A solution-free metric a customer uses to judge job performance, the stable target for opportunity sizing.
A desired outcome is a measurable metricMetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → a customer uses to judge how well they are getting a jobJobUserJob To Be Done: what the user is trying to accomplishView reference → done, written without reference to any solutionSolutionDiscoveryA proposed approach to address an opportunityView reference →. "Minimise the time it takes to detect a billing error" is a desired outcome; "add a billing-alert dashboardDashboardData & AnalyticsAn analytics dashboardView reference →" is not. A desired outcome is solution-free, stable over time, and measurable, the three properties that let a team prioritise dozens of them in a survey and find the few that are important and badly served today.
The desired outcome is the core construct of OutcomeOutcomeStrategyA 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 taskTaskProduct 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-opportunityOpportunityDiscoveryA 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.
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 evidenceEvidenceValidationData supporting or refuting a hypothesisView reference →-ranked target. The eventual featureFeatureProduct SpecificationA product capability or featureView reference →, 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.
In the Unified Product Graph, desired_outcomeimportance 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_outcomejob_motivates_desired_outcomeneed_measured_by_desired_outcomeinsight_reveals_desired_outcome
Worked example: Trellis
Nora's desired outcome is a working, trusted internal tool she reached by describing a process, one the agent keeps adapting without her losing control of it. Where the needNeedUserA user need, pain, desire, or constraintView reference → names governed autonomy as the gap, the desired outcome names the end state: a tool the team depends on, maintained by an agent Nora has approved and can roll back.
Critical Dealbreaker if absent
Very unsatisfied Current solution fails completely
Type-specific fields on BaseNode
statementstringOutcome statement in the user's words
importanceassessmentHow important this outcome is to the user (1 = low, 5 = critical)
current_satisfactionassessmentHow satisfied the user currently is with this outcome (1 = very unsatisfied, 5 = fully satisfied)
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
6 edge types connected to this entity.
insight_reveals_desired_outcomeneed_measured_by_desired_outcomedesired_outcome_reveals_opportunitydesired_outcome_quantified_by_metric3 frameworks use this entity type.