The video above makes the broader argument that product management is responsible for improving the exchange between an organization and the people it serves. This essay focuses on the measurement problem that follows: how can a team recognize that the exchange is improving before a quarterly business result arrives?
Outcomes are not a list of metrics
A dashboard can contain dozens of measurements without explaining what the team is trying to change. Sessions, clicks, revenue, satisfaction, and task completion may all move at once. Without a relationship among them, a team can select whichever number makes its work look successful.
An outcome map starts with a specific product decision and connects three distances of change: the improvement someone should experience, the organizational result that improvement should support, and the observable product behavior joining them. The Product Outcome Triplets framework defines those parts. Mapping adds time: what should become visible first, what should follow later, and what evidence would make the team reconsider the connection?
That sequence matters because shipping is immediate while value is delayed. A feature can be complete before the behavior it was meant to change has had time to emerge. If the team waits only for retention or revenue, it may discover a bad assumption after attention and technical capacity have moved elsewhere.
Map backward from the result
Suppose an organization wants more repeat purchases. That is a legitimate business outcome, but it is too distant to guide a product team by itself. Many things can affect it: price, inventory, seasonality, acquisition quality, and the product experience among them.
The map becomes useful when the team works backward:
- Business outcome: more durable revenue from returning customers.
- User outcome: people can reorder something they need at the moment they decide to act.
- Product outcome: more returning customers complete a repeat purchase from a previous order in the same session.
- Earlier signals: more eligible customers find a previous order, begin a reorder, confirm the right items, and reach checkout without correcting unexpected details.
The product outcome is close enough for a team to influence but far enough from the interface to avoid prescribing a feature. A “reorder” button might help, but it is not the outcome. If people use the button and then abandon the purchase, the output succeeded while the intended change did not.
Leading indicators are a response system
Leading indicators are useful because they create time to respond. They are not miniature outcomes and they are not proof that the final result will occur. They are evidence that the conditions for it are becoming more or less favorable.
In the repeat-purchase example, discovering a previous order happens before completing a reorder. Confirming the intended items happens before checkout. Each step can reveal a different failure: the entry point may be invisible, the saved order may be stale, or the resulting cart may contain surprising substitutions.
A good indicator therefore has three properties:
- It occurs early enough for the team to change course.
- It has a plausible relationship to the desired product outcome.
- It suggests a concrete question when it moves unexpectedly.
The last property keeps measurement connected to learning. “Reorder starts decreased” is not a verdict. It is a prompt to investigate who stopped, where, and under what conditions.
Add guardrails before declaring success
Any behavior can be increased in a way that damages the value it was meant to represent. A team could raise repeat-purchase completion by hiding important choices, making cancellation harder, or defaulting people into quantities they did not intend.
Outcome maps need counter-signals: corrections before purchase, cancellations, returns, unexpected charges, or evidence that the behavior is concentrated among people who do not benefit from it. These measures do not sit outside success. They test whether the measured behavior still represents the user outcome the team claimed to support.
This is also why an outcome map should record assumptions in plain language. If the team believes faster repeat purchase improves convenience and loyalty, it should say so. That belief can then be challenged by research, behavioral evidence, or a segment for whom speed is less important than control.
Review the map as a theory
An outcome map is not a reporting artifact to complete before delivery and admire afterward. It is a working theory that should change as evidence arrives.
Before delivery, use it to expose gaps between the proposed intervention and the expected behavior. During delivery, use it to decide what instrumentation and qualitative evidence are necessary. After release, review the earliest signals before the final results and agree in advance what would trigger investigation, iteration, or reversal.
The discipline is simple: do not let an output stand in for a change, and do not let one attractive metric stand in for value. A useful map makes the team state what should improve, how it expects to recognize progress, and what would show that its reasoning was wrong.