ODI for Product Managers: A Practical Implementation Guide

The PM’s Dilemma: Everyone Has an Opinion, Nobody Has Data

If you are a product manager in a DACH enterprise company, your job looks something like this: You sit between engineering (who wants to build technically interesting things), sales (who wants whatever the last customer asked for), marketing (who wants whatever is trending), and leadership (who wants growth but not risk). Your role is to synthesize these competing inputs into a coherent product roadmap.

The problem: every input is anecdotal, political, or both. Sales brings you the voice of their biggest account. Engineering brings you the feature they have been prototyping on Friday afternoons. Marketing brings you a competitor’s press release. Leadership brings you a board-level strategy that sounds directional but is not specific enough to determine what goes into Sprint 14.

You need data. Not survey data that tells you customers rate your product 4.1 out of 5 (what do you do with that?). Not NPS data that tells you 40% are promoters (promote what, specifically?). You need data that tells you, at the level of specific customer needs, where the market is underserved — and by how much.

That is what Outcome-Driven Innovation provides. And this article is the practical guide to making it happen inside your organization.

Step 1: Decide Whether ODI Is Right for Your Situation

ODI is not for every product decision. It is a significant investment — 12-16 weeks and a meaningful budget for research. Before you pitch it internally, make sure it fits your situation.

ODI is right when:

• You are planning a major product generation or platform (not an incremental update)
• The cost of getting the direction wrong is high (>$1M in development, tooling, or opportunity cost)
• Internal stakeholders disagree on priorities and need a shared data set to align
• You are in a mature market where intuition-based differentiation has stopped working
• You suspect the market has shifted but cannot articulate how

ODI is not right when:

• You need a decision in 2 weeks (ODI takes 12-16 weeks)
• The decision is tactical (UI layout, color scheme, minor feature toggle)
• You have fewer than 100 addressable customers worldwide (survey validity issues)
• You are exploring a category so new that no job executors exist yet

Step 2: Build the Business Case for ODI

This is where most PM-driven ODI initiatives die: the pitch. You need to convince leadership to invest in a research methodology they have probably never heard of. Here is how.

Frame the Problem, Not the Solution

Do not start with “I want to do an ODI project.” Start with “We are about to invest $X million in our next product generation, and we do not have quantitative data on which customer needs are most underserved. Our current approach — customer visits, advisory boards, competitive analysis — produces opinions, not data. The risk of investing in the wrong direction is $X million plus 2-3 years of opportunity cost.”

Cite the Success Rate

The 86% success rate across the published ODI track record is your strongest argument. Compare it to the industry average of 10-28%. If your company has launched products that missed targets, reference those specifically (delicately): “Product Z missed its revenue target by 40%. Would we have made different decisions with quantitative data on customer needs? ODI provides that data.”

Quantify the Downside

What does a failed product generation cost your company? Not just the development cost — the opportunity cost, the market share loss, the morale impact, the time-to-market delay for the replacement. In most enterprise contexts, this number is 5-20x the cost of an ODI project.

Reference Peer Companies

If any of your competitors or peer companies have used ODI or similar approaches, mention them. In the DACH region, companies like Liebherr, Hilti, B.Braun, Palfinger, Eaton, and Teleflex have applied ODI. These are not startups experimenting with a trend — they are established enterprises with rigorous innovation processes.

Product managers often tell me: ‘I know we need better customer data, but I can’t get budget for research.’ My answer is always the same: you’re not asking for research budget. You’re asking for risk reduction on a multi-million dollar investment. Reframe it that way and the conversation changes.

Step 3: Assemble Your Team

A successful ODI project requires a cross-functional core team. As the product manager, you will likely lead the effort. Here is who you need:

You (Product Manager): Project lead. You own the job definition, drive the process, and translate results into product strategy.

A qualitative researcher (internal or external): This person conducts the in-depth interviews and translates customer language into outcome statements. This is the most specialized skill in the process — the ability to hear “I wish the handle were bigger” and capture “minimize the physical effort required to operate the device for extended periods.” If you do not have this skill internally, partner with an experienced ODI firm for your first project.

A quantitative analyst: Survey design, fielding, data cleaning, statistical analysis. This person needs experience with Likert-scale surveys, factor analysis, and cluster analysis. If your market research team has these skills, excellent. If not, this is another reason to partner externally for the first project.

An R&D representative: Technical feasibility assessment during strategy formulation and concept development. This person does not need to be involved in every meeting, but they need to understand the process well enough to evaluate concepts against outcome targets.

