Outcome-Based Product Ownership: From Brief to Measurable Result

Product ownership is the job of deciding what is worth building and answering for whether it helped. Everything else, the backlog, the roadmap, the reviews, serves that. This guide takes the shortest honest path from an idea to a measurable result: separate outcomes from output, write a brief from evidence, lay out options and assumptions, and say plainly how a customer is better off. It also explains why "we added AI" is never the result, however good the demonstration looked.

We write for a working product owner or product manager and assume no prior knowledge of the frameworks.

1. Why a product owner starts with outcomes

The Scrum Guide 2020 gives the Product Owner one accountability that matters here: maximising the value of the product that comes from the work of the team. It also asks the team to work towards a Product Goal, which it describes as a future state of the product that serves as a target to plan against. Neither phrase says "ship the list". Value and a target state are statements about the world after the work, not about the work.

That is the heart of outcome-based ownership. You are judged on what changed for people, not on what was delivered. Marty Cagan of SVPG draws the same line when he contrasts feature teams, which are about shipping features and projects from a roadmap, with product teams, which are measured by outcomes rather than output. Whatever your team is called, what matters is the question you ask at each decision: what will be different for the customer or the business, and how will we know?

This matters more once AI is involved, because AI makes output cheap. A model can draft forty backlog items, ten user stories or a prototype in minutes. If output was ever a safe proxy for progress, it no longer is. The scarce thing is judgement about which change is worth making.

2. Outcome, output, activity and adoption

Four words get confused in board updates. Here they are, with an everyday example (illustrative, not a real company: a support team that has added an AI tool which drafts replies for agents).

Teresa Torres, who writes about product discovery at Product Talk, separates three kinds of outcome measure. Business outcomes measure the health of the business, such as revenue or churn. Product outcomes measure customer behaviour in the product, or how customers feel about it, and she suggests putting one at the top of a team's tree of work. Traction metrics measure adoption of a single feature, and she considers them too narrow to guide discovery. In her terms, the "AI-adoption counts" that managers like to report are traction metrics: they show the feature is touched, not that anyone is better off.

A quick test for any number in a report: If this number doubled and nothing else changed for customers, would we be pleased? If the answer is "it depends on something else", you are looking at an output or an adoption count, and the thing it depends on is the outcome.

3. Why "we added AI" is not an outcome

"We added AI to X" is a description of a solution. A solution may or may not solve anything. Three problems follow when it is treated as a goal.

1. It cannot fail. Once the feature ships, the goal is met, whatever happens to customers. A goal that cannot fail teaches the team nothing.
2. It hides cost and risk. AI features cost money to run, need evaluation and can produce wrong answers confidently. A goal of "adopt AI" gives nobody a reason to weigh those against the benefit.
3. It closes the option space. If AI is the goal, a simpler fix, such as clearer wording on a page, never gets compared.

The worry is not only theoretical. In June 2025 Gartner forecast that over 40% of agentic AI projects (projects built around AI that acts with some autonomy) would be cancelled by the end of 2027, citing escalating costs and unclear business value. It is a forecast, not a measurement, and it covers one kind of project. We cite it only because "unclear business value" is exactly what you get when the target was the technology instead of the result. Our guide on using AI safely at work covers the data and risk side of the same decisions.

A better framing keeps AI in its place:

• Weak: "Add an AI assistant to the help centre."
• Better: "Reduce the share of customers who contact us twice about the same issue, without increasing wrong answers. Then compare options, one of which may be an assistant."

The second version leaves room for AI, and also for finding out that AI is the wrong tool.

4. Leading, lagging and guardrail measures

Every outcome you care about is lagging: it shows up weeks or months after the work, so by the time it moves you have already spent the money. A lagging measure is the result you ultimately want, such as customer retention or the share of issues solved in one contact. A leading measure is an early signal that you can influence and read within days or weeks, and that you have a reason to believe will move the lagging one. A guardrail measure is something you agree must not get worse while you chase the outcome.

Back to the support team. Suppose the target outcome is fewer repeat contacts per issue.

Three rules keep this honest.

1. Fix the baseline first. "Reduce repeat contacts" means nothing without today's figure, where it came from and how it is counted. Without a baseline you cannot tell improvement from drift.
2. Name an owner and a window. Who reads the number, how often, and how long you will wait before judging.
3. Expect a measure to be gamed. Once a number is a target, people optimise the number. A guardrail is partly there for that reason, and so is reading the leading measure beside the lagging one.

A metric tree makes the links explicit. You start with the outcome at the top, break it into the leading measures that should move it, and attach each proposed feature to the measure it is meant to change. A feature that attaches to no measure is a feature you cannot justify yet, and writing that down is a useful result in itself.

1. 1FeatureWhat the team proposes to build
2. 2Behaviour changeWhat customers should do differently
3. 3Leading measureThe early signal, read in days or weeks
4. 4Lagging measureThe result you ultimately want
5. 5GuardrailWhat must not get worse on the way
6. 6Baseline and ownerToday's figure, its source and who reads it

5. Writing the brief from evidence

A product brief sets out the problem worth solving, for whom, how you know, and what success would look like, before any solution is chosen. Its core is a problem statement. A solid one has five parts:

• Who has the problem (a segment you can identify, not "users").
• Situation: when and where it arises.
• Problem: what goes wrong, in the customer's terms.
• Evidence: where you saw it, such as interview notes, support data or logs, each with a reference.
• Impact: which measure it affects and by roughly how much, with the source.

