The Concept That Makes ODI Work
Every methodology has a core unit — the atom from which everything else is built. For Lean, it is waste. For Six Sigma, it is variation. For Outcome-Driven Innovation, it is the customer desired outcome.
A desired outcome is the metric a customer uses to measure success when executing a job to be done. Not what they want to buy. Not the feature they request. Not the problem they complain about. The outcome — the specific, measurable result they are trying to achieve at each step of the job.
This concept sounds simple. It is not. Getting it right requires understanding what desired outcomes are, what they are not, and how they differ from every other way companies have tried to capture “what customers need.” That distinction is the subject of this article.
What Is a Customer Desired Outcome?
A desired outcome is a statement that describes a specific metric of success, expressed from the customer’s perspective, when they are executing a job to be done. It is:
- Solution-free: It does not reference any product, feature, or technology.
- Stable over time: It does not change when new solutions enter the market.
- Measurable: It can be rated on importance and satisfaction scales.
- Actionable: It provides a clear target for product development.
Every desired outcome follows the standard format described in our Outcome Statements Guide:
Direction of improvement + Performance metric + Object of control
Example: “Minimize the time it takes to identify the correct adhesive for the substrate combination.”
This statement describes what the customer wants to achieve — not how. It remains valid whether the solution is a selection guide, an app, a color-coded labeling system, or an AI-powered recommendation engine. The desired outcome is stable; the solution space is infinite.
How Desired Outcomes Differ from Other “Customer Need” Concepts
The business world has no shortage of terms for what customers want: needs, wants, requirements, pain points, user stories, feature requests, voice of the customer. Most of these terms are used loosely, and the looseness is expensive. Here is how desired outcomes differ from each.
Desired Outcomes vs. Needs
“Customer needs” is the vaguest term in product management. It can mean anything from “they need faster delivery” (a solution) to “they need to feel confident” (an emotional state) to “they need 5G connectivity” (a technology specification).
Desired outcomes are a specific, disciplined subset of needs. They are functional performance metrics stated in a standard format. When someone says “customer needs” in a meeting, the statement could mean 10 different things. When someone says “desired outcome #47 has an opportunity score of 15.0,” it means exactly one thing.
Desired Outcomes vs. Wants
“Wants” are usually solution statements disguised as needs. “I want a bigger screen” is a want. The desired outcome behind it might be: “Minimize the time it takes to locate specific data on the display during operation.” By capturing the outcome instead of the want, you preserve the freedom to address the need with any solution — a bigger screen, a better information hierarchy, a search function, or a contextual filter.
Desired Outcomes vs. Requirements
Product requirements specify what a solution must do: “The device shall weigh less than 2 kg.” Requirements are solution-dependent — they assume a specific product form. Desired outcomes are solution-independent: “Minimize the physical effort required to transport the device between work sites.” Requirements are derived from desired outcomes, not the other way around. When a product manager writes a requirement without understanding the underlying outcome, they risk specifying the wrong solution.
Desired Outcomes vs. Pain Points
Pain points describe what frustrates customers today. “The calibration process takes too long” is a pain point. It is useful input but it conflates the need with the current solution’s failure. The desired outcome — “Minimize the time it takes to calibrate the device to specification” — is permanent. It applies whether the calibration takes 30 minutes or 30 seconds, because there is always a desire to minimize the time further. Pain points expire when the pain is fixed. Desired outcomes persist as long as the job exists.
Desired Outcomes vs. User Stories
User stories follow the format: “As a [user], I want [action] so that [benefit].” Example: “As a surgeon, I want a lighter instrument so that my hand doesn’t fatigue during long procedures.” This format has three problems from an ODI perspective: it includes a solution (“lighter instrument”), it implies a specific user context (“long procedures”), and it does not specify a measurable metric. The desired outcome version: “Minimize the physical effort required to operate the instrument for extended periods.” This is more precise, more measurable, and more open to creative solutions.
Desired Outcomes vs. Feature Requests
Feature requests are solutions, not needs. “Add Bluetooth connectivity” is a feature request. The desired outcome might be: “Minimize the time it takes to transfer operational data to the analysis system.” If you implement the feature request, you get Bluetooth. If you address the desired outcome, you might get Bluetooth, Wi-Fi, NFC, wired USB-C, or an automated sync-on-dock system — whichever best minimizes the transfer time.
Info
The Three Types of Desired Outcomes
ODI recognizes three types of desired outcomes, corresponding to the three dimensions of any job:
1. Functional Outcomes (85-90% of the total)
Functional outcomes describe measurable performance metrics related to the execution of the core job. They are the primary focus of ODI analysis.
Examples:
- “Minimize the time it takes to determine the optimal welding parameters for the joint configuration”
- “Minimize the likelihood that the coating thickness falls outside the specified tolerance range”
- “Maximize the ability to detect subsurface defects before they become visible”
These outcomes are objective, measurable, and directly addressable through product and service design.
2. Emotional Outcomes (5-10% of the total)
Emotional outcomes describe how the customer wants to feel while executing the job. They are subjective but still measurable (through importance and satisfaction surveys).
Examples:
- “Minimize the likelihood of feeling anxious about the procedure’s outcome during execution”
- “Maximize the feeling of confidence that the equipment will perform as expected”
- “Minimize the frustration associated with troubleshooting unexpected issues”
Emotional outcomes matter because they influence purchase decisions — sometimes more than functional outcomes. A product that performs flawlessly but makes the user anxious will lose to a product that performs well and builds confidence.
3. Social Outcomes (5-10% of the total)
Social outcomes describe how the customer wants to be perceived by others while executing the job.
Examples:
- “Maximize the likelihood of being perceived as competent by colleagues when operating the equipment”
- “Minimize the likelihood of being seen as responsible for delays caused by equipment failures”
- “Maximize the perception that the team is using state-of-the-art tools and methods”
Social outcomes are particularly important in professional contexts where reputation and credibility matter — which includes virtually every B2B market.
18 Example Desired Outcomes Across Industries
Medical Devices (Job: Repair damaged tissue to restore structural integrity)
- “Minimize the time it takes to assess the tissue’s structural condition before selecting a repair approach”
- “Minimize the likelihood that the repair device causes collateral tissue damage during placement”
- “Maximize the ability to predict the tissue’s healing trajectory based on the repair method used”
- “Minimize the number of repositioning attempts required to achieve optimal device placement”
- “Maximize the degree to which the repair maintains structural integrity under physiological loading”
Construction Equipment (Job: Lift and position heavy loads at a construction site)
- “Minimize the time it takes to determine the optimal lift path considering all site obstructions”
- “Minimize the likelihood that the load shifts during transport to the target position”
- “Maximize the ability to anticipate weather changes that affect lift safety during the operation”
- “Minimize the number of communication errors between the operator and ground crew during positioning”
- “Minimize the time it takes to verify that the landing zone is prepared and clear for load placement”
Agricultural Equipment (Job: Prepare soil to optimal conditions for crop establishment)
- “Minimize the variability in tillage depth across the working width of the field”
- “Maximize the ability to adjust operational parameters in real time based on changing soil conditions”
- “Minimize the amount of fuel consumed per hectare while maintaining target soil quality”
- “Minimize the time it takes to transition the equipment between field configurations”
Industrial Adhesives (Job: Create a permanent bond between dissimilar materials)
- “Minimize the time it takes to achieve full bond strength after application”
- “Minimize the sensitivity of bond quality to ambient temperature variation during curing”
- “Maximize the ability to verify bond integrity without destructive testing”
- “Minimize the amount of surface preparation required before adhesive application”
When I train product managers to recognize desired outcomes, I use a litmus test: read the statement aloud and ask, ‘Does this tell me what to build, or does it tell me what the customer wants to achieve?’ If it tells you what to build, it’s a solution — rewrite it. If it tells you what the customer wants to achieve, and it follows the Direction + Metric + Object format, it’s a desired outcome.
Why 50–150 Outcomes Per Job?
New teams are often surprised by the volume: 50–150 outcome statements for a single job. Why so many?
Jobs are more complex than they appear. A surgeon does not just “repair tissue.” She assesses the damage, selects an approach, prepares the site, positions the device, executes the repair, monitors the result, adjusts if necessary, and verifies the outcome. Each step has 8-15 desired outcomes. Across 10-12 steps, that produces 50–150 outcomes.
Granularity enables precision. If you capture only 30 outcomes, you have a blurry picture of the market. High-level outcomes (“minimize the time to complete the job”) will score high on importance but provide no design direction. Specific outcomes (“minimize the time it takes to verify that the torque specification has been met”) provide actionable design targets.
Completeness enables discovery. The outcomes that score highest on the Opportunity Algorithm are often ones that nobody in your organization has considered. They appear in the 80th or 120th interview, in a step of the Job Map that your product does not currently address. If you stop at 50 outcomes, you miss these.
Coverage enables segmentation. Outcome-based segmentation requires enough outcomes to detect statistical patterns. With 30 outcomes, you can identify 2 segments at most. With 150 outcomes, you can distinguish 4-5 segments with distinct opportunity profiles — producing far more targeted strategies.
Capturing Desired Outcomes: The Process
Desired outcomes are captured through qualitative interviews, structured around the Job Map. The full interview process is described in The ODI Process. Here is a summary of the key principles:
1. Interview Job Executors, Not Buyers
The person who does the job — the surgeon, the crane operator, the assembly technician — is the source of desired outcomes. The person who buys the product may have a completely different set of priorities (price, vendor relationships, procurement policies). Both matter for your business, but only the executor’s outcomes belong in the ODI analysis.
2. Use the Job Map as Your Framework
The Job Map ensures comprehensive coverage. By walking through every stage of the job — from Define through Conclude — you systematically probe for outcomes that the customer might not mention in an unstructured conversation. The most valuable outcomes often emerge in the “boring” stages (Prepare, Confirm, Monitor) that customers do not think to discuss unprompted.
3. Translate Customer Language into Outcome Format
Customers do not speak in outcome statements. They say: “The worst part is not knowing if it’s going to hold.” Your job is to translate: “Minimize the likelihood that the bond fails under operational load” and “Minimize the uncertainty about bond integrity after assembly.” One customer statement often yields 2-4 outcome statements.
4. Validate Immediately
After writing an outcome statement, read it back to the customer: “What I hear you saying is that you want to minimize the likelihood that the bond fails under operational load. Is that accurate?” This validation step catches misinterpretations and often triggers additional outcomes: “Yes, exactly — and also minimize the time it takes to detect if a bond is failing before it becomes a safety issue.”
5. Reach Saturation
Continue interviewing until new interviews produce fewer than 2-3 new outcomes. This typically requires 15-30 interviews. Interviews 1-8 produce the obvious outcomes that most people share. Interviews 9-20 produce the distinctive outcomes that differentiate segments. Interviews 20-30 confirm saturation.
From Outcomes to Opportunity
Individual desired outcomes are building blocks. Their power emerges when they are:
Quantified through survey research — each outcome rated on importance and satisfaction by 180-600 respondents.
Scored using the Opportunity Algorithm — producing opportunity scores that range from 0 to 20.
Visualized on the Opportunity Landscape — revealing clusters of underserved, appropriately served, and overserved outcomes.
Segmented using cluster analysis — identifying groups of customers with systematically different patterns of unmet outcomes.
Targeted in product strategy — selecting the cluster of underserved outcomes that your capabilities can best address.
This progression — from raw customer language to quantified strategic targets — is what makes ODI unique. No other innovation methodology captures customer needs at this level of specificity and then quantifies them with this level of rigor.
The Stability of Desired Outcomes
One of the most strategically valuable properties of desired outcomes is their stability. Because they describe what customers want to achieve (not how), they remain valid even as technologies change.
Consider the desired outcome: “Minimize the time it takes to transfer measurement data to the analysis system.”
This outcome was valid when data was transferred by hand-written notes (1960s), by floppy disk (1990s), by USB cable (2000s), by Wi-Fi (2010s), and by cloud sync (2020s). Each era produced a different solution. The outcome has not changed.
This stability has a powerful strategic implication: ODI data remains valid for 5-10 years. Importance scores rarely shift dramatically in the short term (the job does not change). Satisfaction scores can shift when competitors launch new products, but even then, only a subset of outcomes is affected.
Contrast this with traditional market research, which typically focuses on product features and competitive positioning — data that becomes stale within 6-12 months as competitors respond and technologies evolve.
Common Questions About Desired Outcomes
Further Reading
- Outcome-Driven Innovation: The Definitive Guide
- How to Write Outcome Statements That Drive Product Decisions
- What Is ODI? Outcome-Driven Innovation Explained
- Functional, Emotional, and Social Jobs
Want to Discover Your Customers' Desired Outcomes?
Book a complimentary discovery call to explore how these ideas apply to your organization.
