Outcomes, not features
Ask a team what it is working on and you will usually hear a list of features. Ask what those features are for and the answers get vaguer. Framing discovery around an outcome — a change in what people do, measured — is the simplest way to fix that.
Output, outcome, impact
Three words that get used interchangeably, but mean different things:
- Output is what the team produces: a feature, a page, an integration.
- Outcome is the change in behaviour the output is supposed to cause: more people finishing sign-up, fewer support tickets about invoices, managers spending less time on reports.
- Impact is what that change means for the business: revenue, retention, cost.
Teams control output completely and impact barely at all. Outcomes sit in the useful middle: close enough to the team’s work that it can influence them, close enough to the business that they matter.
What a good outcome looks like
A good outcome has four properties.
- It describes behaviour. “Customers are happier” is a feeling. “Customers renew without contacting support” is something you can see.
- It is measurable now. If you cannot get the number today, either find a stand-in measure that tracks it closely or make measuring it the first piece of work.
- The team can move it. “Increase company revenue” is influenced by sales, pricing, the economy and the weather. “Increase the share of trial accounts that invite a colleague” is something one team can actually work on.
- It has a direction and a horizon. Up or down, and roughly by when you expect to see a change.
Put together: “Increase the share of new accounts that create a second project within 14 days, from about 18% to 25%, by the end of the quarter.” Nobody has said anything about which features will do it. That is the point.
Leading and lagging
Some measures move quickly and predict what will happen later; others only move after a long delay. Retention after six months is a lagging measure: by the time it changes, the cause is long forgotten. Whether a new user completes a key action in their first week is a leading one.
For day-to-day discovery, pick a leading measure that you have reason to believe is connected to the lagging one you really care about. Check that belief occasionally. Leading indicators have a habit of drifting away from what they were supposed to predict.
Common traps
The disguised output. “Launch the new onboarding by March” is a delivery date, not an outcome. Ask what should be different once it launches.
The vanity metric. Page views, sign-ups and downloads are easy to move and often say little. An outcome built on them can be hit while the product gets worse.
Too many at once. A team with five outcomes effectively has none, because every piece of work can be justified by one of them. One primary outcome, perhaps with one guardrail that must not get worse, is plenty.
When you are handed a feature
It happens all the time: a stakeholder arrives with a specific feature request. Arguing about outcomes in the abstract rarely helps. Asking a few concrete questions usually does:
- If this existed tomorrow, what would people do differently?
- How would we notice?
- Who is struggling without it today, and what do they do instead?
Often the answers reveal a perfectly good outcome behind the request. Once it is written down, the original feature becomes one candidate solution among several, which is exactly where it belongs. Sometimes it turns out to be the right one, and you have lost nothing but a short conversation.
Writing it down
A short outcome brief is enough: the problem in two or three sentences, the outcome and how it is measured, any constraints, and what is explicitly not part of the work. It should fit on one screen. If it does not, the outcome is probably several outcomes wearing a trench coat.
Next in the cycle: Customer interviews that teach you something.