outcomeryOutcomes, by hand
Good outcome Key Result examples for product teams.
The first Key Result we ever wrote for Outcomery was "ship the bench by the end of the month." We shipped it, we felt great, and nothing outside our two laptops had changed. It took us a while to notice that we had written a to-do list with a deadline on it. So here are examples that survive the week after the launch.
The short version
A good Key Result names someone outside your team, one thing they do differently, a direction, a starting point, a target and a date. For example: cut the share of new workspaces that need our team to import their data for them from 45% to 15% by 30 June. If your team could finish it just by shipping, it is an output wearing a percentage sign.
What all the examples below have in common
Every one of them has the same four parts. Someone outside the team: a customer, a buyer, an admin, a technician. Something that person does differently: imports, pays, renews, stops calling. A direction and two numbers: where it is today, where you are betting it can go. A date, usually the end of the quarter. One change per Key Result. If you find yourself joining two changes with an "and", you have two Key Results and a hard quarter. The examples on this page are invented. The shape is the part worth keeping.
Examples a B2B product team could use
Cut the share of new workspaces that need our team to import their data for them from 45% to 15% by 30 June. Raise the share of invoices customers pay without contacting billing from 62% to 80% by the end of Q3. Raise the share of trial teams that run a second data sync themselves within 14 days from 20% to 40% by the end of Q2. Cut the number of accounts that email us a spreadsheet each month for data the product already shows, from 40 to 10 by the end of Q4. None of them mention a feature. Each one still needs one, and that is your plan, not your Key Result.
Two first drafts and what they became
First draft: roll out the bulk edit screen to every plan by 30 September. It is done the day it ships. Rewritten: cut the share of accounts that update their prices one item at a time from 70% to 25% by 30 September. Second draft: increase mobile app logins by 25% by the end of Q2. Logins go up when people find things, and also when they cannot. Rewritten: raise the share of field technicians who close a job in the app before leaving the site from 35% to 65% by the end of Q2. The feature survives both rewrites. It just stops being the finish line.
Don't copy the numbers, copy the shape
Borrow the sentence pattern, never the figures. 45% to 15% is a number we made up for a page on the internet; your baseline is a fact about your product. Measure the starting point before you commit, even roughly. Two weeks of data beats a guess, and a guess dressed as a baseline has a way of coming back in December. If you truly cannot get a number yet, write the Key Result anyway and say so. It is a weak outcome for now, and naming that is more honest than inventing a starting point.
If you want a second opinion on your draft
The bench at outcomery.com takes one Key Result, up to 1,200 characters, and puts it in one of four positions: OUTPUT, OUTPUT IN DISGUISE, WEAK OUTCOME, TRUE OUTCOME. It names the tell that placed it there and writes a corrected spec, or tells you when no stamp fits. Free, no account. An AI agent writes the verdict, so it can be wrong; if the tell does not describe your Key Result, keep your version. A bad first draft is not a verdict on you or your team. It is just the draft that answers "what will we build?" when someone asked a different question.
Questions
- What is a good key result for a product team?
- A good Key Result measures a change in what someone outside the team does, with a direction, a baseline, a target and a date. For example: cut the share of new workspaces that need our team to import their data for them from 45% to 15% by 30 June. The test is one question: could the team call it done just by finishing its own work, while everyone outside carries on exactly as before? If yes, it is measuring delivery, not effect.
- What is an example of a good outcome-based OKR for a B2B product team?
- Here is one, invented for this page. Objective: new customers get their data in without needing us. Key Result one: cut the share of new workspaces that need our team to import their data for them from 45% to 15% by 30 June. Key Result two: raise the share of trial teams that run a second data sync themselves within 14 days from 20% to 40% by the end of Q2. The objective says why it matters. The Key Results name what someone outside the team does differently, and by when.
- Can I copy these examples straight into my own OKRs?
- Copy the sentence shape, not the numbers. The percentages here were invented to make the pattern readable; yours have to come from your own data. Keep the structure: raise or cut, what someone outside the team does, from baseline, to target, by date.
- What if we can't get a baseline before the quarter starts?
- Write the Key Result with the baseline missing and say it is missing. Two weeks of real data beats a guess, so start counting now rather than inventing a starting point you will have to defend later. Until there is a real number, it is a weak outcome, and that is a fair thing to say out loud in a planning meeting.