outcomery

Guide
Outcomes, by hand

How to write a product outcome, not an output.

We've written plenty of Key Results that were outputs with a number stapled on. Here's how we fix one now: start from the delivery you already wrote, and turn it into a change someone outside the team makes. It fits in the gap before your planning meeting.

The short version

A product outcome is a change in what someone outside your team does that is worth something to the business, with a direction, a starting point, a target and a deadline. If your team could finish it just by shipping, it's an output.

[Raise or cut] [what someone outside the team does] from [baseline] to [target] by [date].

Want a verdict on your own Key Result? Paste it into the bench at outcomery.com. Free, no account.

Five steps, one Key Result

1. 01

   Start from the output you already have.

   Most first drafts are a feature and a date. Keep it. It isn't wrong, it answers a different question: what will we build? Write it down, then ask the question it skips.

2. 02

   Ask who acts differently if it works.

   Name the person outside the team: a customer, a buyer, an admin, a colleague who uses your platform. Then name what they would do that they don't do today. If you can't name anyone, you've learned something before the quarter started, which is cheaper than learning it after.

3. 03

   Measure the value, not the activity.

   Visits, clicks, logins and views go up when people look, and also when they're lost. Pick the action that means someone got what they came for: finished setup, bought again, stopped needing to ask support.

4. 04

   Say from where to where.

   Measure the starting point before you commit, even roughly: two weeks of data beats a guess. Until there is a real number, it's a weak outcome, and the bench will say so. Don't invent one. Set the target where your team would bet on it, not where it looks good on a slide.

5. 05

   Add a deadline, then run the check.

   Usually the end of the quarter or the cycle. Then ask the one question below. If the answer is yes, go back to step two.

   Could the team call it done just by finishing its own work, while everyone outside the team carries on exactly as before?

Four Key Results, reworked

Invented for this page, each one a kind we've written ourselves. The label is where it sits on our verdict scale.

1. 01
   Written · OUTPUT

   Ship the new reporting dashboard to all enterprise customers by 30 June.

   The tell. A delivery verb and a date. It is done the day it ships, whether or not anyone opens it.

   Reworked

   Cut enterprise accounts' monthly requests for us to pull a report for them from 120 to 40 by 30 September.

2. 02
   Written · OUTPUT IN DISGUISE

   Empower admins with a best-in-class permissions experience by Q3.

   The tell. Outcome words around a delivery. "Empower" and "best-in-class" sound like someone gains something, but nothing outside the team has to change for it to be done.

   Reworked

   Cut the share of admins who file a support ticket about access or permissions each month from 30% to 10% by the end of Q3.

3. 03
   Written · WEAK OUTCOME

   Increase weekly visits to the help center by 30% by the end of Q4.

   The tell. Visits count activity. They also go up when the product gets more confusing.

   Reworked

   Raise the share of help-center visits not followed by a support ticket within 48 hours, from 55% to 70% by the end of Q4.

4. 04
   Written · WEAK OUTCOME

   Get 500 teams using the new approval workflow.

   The tell. No deadline, and it counts use of the thing you built, not what anyone got from it.

   Reworked

   Cut the share of purchase requests that customers chase by email or phone before approval from 40% to 10% by the end of Q2.

The feature is still in every rewrite, just not in the sentence. It stopped being the finish line and became the bet on how to get there.

Where it usually goes wrong

• A count of things shipped: "three features", "ten experiments". Still an output, just counted.
• A bar the team sets and then marks itself, like a score from its own survey.
• Several changes in one sentence. One change per Key Result.

Questions

What is the difference between an output and an outcome?

An output is something your team makes: a feature, a release, a campaign. It is done when it ships. An outcome is a change in what people outside the team do because of it, and that change is worth something to the business: customers finishing setup, buying again, needing support less. Both matter. Only the outcome tells you whether the output worked.

Can a Key Result be an output?

It can be written as one, and most first drafts are. Then the Key Result only measures whether the team delivered, not whether it helped. Keep the output as the plan, and make the Key Result the change it is meant to cause.

Is an OKR the same thing as an outcome?

No. An OKR is a format: an objective plus a few Key Results. Whether a Key Result is an outcome depends on what it measures. Plenty of OKRs are lists of outputs with a percentage sign.

Is there a tool that checks whether my Key Result is an outcome?

The bench at outcomery.com does. Paste one Key Result and you get a verdict, the tell that placed it, and a corrected spec. Free, no account. An AI agent writes the verdict, so it can be wrong.

Got one on your desk?

Paste it into the bench. One Key Result, no account.

Inspect a Key Result

Written by Georges-Alexandre Hanin · What we believe about outcomes