Product thinking and discovery
Outcomes vs output
Shipping is output. Outcomes are changes in user or business behavior. The build trap is optimizing the first and ignoring the second.
Most of an engineer's week is output: tickets closed, PRs merged, services deployed. Outcomes are what those shipments change — users succeeding, the business growing, a risk retiring. Teams that chase velocity while ignoring whether anyone uses what they shipped end up in the build trap: busy roadmaps, rising headcount and flat results.
The big idea
Output is necessary. It is not sufficient. A feature that nobody uses is still output. A one-day prototype that proves people will pay is an outcome, even if the code is thrown away.
The build trap (Melissa Perri's term) is when an organization measures success by how much it builds. Roadmaps fill with features. OKRs become "ship X by Q3." Teams celebrate launch day and never look at week-4 retention. Engineering capacity becomes the bottleneck everyone fights over, while the real bottleneck is learning what matters.
A kitchen that plates fifty dishes nobody eats is not a successful kitchen. The analogy breaks when output is the outcome — a regulatory filing, a security patch — but those are the exception, not the backlog.
| Signal | Output-obsessed team | Outcome-oriented team |
|---|---|---|
| Success metric | Velocity, story points, launches | Metric movement, validated learning |
| Roadmap | Feature list with dates | Problems and bets with evidence |
| After launch | Move to the next ticket | Instrument, watch cohorts, iterate or kill |
| Engineer question | "Is the spec clear?" | "What risk does this reduce?" |
Walking through it
A team ships a "share to Slack" button in two weeks. Output: done.
Outcome check: 3% of users click it; of those, 80% never share again; support gets tickets about permission errors. The feature cost about 3 engineer-weeks and moved the north star by noise.
An outcome-oriented team would have tested demand with a fake door or a 1-day prototype before the full build. Escaping the trap does not mean shipping less forever. It means treating every build as a bet with a hypothesis, a success metric and a kill or iterate condition.
Product-market fit is the extreme form of this clarity: enough people care that growth compounds.
Common mistakes
- Counting launches as wins. Launch day is when measurement starts, not when the bet is proven.
- OKRs that name features. "Ship the dashboard by Q3" is an output. "Activation for new teams hits 35%" is an outcome.
- Skipping the check because the build was hard. Effort does not create demand.
Check yourself
- A team ships dark mode, closes the ticket and starts the next epic. What is missing?
An outcome check: who it was for, what should move and whether it moved.
- Why can a team with rising velocity still be in the build trap?
They are optimizing output (shipping) while outcomes (usage, retention, revenue) stay flat.
Key takeaways
- Output is what you ship. Outcomes are changes in behavior or the business.
- The build trap is measuring success by how much you build.
- Treat each build as a bet with a hypothesis, a metric and a kill condition.
Further learning
Melissa Perri's framing of the build trap — useful vocabulary when your org confuses velocity with progress.
Escaping the Build Trap (Melissa Perri / book page)Book — Melissa PerriMelissa PerriNext, the four risks every product bet has to survive: four product risks.
Related
Product thinking for engineers
Outcomes over output — why engineers who understand users and business build better software. Start here for the map.
Four product risks
Every failed product fails at least one of value, usability, feasibility or viability. Name the biggest risk before you write code.
Product-market fit
What fit feels like, how to measure it, the false positives that fool teams, and what changes after you find it.