Product economics is the short list of terms that lets a team argue about what to build next in money. Product management borrowed every one of them from managerial accounting and from the economics of queues. The terms are old. Donald Reinertsen put cost of delay at the centre of his 2009 book on product development flow, and sunk cost and opportunity cost were settled long before software existed. A product manager needs them because the people who release funding already argue in this vocabulary. An item defended in the language of the backlog usually loses to an item defended in the language of the balance sheet.
The sections below define the five terms that do the most work. They then set out what value means to each group with a claim on the answer. The techniques for measuring value come next, and the page ends with where each syllabus puts the material.
Terms worth defining precisely
Cost of delay. The value lost for every unit of time a capability is unavailable. A compliance change with a fixed deadline carries almost nothing until the date and an enormous amount the day after it. A revenue feature in a growing market bleeds a steady sum every week. Dividing cost of delay by the duration of the work produces a ranking that beats most scoring schemes, and that division is the whole of weighted shortest job first.
Sunk cost. Investment already made, which nobody can now recover. It should count for nothing in the next decision. Treating it as though it counts is the most common error in a backlog argument, and it usually arrives in the sentence "we have already spent six months on this".
Opportunity cost. The value of the best thing the organisation gave up to do this thing. Every ordering decision creates one. Naming it aloud changes the question. The conversation stops being about whether an item is valuable, since almost everything is, and becomes a conversation about whether it is worth more than the work it displaces.
Total cost of ownership. Building is a fraction of the cost. Support, hosting, documentation, training and the drag every extra feature puts on future changes all run for the life of the thing. A cheap build can therefore commit an organisation to an expensive decade.
Customer lifetime value and cost of acquisition. What a customer is worth across the whole relationship, and what it cost to win them. The ratio between the two sets how much the product can afford to spend on keeping a customer against finding a new one. A ratio below three to one usually means growth is being bought at a loss.
What value means to each stakeholder group
The word value covers several different quantities. Five groups have a claim on the answer, each one of them measures something else, and a single number carried to all five convinces none of them.
| Group | What it values | What it accepts as evidence |
|---|---|---|
| Customers and users | The problem going away, with the least disruption to what they already do | Task completion time, repeat use, contacts with support |
| The business | Revenue, margin, retention and reduced risk, on the horizon its planning cycle sets | Deals influenced, churn avoided, cost removed |
| Operations and support | Fewer incidents, fewer manual steps, fewer tickets nobody can resolve | Incident counts, handling time, escalation rate |
| Engineering | A system that stays changeable, since that sets the cost of everything after this release | Change failure rate, lead time, defect escape rate |
| Regulators and auditors | Controls somebody can demonstrate on request | Traceability, records, evidence of a control operating |
A product manager able to state an item's worth in all five vocabularies rarely has to win the argument by seniority.
Techniques for measuring value
Direct outcome measures. Conversion, task completion time, retention, support contacts per active user. Each of these attaches to the specific change, and somebody can watch it happening. That is why they carry more weight than anything a survey returns.
Revenue and cost attribution. Deals influenced, churn avoided, hours removed from a manual process. Every one of these figures is blunt and arguable. They are also the language most funding decisions happen in. If a product manager refuses to produce them, somebody else produces them and makes the decision.
Scored comparison. Models such as RICE or weighted shortest job first compress several dimensions into one number. The score does not make the decision. It makes the reasoning visible, so a colleague can argue with the reasoning itself.
Value area checklists. Several frameworks group value into areas, so that a team measuring one area cannot quietly ignore the others. A widely used set separates four areas.
- The value a product delivers today.
- The value it would deliver if it served its market fully.
- The organisation's remaining ability to innovate.
- The time it takes to put a change in front of a customer.
The grouping earns its place as a guard against the common failure of measuring only the value a product has already banked.
Where each syllabus puts it
The CSPO learning objectives put this material inside the backlog section. They ask a product owner to define at least three of the terms, to describe value from at least three stakeholder perspectives and to list at least three techniques for measuring it. The value area checklist above is published by Scrum.org as Evidence-Based Management, with the four areas named Current Value, Unrealised Value, Ability to Innovate and Time to Market. That set sits outside the Scrum Guide, so a candidate meets it as supporting material.
The Product Strategy Practitioner course arrives at the same arithmetic from the far end. There the question is how to settle an allocation argument between two funded products. The strategy has already named its non goals. Somebody still has to say which of the survivors gets the next engineer. The maths is identical. Only the size of the thing being compared changes.