The question nobody asked me when I started was: what changed after you shipped it?
For the first two years, I measured my work by deliverables. Feature designed. Screens handed off. Sprint done. That was the job.
Then I got into a conversation with a PM at MontyCloud about a feature we'd shipped a few months earlier. I assumed we'd talk about the design — what worked, what didn't. Instead she asked: "Did users actually adopt it?" I had no idea. I'd never tracked it. I'd treated my job as ending at handoff.
That conversation reset how I think about design.
The distinction
Output is what you build. A feature. A screen. A design spec.
Outcome is what changes because you built it — in user behavior, in business performance, in how someone feels using the product.
Outputs are easy to count. Outcomes are harder to name. Which is probably why most designers default to outputs.
Why this matters
A team could ship fifty features and none of them change anything meaningful. And a team could ship one decision — a different empty state, a more obvious call-to-action, a removed step in onboarding — and meaningfully change retention.
The latter team is thinking in outcomes. They're asking: what specific behavior are we trying to shift? And they're measuring against that.
A framework that helped me
If you're working on a SaaS product, your revenue breaks down roughly like this:
Revenue = # of customers × monthly spend × subscription length
Break that further:
# of customers = site traffic × signup conversionsubscription length = retentionmonthly spend = pricing × perceived value
When you're designing anything, you can locate it in this formula. Does this onboarding redesign affect signup conversion? Does this in-app experience change retention? Does this pricing display change perceived value?
If you can't locate your design work somewhere in that chain, you should ask whether you're solving the right problem. Work that doesn't connect to any real number is probably decoration.
How to apply this before you open Figma
Before starting any design, write one sentence: "This design is trying to shift [specific behavior or perception] among [specific users]."
Be precise. Not "improve the experience" — that's a direction, not a target. "Help new users reach their first successful export within 10 minutes of signup" is something you can test and measure.
Then, after you ship: did it happen? You might not always be able to measure it yourself — especially in early-stage teams. But asking the question before you design changes how you make decisions during design. You start pruning features that don't serve the outcome. You start pushing back on additions that add noise without changing behavior.
What this changes in practice
When I design from an outcome, I make different choices. I ask myself: "Is this screen helping the user reach the behavior we're targeting, or just making the interface more complete?" Those aren't the same question.
It also changes how I present work. Instead of "here's the new flow," I try to lead with: "we're trying to reduce time-to-value for new users, and here's why this design serves that." That framing is more honest and more useful for stakeholders.
The honest version
I don't always do this perfectly. There are still weeks where I'm heads-down in a sprint and not thinking about outcomes until someone asks. But the habit of asking "what changes if we ship this?" before touching Figma has made me a better designer than any visual technique I've learned.
Outputs are your job. Outcomes are the point. If you're not occasionally asking yourself which one you're optimizing for, you might be doing a lot of work that lands nowhere.
Credits & further reading
- Teresa Torres — her work on continuous discovery and the Opportunity Solution Tree is the clearest articulation I've found of how to think about outcomes systematically. The tree maps from a desired outcome → opportunities to reach it → solutions to test. (producttalk.org)
- Shifting from Outputs to Outcomes — Teresa Torres, producttalk.org. (Read it here) — the article that first gave me language for the distinction.
- Managing Outcomes in Product Teams — Teresa Torres, producttalk.org. (Read it here) — how to apply outcome thinking practically inside a team.
- Continuous Discovery Habits — Teresa Torres (book). The full framework for making discovery work a regular practice, not a one-time phase.
- Marty Cagan, SVPG — his writing on empowered product teams versus feature factories is where the output/outcome tension is laid out most clearly in the context of real product organizations.