A marketing representative: Market sizing, segment profiling, and — critically — ensuring that the insights translate into marketing language. The Opportunity Landscape is a strategic tool; marketing needs to turn it into messaging.

A senior sponsor: Someone at the VP level or above who can protect the project’s budget and timeline when organizational priorities shift. Without a sponsor, ODI projects get killed in month 2 when quarterly targets tighten.

Step 4: Define the Job

This is your first deliverable, and it sets the scope for everything that follows. See The ODI Process for detailed methodology. Here is the practical guidance:

Involve your team, but own the decision. Job definition is a judgment call, not a consensus exercise. Gather input from R&D, marketing, and sales on how they think about the market. Then define the job using the standard syntax: verb + object + contextual clarifier.

Use the “too narrow / too broad” test. If the job can be completed in under 15 minutes, it is probably too narrow (that is a task, not a job). If it takes more than a day, it is probably too broad (that is multiple jobs).

Do not define the job around your product. “Use our Model X400 to process materials” is not a job. “Process raw materials to meet production specifications” is a job. The difference matters because the job-centric framing includes competitors, substitutes, and workarounds — giving you a complete market view.

Test the job with 3-5 customers. Before committing to the full qualitative phase, describe the job to a handful of customers and ask: “Is this something you do? Does this description capture the process accurately?” If they nod, you are on the right track.

Step 5: Run the Qualitative Phase

This is where the outcome statements are captured. If you are partnering with an experienced ODI firm, they will lead this phase. If you are running it internally, here is what matters:

Interview 15-30 job executors. Not buyers, not specifiers, not department heads — the people who actually do the job. In B2B, this is the operator, the surgeon, the technician, the assembly worker. In consumer markets, this is the end user.

Use the Job Map as your interview guide. Walk through the 8 Job Map stages (Define, Locate, Prepare, Confirm, Execute, Monitor, Modify, Conclude) and probe for outcomes at each stage.

Write outcome statements during the interview, not after. If you wait until after, you lose context. The best practice is to draft outcomes in real time and read them back to the customer for validation: “So what you’re saying is that you want to minimize the time it takes to verify that the load configuration matches the lift plan — is that right?”

Aim for 50–150 outcome statements. Fewer than 80 means you stopped too early or the job is too narrow. More than 175 means the job is too broad or your statements are too granular.

Step 6: Run the Quantitative Phase

The survey phase is logistically intensive but methodologically straightforward. Each outcome statement gets two questions (importance and satisfaction), answered by 180-600 respondents.

Practical Tips for Product Managers

Recruit broadly. Do not only survey your own customers. Include competitor users, former customers, and non-consumers (people who do the job without any formal product). Your customer base is a biased sample — they chose your product for a reason and may have systematically different needs than the broader market.

Set realistic timeline expectations. B2B surveys take 3-6 weeks to field, depending on the population size and accessibility. Consumer surveys can be faster (2-3 weeks with panel access). Do not promise results to leadership before the survey is complete.

Quality-check responses. Remove straight-liners (respondents who give the same rating for every question), speedsters (surveys completed in under 10 minutes for a 25-minute survey), and inconsistent respondents. Typically 10-15% of responses are removed in cleaning.

Run the Opportunity Algorithm. This is a straightforward calculation but the interpretation requires experience. For each outcome: Opportunity Score = Importance + max(Importance - Satisfaction, 0). For the full mathematics, see The Opportunity Algorithm.

Step 7: Present the Results to Leadership

This is the moment of truth. You have the Opportunity Landscape, the opportunity scores, and the segment analysis. Now you need to turn data into decisions.

Structure the Presentation

Start with the top 10 underserved outcomes. These are the punchlines — the specific, quantified customer needs that nobody in your organization knew about. Read the outcome statements aloud. Let the room absorb what customers actually care about.

Show the Opportunity Landscape. This single visual communicates more than 50 slides of traditional market research. Point out the clusters: “Here are the 14 outcomes where we have been investing — all appropriately served. Here are the 18 outcomes we have been ignoring — all severely underserved.”

Present the segments. Show that the “average customer” does not exist. Different groups want different things. This is often the most powerful slide for leadership, because it reframes strategic debates that have been stuck for months or years.

Connect to strategy. Based on the data, present 2-3 strategic options (differentiated, disruptive, discrete) with the outcomes each would target, the segment each would serve, and the investment required.

Handling Pushback

“But our biggest customer said they want X.” Show the opportunity score for X. If it is below 10, it is appropriately served — your biggest customer’s preference is not representative of the market. If it is above 12, great — include it.