The test for a good statement is what it leaves out: no solution words. "Customers need a chatbot" is a solution wearing the clothes of a problem. "Customers who miss their appointment cannot tell whether to rebook or wait, and call us to ask" is a problem, because several solutions could address it.

Evidence strength matters. One interview is a lead, not a segment. Three people saying the same thing is stronger than one, and a log of how many people actually hit the problem is stronger again. An expectation ("customers will love this") is an assumption even when someone wrote it in a document, because writing it down does not turn it into an observation.

This is also where AI most needs supervision. A model asked for a brief will produce fluent, well-structured text containing needs nobody expressed and numbers nobody measured. It is not lying on purpose; it completes patterns. The check is mechanical and worth doing line by line: tag each sentence supported (and point to the source), assumption (a belief you have not tested) or unsupported (nothing behind it, so cut it or go and find evidence). Our guide on prompting for delivery work shows how to ask for drafts so that checking is easier.

1. 1DraftAsk the assistant for a structure from your notes only
2. 2SplitBreak the draft into single claims
3. 3TraceFind the source for each claim
4. 4TagSupported, assumption or unsupported
5. 5Cut or testRemove what you cannot support or plan how to learn it

6. Opportunities, solutions and assumptions

Once the problem is clear, the temptation is to jump to a favourite solution. Torres's opportunity solution tree is a way to slow down in a useful way. It has four layers: the desired outcome at the root; below it the opportunities, which are customer needs, pain points or desires that would move the outcome if addressed; below those the solutions you might try; and below those the assumption tests that show which solution best creates customer value in a way that also drives business value.

Torres offers a simple test for an opportunity: could more than one solution address it? "I want to go out to eat" is a solution in disguise, since only one thing answers it, while "I am hungry" leaves room for many. Apply the same test to a backlog item. If it names the thing to build, it belongs on the solutions layer, and you still need the opportunity it serves.

Every solution rests on assumptions: things that must be true for it to work. Cagan names four risks to check before building: value (will customers choose to use or buy it), usability (can they work out how to use it), feasibility (can the engineers build it) and business viability (does it work for the rest of the business, including legal, financial and brand constraints). Torres adds categories such as desirability and ethics, and notes that the exact label matters less than generating assumptions across all of them.

To decide what to test first, she describes assumption mapping, an exercise she credits to David Bland. Rate each assumption on two things: how important it is to the idea's success, and how much evidence you already have. The riskiest assumptions are the critical ones for which you have little evidence. Test those, cheaply, before committing to a build.

For an AI feature, typical assumptions include "the assistant will give accurate answers from our content", "agents will trust it enough to use it", "it will cost less per case than the current process" and "it will not expose data it should not". Each can be tested with a small experiment before launch.

7. How to say what "better off" means

The final step in a brief is the sentence that most teams skip: how will the customer be better off, in their own terms? Use words they would use, and pick something you can observe.

Useful dimensions are time (they finish sooner or wait less), money (they pay less or lose less), effort (fewer steps, fewer contacts, fewer documents), errors (fewer mistakes or reworks) and confidence (they know what happens next). A satisfaction score can support the story but rarely carries it alone, because it moves for many reasons.

A usable statement has this shape: "For [segment], [measure] will move from [baseline, with source] to [target] within [window], without [guardrail] getting worse." For example, with the figures left for the team to fill in from its own data: "For customers who contact us about a delayed order, the share who need a second contact will fall from today's figure to a target agreed with the support lead within one quarter, without wrong-answer reports rising."

Two cautions apply.

• Customer benefit and company benefit are different columns. A feature might save the company money and cost the customer time, or the reverse. Keep both visible, so you can choose knowingly instead of finding out later.
• Use is not benefit. A customer may use a feature because it is the only route, or because it is prominent. Compare outcomes between people who used it and people who did not, or before and after, and be wary of reading a change as caused by your feature when something else (a season, a price change, a campaign) moved at the same time.

8. Where AI helps and where you decide

The pattern is consistent: AI drafts, you own the truth. The accountability in the Scrum Guide sits with a single person, and it does not transfer to a tool.

9. A short checklist to try on your own work

1. Pick one item from your current roadmap. Write the outcome it is meant to change in one sentence, without naming the feature.
2. Find the baseline for that outcome and note where it came from. If you cannot, that is your first task.
3. Name one leading measure, one lagging measure and one guardrail.
4. Write the problem statement with its evidence. Underline anything that is an assumption.
5. List the assumptions and rate each as critical or not, and well-evidenced or not.
6. Write the better-off sentence in your customer's words.

If the item survives these steps, you can explain why you are building it. If not, you have learned that cheaply.

10. How our course practises this

Weeks 1 to 3 of our AI-Enabled Product Ownership course work on exactly these skills: sorting measures, checking an AI-drafted update claim by claim, writing a brief without invented needs and testing assumptions. The graded exercises use dealt data and a fictional company, so you practise on material that cannot be copied from this page. The next guide in this pair, prioritising a backlog with AI, picks up from a clear outcome and shows how to order the work.

Sources and further reading

• Schwaber, K. and Sutherland, J. (2020), The Scrum Guide
• Cagan, M., SVPG, Product vs. Feature Teams
• Cagan, M., SVPG, The Four Big Risks
• Torres, T., Product Talk, Opportunity Solution Trees
• Torres, T., Product Talk, Assumption Testing
• Gartner (2025), Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027