Recommended resources
The freely available resources this lesson will direct you to.
Good to see you again. Last lesson distinguished delivering an initiative from deciding whether it created value. You noted that a feature can be released successfully without improving anyone’s work. This lesson turns that distinction into a practical skill: rewriting a delivery commitment as a measurable customer outcome and a related business outcome.
Allow about 40 minutes, including the short resources and a portfolio note. We’ll use the AI-assisted support-ticket summary from the previous lesson, but the method applies just as well to an ordinary software feature.
Start with what changes, not what ships
Consider the commitment, “Deliver an AI feature that drafts support-ticket summaries by the end of the quarter.” It tells a delivery team what to produce and when. It does not tell a product team why that feature deserves investment or how to recognise success after release.
The distinction is visible in this example from ProdPad:
The output is within the team’s direct control: it can build and release the tutorial. The outcome depends on what people do after encountering it. Even the image’s “increase activation by 30%” would need a defined starting rate, target group and measurement period before a team could use it as a precise success criterion.
For a concise explanation, watch NNgroup’s Outcomes Over Outputs. Notice that the proposed solution comes after identifying and checking the problem, not before it.
NNgroup’s “Outcomes Over Outputs” defines the distinction, then gives a short sequence for setting a useful target.
Watch the distinction between something produced and the improvement it is meant to create. Then watch the four steps, from stating and checking the problem to defining success and testing possible solutions. Focus on why setting a target does not remove the need to verify that the problem is real.
A delivery milestone still matters. If the feature is never released, it cannot help users. But “released by 30 June” answers a different question from “agents spend less time preparing accurate handovers.” Product management needs both kinds of information without mistaking one for the other.
Connect the user’s gain to the organisation’s gain
An outcome statement becomes more useful when it names whose result is expected to change. In a services engagement, distinguish the people using the software from the client organisation paying for it. A client sponsor accepting a release is not the same as support agents finding handovers easier; neither automatically proves the client has gained enough value to justify the investment.
Productside’s article Great Outcome Statements: Move from Outputs to Outcomes, by Tom Evans, offers a helpful distinction between customer-behaviour outcomes and organisational goals. Read its examples before looking at the worked conversion below.
Great Outcome Statements: Move From Outputs To Outcomes
Read Productside’s distinction between business and product outcomes, then its example of connecting those outcomes to a possible feature.
Near the start, begin at the paragraph introducing two kinds of outcomes. Read the definitions and examples through “Business Outcomes: The Organizational ‘Why’” and the beginning of “Product Outcomes: The Customer Impact.” Notice why delivering an AI feature is listed as a weak business goal. Later, under “Aligning Stakeholders around Outcomes,” find the “Outcome Tree Framework.” Begin with its first numbered step and read the connected example through the paragraph beneath it. Treat the feature in that example as a proposed means, not a guaranteed cause of the result.
For our purposes, write two linked statements:
- Customer outcome: A measurable improvement in the support agents’ work—for example, less time spent preparing a handover that is still accurate.
- Business outcome: A measurable benefit to the client organisation—for example, lower paid overtime cost associated with handovers.
The proposed link between them is a hypothesis. Faster preparation might reduce overtime cost. It might not, if agents use the saved time on other work, if overtime has another cause, or if reviewing inaccurate drafts takes longer than writing summaries manually. Stating both outcomes makes that uncertainty visible instead of hiding it behind a feature request.
Rewrite a delivery initiative: one worked example
Return to the original initiative:
Delivery-focused: “Build and release an AI-assisted support-ticket summary feature for the client by the end of the quarter.”
Before rewriting it, identify the suspected problem: during escalations, support agents may spend substantial time assembling information for the next agent. We have not yet established how often that happens or whether an AI draft would help. The outcome statements below are therefore proposed targets, not claims about actual performance.
Customer outcome: “For escalated tickets handled by the pilot support team, reduce the median active time agents spend preparing and reviewing each handover from a hypothetical baseline of 12 minutes to 9 minutes or less during an eight-week pilot, without increasing handovers that omit critical information.”
Client business outcome: “For that team, reduce paid overtime cost logged against handover work from a hypothetical €1,000 to €750 or less per 100 eligible escalated tickets during the eight-week pilot, without a deterioration in handover quality.”
The release commitment has not disappeared. It is now a candidate output that might help achieve those outcomes, alongside other possible approaches. Perhaps clearer ticket fields or a better handover template would solve much of the problem without AI. The outcomes give the team a reason to compare alternatives.
Notice what makes the rewrite measurable. It identifies the population (eligible escalated tickets in one pilot team), the starting point and target, the time window, and what will be counted. “Median active time” includes reviewing a draft, not just generating it. “Cost per 100 eligible tickets” accounts for changes in ticket volume better than a raw monthly cost. A quality check matters because a quick but incomplete handover is not a customer improvement.
The numbers are illustrative. In your own initiative, do not invent a baseline and present it as measured fact. If the team does not record handover time or attributable overtime cost, mark those baselines as to be established. You could observe a sample of handovers and check with the client’s operations lead whether the proposed cost measure is available and meaningful. If it is not, agree on a different business measure rather than forcing a precise-looking number onto unreliable data.
Nor would meeting both targets automatically prove the AI feature caused the improvement. Ticket complexity, staffing or other process changes could also affect the results. At this stage, the task is to state what success would look like and what evidence would be needed—not to claim an effect before testing it.
A compact method for your own initiatives
When a request arrives as “build,” “launch” or “integrate,” keep the delivery commitment, then add a separate outcome layer. Start by naming the user and the difficulty the request is intended to address. Describe a change in that user’s experience or behaviour that could be observed, and connect it to a result the investing organisation cares about. Finally, specify the population, measure, baseline status, target and time period for each statement.
One useful check is to temporarily remove the proposed feature name. “Reduce handover preparation time while preserving accuracy” remains a meaningful goal without mentioning AI summaries. “Launch AI summaries” does not. A second check is to ask whether success could be declared on release day: if so, the statement probably still describes an output.
For your portfolio, spend about eight minutes saving a short before-and-after note from a real delivery initiative you know. Use this structure:
Original delivery commitment: What was to be shipped, and by when.
Intended user and problem: Name the user and the suspected difficulty; label anything not yet verified.
Proposed customer outcome: Population, observable change, measure and time window.
Proposed business outcome: Beneficiary organisation, measure and time window.
Evidence status: Record which baselines exist, which need checking, and who would be able to confirm them.
Keep your historical accountability accurate: proposing these statements now does not mean you owned the product decision on the original engagement. The portfolio value lies in showing how you would frame that decision and seek evidence for it.
Conclusion
An output is what a team delivers; an outcome is a beneficial change that delivery is intended to produce. A useful rewrite names both the customer improvement and the business result, gives each an observable measure, and labels unverified baselines and causal assumptions honestly. The feature remains a possible way to achieve success, not the definition of success.
Next, you’ll map where this kind of question belongs across product discovery, validation, delivery, launch and iteration—so you can see when to investigate the problem, when to build, and when to judge the result.