Outputs versus outcomes
An output is something your team produces: a feature, a redesign, a new integration. An outcome is the change that output is supposed to cause: customers doing something differently.
Teams that manage by outputs measure success by what they shipped. Teams that manage by outcomes measure success by what changed. The difference sounds small, but it changes everything about how you plan. When the goal is an outcome, a feature is just one possible way to get there, and you are free to find a better one.
It also changes what counts as progress. An output-driven team is done when the feature ships. An outcome-driven team is done when customer behavior changes, which might take one feature, three experiments, or the discovery that the original idea wasn't needed at all.
Why outcomes are hard to write
If outcomes are so useful, why do so many teams still plan by features? A few reasons come up again and again:
- Features are easier to promise: a date and a feature list feel more certain than a target metric
- Outcomes require data: if you can't measure customer behavior today, you can't set an outcome
- Ownership is unclear: it is hard to agree which team owns a metric that several teams influence
- Habit: many planning processes, from annual budgets to quarterly roadmaps, still ask for features
None of these are reasons to give up on outcomes. They are reasons to start small: pick one outcome for one team for one quarter, and learn from it.
Business outcomes and product outcomes
Not all outcomes are equal. It helps to separate two kinds:
- Business outcomes describe the health of the business: revenue, retention, churn, cost to serve. They matter, but they are lagging and influenced by many things outside your team's control.
- Product outcomes describe customer behavior in your product: how many people complete a key action, how often they come back, how quickly they get value. Your team can influence these directly.
A good product team is given a product outcome that is believed to drive a business outcome. "Reduce churn below 5%" is the business outcome; "increase the share of customers who invite a teammate in their first month" might be the product outcome that drives it.
Teresa Torres describes this distinction in Continuous Discovery Habits, and recommends that product teams are assigned product outcomes rather than business outcomes, precisely because they are within the team's reach.
What makes a good product outcome?
A strong product outcome passes five checks:
- It describes behavior: what customers do, not what you build
- It is measurable: you can put a number on it today
- Your team can influence it: the team owns the experience that drives it
- It has a baseline and a target: you know where you are and where you want to be
- It has a timeframe: a quarter is a common horizon
A simple template
If you are stuck, start from this template and adjust it:
Increase / decrease [the share or number of customers] who [do a specific behavior] from [baseline] to [target] by [date].
For example: "Increase the share of new users who create their first plan within 24 hours of signing up from 35% to 50% by the end of the quarter." It is not elegant, but every part of it is doing work: who, what behavior, where you are, where you want to be, and when.
Examples: weak versus strong
- Weak: "Launch the new onboarding". Strong: "Increase the share of new users who complete setup in their first session from 40% to 60% this quarter"
- Weak: "Improve search". Strong: "Increase the share of searches that end in a product view from 25% to 35%"
- Weak: "Make the app more engaging". Strong: "Increase weekly active planners from 30% to 45% of users"
- Weak: "Reduce churn" (as a product team goal). Strong: "Increase the share of teams with three or more active members from 20% to 30%"
- Weak: "Build a mobile app". Strong: "Increase the share of users who check their plan on a weekday evening from 10% to 25%"
- Weak: "Improve customer satisfaction". Strong: "Decrease the share of support tickets about billing from 30% to 15%"
The weak versions are either outputs or too far from what the team controls. The strong versions tell the team exactly what success looks like, without dictating the solution. Notice that the mobile app example might still lead to a mobile app, but it might also lead to a reminder email or a better mobile web experience. The outcome leaves that choice open.
Leading and lagging metrics
Every product outcome benefits from two kinds of metrics:
- Leading metrics predict success early. They move quickly and help you steer week to week. Example: daily planning sessions in the first week.
- Lagging metrics confirm the result. They move slowly but tell you whether the change really stuck. Example: monthly retention of new users.
Track both. Leading metrics without lagging ones can make you optimize for activity that doesn't last; lagging metrics alone tell you too late whether you are on track.
Setting baselines and targets
Before you commit to a target, measure where you are. A baseline with a date ("30% of users planned a week in March") turns a vague ambition into something you can track. Then set a target that is ambitious but believable, and write down how you will measure it, so everyone reads the same number.
A few practical tips:
- Define the metric precisely: "active" and "user" mean different things to different people; write down exactly what counts
- Check that you can measure it before the quarter starts, not halfway through
- Look at the trend, not just a single number: a metric that is already rising on its own makes a target look easier than it is
- Avoid vanity metrics: page views and sign-ups are easy to move without changing anything that matters
Common mistakes when writing outcomes
- Disguised outputs: "increase adoption of the new dashboard" is still about a feature; ask what customers should achieve with it
- Too many outcomes at once: a team with five outcomes effectively has none; pick one, maybe two
- Outcomes without baselines: if you don't know where you are, you can't tell whether you moved
- Outcomes nobody can influence: if the metric depends mostly on marketing spend or pricing, it isn't a product outcome for your team
- Changing the outcome every month: outcomes need time to move; give them at least a quarter unless you learn they were wrong
Connecting outcomes to strategy
Outcomes don't exist in a vacuum. They are bets that, if they move, something bigger will move too. In Product Planner you can optionally place product outcomes under a strategy, and record each one as a bet: "If weekly planning increases, then retention improves, because planners build a habit." That makes the link between your outcome and your strategy explicit and testable.
Writing the bet down has another benefit: when the product outcome moves but the business outcome doesn't, you know which belief to question.
Use the outcome to guide discovery
A clear product outcome is the root of an Opportunity Solution Tree: every opportunity you explore and every solution you test should help move it. And when you start testing solutions, our guide to assumption testing shows how to find out quickly whether you are on the right track.
When a solution is ready for delivery, the outcome travels with it. A user story map that names the outcome at the top keeps the team focused on why they are building, not just what.
Review outcomes regularly
Set a cadence, such as every two weeks, to review your outcomes with the team. Look at the leading metrics, note what you learned, and decide whether to keep going, change course or pick a different opportunity. An outcome is not a promise you make once; it is a direction you check against continuously.
Frequently asked questions
How many outcomes should a team have?
One is ideal, two at most. Focus is the point: an outcome only guides decisions if it is clear which one matters right now.
Who sets the outcome?
Usually it is negotiated. Leadership brings the business context and the business outcome; the team brings knowledge of the product and customers and proposes the product outcome they believe will drive it.
What if we can't measure the behavior yet?
Then the first piece of work is instrumentation. Until you can measure it, use the closest behavior you can measure, and say clearly that it is a proxy.
Product Planner lets you define outcomes with leading and lagging metrics, baselines and targets, and see them in a metrics dashboard next to your discovery work. Start free to set your first product outcome.