Desired Outcome

Origin & evolution

The desired outcome is the core construct of Outcome🏆OutcomeStrategyA desired business or user outcomeView reference →-Driven Innovation, developed by Anthony Ulwick beginning in 1991 and set out in his book What Customers Want (2005). Ulwick built it on the Jobs-to-be-Done theory: a customer hires a product to get a job done, and while executing that job they use a set of metrics to measure success. Those metrics are the desired outcomes. He defined them as a special kind of need statement, distinguished from a job by being a measure rather than a task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →.

Ulwick gave the statement a rigid grammar so it could be measured and compared. A well-formed desired outcome has a direction of improvement (minimise, increase), a unit of measure (the time, the likelihood, the number of), an object of control, and a contextual clarifier. The structure is what makes the statement stable and survey-ready, because two customers reading it interpret it the same way.

The method's distinctive move is quantification. Customers rate each desired outcome twice, on a scale, for importance and for current satisfaction. Ulwick's opportunity algorithm combines the two, weighting importance roughly double, to score where the gap between what matters and what is satisfied is widest. Those high-opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → outcomes, important and underserved, are where innovation pays off. The approach has held its shape for three decades because the rigidity is the point: loose outcome statements cannot be prioritised, and prioritisation is what the whole method exists to do.

How it works in practice

A team building software for field technicians runs an outcome study on the job "diagnose an equipment fault on site." They surface around forty desired outcomes and survey two hundred technicians, who rate each on importance and satisfaction from one to five.

Most outcomes cluster as important and already well served, so they are left alone. Two stand out as important and poorly satisfied: "minimise the likelihood of misidentifying the faulty component" and "minimise the time to confirm the right replacement part is in the van." Both are pure measures with no solution attached, which is what lets the survey rank them honestly. The team now has an evidence🔎EvidenceValidationData supporting or refuting a hypothesisView reference →-ranked target. The eventual feature, an on-device diagnostic that cross-checks van inventory, was never named in the research; it was derived from two outcomes the customers themselves rated as the biggest gaps.

Desired outcome vs. its neighbours

• Job to be done: a job is the overall task the customer is trying to accomplish. A desired outcome is one of the metrics they use to measure success at that job. A single job typically has dozens of desired outcomes hanging off it.
• Need: a need is the broad statement that something is lacking. A desired outcome is the specific, measurable, solution-free form of a need, structured tightly enough to be rated and ranked. Every desired outcome is a need; not every need is written precisely enough to qualify.
• Outcome (strategic): the strategic outcome measures a change in the organisation's results, such as retention. A desired outcome measures the customer's success at their own job. One belongs to the business; the other belongs to the user.

In the graph

In the Unified Product Graph, desired_outcome🌟Desired OutcomeUserWhat the user hopes to achieve is a leaf in the Users & Needs region, anchored to the persona🎭PersonaUserAn archetype representing a user segmentView reference → who holds it. It carries Ulwick's two ratings directly as structured properties, importance and current_satisfaction, each with a numeric value and a qualitative label, which is what lets a graph reconstruct the opportunity score. It is reached through persona_aspires_to_desired_outcomePersonaaspires toDesired Outcomehierarchy, job_motivates_desired_outcomeJobmotivatesDesired Outcomecausal, need_measured_by_desired_outcomeNeedmeasured byDesired Outcomecausal, and insight_reveals_desired_outcomeInsightrevealsDesired Outcomecross-domain. That last edge keeps the construct honest: a desired outcome revealed by an insight🔦InsightUser ResearchA synthesised finding from researchView reference → is evidence-backed, while one floating with no inbound edge is an assumption🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference → a team has not yet earned.