Outcomes vs Outputs
You ship features, mark tasks done, and still nothing moves in the metrics that matter.
"Mistaking 'making stuff' for making progress, and mistaking shipping features for being done."
Joshua Seiden.
In my experience, the problem usually starts with the roadmap. Leaders pack it with features and deadlines. The team then measures success by productivity: how much got shipped. The user result and the business result become afterthoughts. Without an outcome to aim at, the team can't propose better ideas, can't experiment, and can't tell whether the work was worth it.
Joshua Seiden points out that leaders and teams often define value at different altitudes. Leaders think about impact. Teams think about resources, tasks, and outputs.
That gap closes when leaders communicate in outcomes. Be specific about what must change and why.
For example, if the goal is to increase online store sales, that's the impact. The team can decide to raise the average order value. That's the outcome. One way to get there is adding a section that says, "Customers who bought this product also bought…" That's the output.
Seiden frames this as a logic model:
In the store example, the impact is more sales, the result is a higher average order value, and the output is the related-products section.
When the model is explicit, the team knows what result to measure and can iterate until it happens.
Seiden suggests three questions to find the outcome:
- What user behaviors drive business results?
- How do we get people to do more of those behaviors?
- How do we know we're right?
Moving from productivity metrics to outcome metrics is hard. But if you want the work to matter, plan in outcomes. I keep two questions nearby: "Why are we doing this?" and "What are we trying to achieve?"