“We already knew this.” If leadership claims to have known the top underserved outcomes, ask: “Then why did our last product roadmap not address them?” The Opportunity Landscape often confirms suspicions that nobody had the data to act on.

“This would require us to change our roadmap.” Yes. That is the point. If the current roadmap addressed the right outcomes, you would not need ODI. Present the cost of NOT changing: continued investment in outcomes that are already well-served while competitors eventually discover the underserved space.

We discussed this dynamic in detail in our podcast episode #48, where a product manager from Liebherr shared how he presented ODI results to his leadership team and redirected a major development program based on the data.

Step 8: Translate to Product Requirements

ODI outcome targets are not product requirements — they are design targets. The translation happens in concept development (Step 6 of the ODI process):

From outcome target to design brief:

• Outcome: “Minimize the time it takes to verify that the load configuration matches the lift plan” (Score: 15.7)
• Design brief: “Develop a system that enables operators to confirm load-lift plan alignment in under 30 seconds, compared to the current 5-minute visual inspection process.”

From design brief to product requirement:

• Requirement: “The system shall provide automated load identification and comparison against the active lift plan, displaying match/mismatch status within 30 seconds of load engagement, with 95% accuracy.”

The lineage is traceable: customer outcome → opportunity score → design brief → product requirement. This traceability is powerful for stakeholder management — every requirement on the roadmap can be justified by customer data.

For more on translating outcomes to product requirements, see JTBD and Product Requirements.

Building Internal ODI Capability

Most organizations partner with an experienced ODI firm for their first 2-3 projects, then gradually build internal capability. Here is the progression we recommend:

Project 1 (fully guided): An ODI partner leads the entire process. Your team observes and learns. This is the highest-cost project but builds foundational understanding.

Project 2 (co-led): Your team leads the qualitative research with coaching from the ODI partner. The partner leads the quantitative analysis and strategy phases. Your team gains hands-on interview experience.

Project 3 (internally led, externally reviewed): Your team runs the entire project. The ODI partner reviews outcomes, survey design, and analysis at key checkpoints. This confirms readiness for full independence.

Projects 4+: Fully internal. You may still engage an external partner for complex or high-stakes markets, but the core capability is in-house.

Skills to Develop

• Qualitative interviewing: The discipline to capture outcomes (not solutions) requires practice. Plan for 8-12 practice interviews before the first real project.
• Survey design: The ODI survey format is standardized, but adapting it to specific markets requires skill.
• Statistical analysis: Factor analysis, cluster analysis, and discriminant analysis. This typically requires a dedicated analyst or partnership with your market research function.
• Strategic synthesis: The ability to look at an Opportunity Landscape and see strategic options, not just data points.

The product managers who succeed with ODI share one trait: they treat it as a strategic investment, not a research project. They present it to leadership as risk mitigation, they staff it with their best people, and they commit to acting on the data — even when it contradicts their assumptions. That last part is the hardest.

Day-to-Day Impact: How ODI Changes Your Work

Once you have completed your first ODI project, your daily work changes in several ways:

Backlog prioritization becomes data-driven. Instead of debating which features matter most, you rank them by the opportunity scores of the outcomes they address. The feature that addresses a score-15 outcome gets priority over the one addressing a score-8 outcome, regardless of who requested it.

Stakeholder conversations become productive. When sales brings you a customer request, you can check it against the Opportunity Landscape: “That outcome scores 7.3 — it’s appropriately served. Let me show you the outcomes scoring 14+ that we should focus on instead.”

Roadmap presentations become compelling. Instead of “we think customers want X,” you present “we surveyed 280 customers and outcome #47 — minimize the likelihood that the bond fails under vibration — has an opportunity score of 15.0, making it the single largest unmet need in our market. Our next product addresses it.”

Cross-functional alignment improves. R&D, marketing, and sales can all look at the same Opportunity Landscape and see the same reality. Arguments shift from “whose customer insight is right” to “which outcomes should we target first” — a more productive debate.

Innovation becomes proactive. Instead of reacting to competitors or customer complaints, you are working from a map of opportunities that competitors have not yet discovered. This is the difference between following the market and leading it.

Common Mistakes Product Managers Make with ODI

Further Reading

• Outcome-Driven Innovation: The Definitive Guide
• The ODI Process: 6 Steps to Systematic Innovation
• How to Write Outcome Statements That Drive Product Decisions
• JTBD and Product Requirements