Product outcomes vs. business outcomes: why handing your team a revenue target backfires
“Increase revenue 20%” is a business outcome - and it's the wrong thing to put on a product team's goals. Not because revenue doesn't matter, but because your product team can't move it directly. Here's the distinction that makes teams accountable instead of anxious.
It feels logical. The business needs to grow revenue, so you put “grow revenue” on the product team's OKRs. Direct, measurable, ambitious. And it quietly sets the team up to fail - because a business outcome is a lagging indicator of things the product team can only partly control.
The fix isn't to stop caring about revenue. It's to give the team the product outcome that drives it - the one lever they can actually pull.
Business outcome vs. product outcome
A business outcome is what the company wants: more subscribers, higher revenue, better margins. A product outcome is the change in user behaviour that leads there.
Take Netflix. The business outcome is “increase subscriptions.” But you don't grow subscriptions by wishing for them - you grow them by driving a behaviour, like time spent watching. Increase the watching, and retention and subscriptions follow. The behaviour is the product outcome; the revenue is the business outcome trailing behind it.
Why business outcomes aren't the product team's to own
How much profit a business generates never depends solely on the product. Marketing, sales, pricing, operations - they all move that number too. So holding a product team accountable for revenue is holding them accountable for something they only partly influence.
Put the business outcomes at the organisational level and the product outcomes at the product-team level, and something clicks: every team can focus on, and be fully accountable for, a number it can actually move.
Why leaders assign them anyway
If product outcomes are clearer, why do executives keep handing teams business targets? Three reasons I see repeatedly:
- Executives are fluent in business-outcome language and perceive those metrics as easier to track - and they rarely get enough clarity from the product team on how a product outcome connects to the business one.
- The company lacks a clear strategy - often from a shaky understanding of its market and customers - which makes it hard for product teams to know which behaviour to drive.
- The product team keeps its options open instead of committing to sharp bets, so no one can name the specific behaviour that matters.
How to translate a business outcome into a product outcome
Teresa Torres lays out the move cleanly in Continuous Discovery Habits. Roughly:
- Get clear on the business outcome your organisation is focused on.
- Translate it into a product outcome - e.g. “increase subscription revenue by X” becomes “increase time spent listening to music.”
- Sanity-check it's a leading indicator - a human behaviour that genuinely contributes to the business outcome.
- Explore the opportunities - the customer problems and needs, framed from their point of view.
- Prioritise and experiment against those opportunities until you actually move the product outcome.
🎵 Spotify → increase time spent listening to music by subscribers.
🚗 Uber → increase rides per week.
💻 Asana → increase weekly active subscribers.
One caveat, so we're clear
None of this means ignoring the business. A good PM optimises for customer value and business viability at the same time. But the team should measure its progress against the product outcome it can directly influence. Move the behaviour, and the business outcome follows. Chase the business outcome directly, and you get a team that's anxious, unfocused, and building features in the hope that revenue notices.
If your product team is on the hook for a number it can't move, that's usually a strategy problem, not an effort problem - and it's exactly the kind of thing the Opportunity Solution Tree and a bit of outside perspective are built to fix.
.svg)
.svg)
