Outcomes Over Outputs

This is the most important belief in the entire Product Execution domain, and arguably in the whole Atlas. If everything else here is technique, this is the point of the technique. I put it last in the domain on purpose, because it's the lens you should re-read all eleven prior notes through.

#The belief, stated plainly

A team that counts features shipped, story points burned, or roadmap items checked off is measuring its own activity. A team that counts retention moved, friction removed, revenue earned, or a job done better for the user is measuring its impact. These produce radically different products and radically different cultures, and the gap between them is the gap between a feature factory and a real product team.

#Feature factory vs outcome team

This is the same divide Marty Cagan draws between feature teams and empowered product teams, and it's central enough to the foundations that it has its own note: Product Teams vs Feature Teams. Here's how the two actually feel from the inside.

The Product Organization Matrix frames this exactly: the PM as Owner (accountable for an outcome) versus Facilitator (organizes people to ship features). Outcome teams need owners.

#This is why I built the rest of the domain the way I did

Outcomes-thinking isn't a separate activity; it's woven through every execution competency:

• Specs open with the outcome and the metric ("Outcome Oriented" is the first behavior), not a feature list.
• Decisions are judged by the change they produce, and you write down the prediction so you can check it.
• Launches aren't done at 100% rollout. They're done when you've measured the outcome.
• The 10/50/90 framework's entire purpose is to avoid spending effort building outputs you haven't validated will produce outcomes.

It also connects straight up into the strategy domain, where it stops being a feature-level habit and becomes a leadership mandate: Business Outcome Ownership is literally this belief promoted to a competency, and The North Star Framework and OKRs and Goal-Setting are the tools for making outcomes the unit of planning rather than features.

#How to actually do it

• Define the outcome metric in the spec, before building. No metric, no build. This one rule kills more feature-factory behavior than any reorg.
• Pair every output with its expected outcome. "We're building X so that metric Y moves by Z." If you can't finish the sentence, you're proposing an output in search of a reason.
• Hold a real post-launch review (Shipping and Launch). Did the number move? If not, iterate or kill it. Loyalty to a flop is the feature factory's favorite disguise.
• Change the way you report up. Lead executive updates with outcomes moved, not features shipped. You train the org to value what you report.

#How AI is changing it

AI makes this belief more load-bearing, not less. When AI commoditizes the production of outputs, whether that's drafting specs, generating tickets, or even vibe-coding prototypes, shipping stops being a differentiator, because shipping gets cheap and fast for everyone. The scarce, defensible skill becomes knowing which outcomes are worth pursuing and judging whether they actually moved. SVPG is explicit that the backlog-administrator (pure output) role is the easy AI target, while outcome-oriented PMs are in demand. As the cost of producing outputs collapses, the premium on choosing and measuring the right outcomes only rises. See Competencies AI Commoditizes vs Elevates.

#Continue Reading

• Product Teams vs Feature Teams for the foundational version of this divide, via Cagan.
• Business Outcome Ownership for this belief promoted from a habit to a strategy competency.
• The North Star Framework for making one outcome the organizing metric for a team.
• Product Execution for the domain hub; re-read it through this lens.
• OKRs and Goal-Setting for setting outcomes, not output lists, as goals.