Products, Product Management and the Value Lifecycle

Start with value, not a feature list

A product is not merely a bundle of features or a project that has finished delivery. In this diploma, a product is treated as an ongoing means of solving a problem or enabling a task for users or customers within organizational constraints. Product management therefore repeatedly asks: who are we serving, what problem or opportunity matters, what outcome should change, which assumptions remain uncertain, and what evidence justifies continuing, changing, or stopping? This view prevents product work from becoming a race to release features whose value is unknown.

The value lifecycle: repeated learning, not a fixed production line

A practical value lifecycle can be pictured as connected activities: understand the context and user; define a problem or opportunity; state a desired outcome; explore assumptions and possible solutions; build and release enough to enable use or learning; observe behavior and results; then decide whether to improve, scale, change, or stop. These activities are not a rigid sequence. New evidence may take the team from measurement back to problem understanding, while a technical constraint may force solution redesign. The purpose is to make learning and decisions visible, not to create ritual.

The distinction between output and outcome matters. An output is something built or released, such as a new rescheduling button. An outcome is a change in behavior or capability connected to value, such as a higher proportion of customers successfully rescheduling by themselves. Broader effects may follow, such as fewer support calls or better capacity use. Releasing the button is a delivery fact; its expected effect remains a hypothesis until measured. A team should therefore not promise that a specific feature will “create growth” before evidence supports that claim.

Post-release decisions are part of product management

Releasing something does not end responsibility for thinking about its value. After release, the team asks whether users found the capability, understood it, completed the task, experienced side effects, or created unexpected operating cost, and what changed from baseline. Decisions then follow the evidence: improve discoverability, simplify steps, expand the solution, keep it unchanged, or remove it. A feature is not successful merely because it functions technically, and an experiment is not useless merely because the target metric did not improve; learning may prevent a larger poor investment.