How to combine jobs-to-be-done interviews with outcome-driven innovation scoring to prioritize product opportunities

Product teams rarely struggle to generate ideas. The harder problem is figuring out which ideas matter most—which ones address real, underserved customer needs rather than assumptions that sound plausible in a planning meeting.

Two frameworks address this problem from complementary angles. Jobs-to-be-done (JTBD) interviews uncover what customers are actually trying to accomplish and why current solutions fall short. Outcome-driven innovation (ODI) scoring takes those findings and quantifies them, producing a clear ranking of opportunities based on where customer needs are most underserved.

Used together, JTBD interviews and ODI scoring create a research-to-prioritization pipeline that grounds product decisions in evidence. This article walks through how to combine the two methods, step by step.

A quick primer on each framework

Jobs-to-be-done interviews

JTBD is a research lens that focuses on the underlying purpose behind a customer's behavior. Instead of asking what features people want, a JTBD interview explores the circumstances that led someone to "hire" a product, what progress they were trying to make, and what trade-offs they considered along the way.

The output of JTBD interviews is typically a job map—a sequence of steps the customer goes through to accomplish their core job—along with a set of desired outcomes: the specific criteria customers use to judge whether each step is going well.

For example, a project manager using a scheduling tool might have the core job of "coordinating team capacity across multiple projects." One desired outcome within the planning step might be "minimize the time it takes to identify scheduling conflicts." Another might be "reduce the likelihood of overallocating a team member."

These outcomes are precise, measurable, and free of solution language. That precision is what makes them useful as inputs into the next step.

Outcome-driven innovation scoring

ODI is a framework developed by Tony Ulwick that treats innovation as a measurable process rather than an act of intuition. Its central mechanism is the opportunity score, calculated from two survey inputs:

• Importance: How important is this outcome to the customer?
• Satisfaction: How satisfied is the customer with how current solutions deliver on this outcome?

The formula is straightforward:

Opportunity = Importance + max(Importance − Satisfaction, 0)

An outcome that is highly important but poorly satisfied represents a large, underserved opportunity. An outcome that is highly important and highly satisfied is already well served—investing there yields diminishing returns. An outcome that is unimportant is, regardless of satisfaction, not worth prioritizing.

The result is an opportunity landscape: a ranked list of outcomes that tells you exactly where customer needs are most acute.

Why combine the two methods

Each method has a gap the other fills.

JTBD interviews are excellent at uncovering outcomes you would never have discovered through feature requests, support tickets, or competitive analysis. But qualitative research alone cannot tell you how widespread a need is or how it ranks against dozens of other needs. A single compelling interview quote can distort prioritization if it is not validated at scale.

ODI scoring provides that quantitative rigor. But the survey is only as good as the outcomes it measures. If you populate an ODI survey with outcomes derived from internal brainstorming or feature wishlists rather than actual customer language, you risk measuring the wrong things entirely.

Combining the two methods means your qualitative research generates the right inputs, and your quantitative research ranks them with precision. The result is a prioritization framework that is both deeply grounded in customer reality and defensible in cross-functional planning conversations.

Step 1: Define the core functional job

Before conducting interviews, establish clarity on the job you are studying. A core functional job is a statement that describes what the customer is trying to accomplish, independent of any product or technology. It should be stable over time—the job of "managing personal finances" has existed for centuries, even as the tools have changed dramatically.

Write the job statement using the format: [verb] + [object] + [contextual clarifier]

Examples:

• Coordinate team capacity across multiple projects
• Diagnose the root cause of a software performance issue
• Prepare a quarterly business review for executive stakeholders

A well-defined job scopes your research. It tells you who to interview, what questions to focus on, and when you have drifted off topic.

Step 2: Conduct JTBD interviews

Recruit 12–20 participants who have recently performed the job you are studying. "Recently" matters because you need concrete memories, not abstract preferences. People who completed the job in the past 30–90 days can walk you through specific events, decisions, and frustrations with enough detail to be useful.

Interview structure

A productive JTBD interview typically lasts 45–60 minutes and follows this general arc:

1. Set context. Ask the participant to describe their role, the environment they work in, and how often they perform the job.
2. Walk through the timeline. Ask them to reconstruct a specific recent instance of performing the job from beginning to end. Where did they start? What steps did they take? What tools or workarounds did they use?
3. Probe for desired outcomes. At each step, ask what they were trying to achieve, what made the step difficult, what could go wrong, and how they judged whether they had done the step well.
4. Explore switching and trade-offs. Ask about previous solutions they have tried, why they switched, and what compromises they currently accept.

Record and transcribe every interview. The exact language customers use is critical—it becomes the raw material for outcome statements.

Extracting outcomes from interview data

After interviews, review transcripts to identify desired outcomes. Each outcome should follow a consistent format:

[Direction of improvement] + [unit of measurement] + [object of control]

For example:

• Minimize the time it takes to identify scheduling conflicts
• Reduce the likelihood of overallocating a team member
• Increase the accuracy of project timeline estimates

Strip out solution language. "I wish the tool had a drag-and-drop calendar" is a feature request, not an outcome. The underlying outcome might be "minimize the effort required to reschedule a task."

Aim for 80–150 outcomes across all steps of the job map. This may seem like a large number, but a well-researched job typically produces this range. Each outcome represents a specific criterion the customer uses to evaluate success.

Tools like Dovetail can significantly streamline this stage. Tagging and clustering interview transcripts in a shared workspace helps research teams collaboratively identify outcome patterns across multiple interviews, reducing the risk of individual bias in the extraction process.

Step 3: Organize outcomes into a job map

Group the extracted outcomes under the job steps where they naturally belong. A job map is not a user flow or a process diagram—it represents the universal structure of the job, independent of any specific product.

A typical job map follows this sequence:

1. Define — Determine what needs to be accomplished
2. Locate — Gather the necessary inputs
3. Prepare — Set up the environment or materials
4. Confirm — Verify readiness before execution
5. Execute — Carry out the core task
6. Monitor — Track progress and performance
7. Modify — Make adjustments as needed
8. Conclude — Finish and wrap up

Not every job includes every step, and some jobs require additional steps. The map gives you a visual structure for seeing where outcomes cluster, which often reveals which parts of the job are most complex or problematic.

Step 4: Design and deploy the ODI survey

With your outcome list finalized, build a survey that asks two questions for each outcome:

1. How important is this outcome to you? (1–10 scale)
2. How satisfied are you with how your current solution delivers on this outcome? (1–10 scale)

Survey design considerations

• Keep outcome language consistent with what you extracted from interviews. Do not rephrase outcomes into marketing language or internal jargon.
• Randomize order to prevent position bias, especially with long outcome lists.
• Include a screener to ensure respondents actually perform the job you are studying.
• Segment your audience if you suspect different customer types may have different importance and satisfaction profiles. ODI is most powerful when you can compare opportunity scores across segments.

Aim for at least 100 completed responses per segment you want to analyze. Larger samples (200+) give you more confidence in the results, especially when importance and satisfaction scores are close.

Step 5: Calculate opportunity scores and build the opportunity landscape

For each outcome, calculate the opportunity score:

Opportunity = Importance + max(Importance − Satisfaction, 0)

Then rank all outcomes by opportunity score from highest to lowest. The top of the list represents your most underserved customer needs.

Interpreting the scores

Score range	Interpretation
Above 10	Significantly underserved — strong opportunity
6–10	Moderately underserved — potential opportunity
Below 6	Adequately served or unimportant — low priority

Plot outcomes on a two-axis chart with importance on the Y-axis and satisfaction on the X-axis. This visualization—sometimes called the opportunity landscape—makes the strategic picture immediately clear:

• Top-left quadrant (high importance, low satisfaction): Underserved needs. Your best opportunities.
• Top-right quadrant (high importance, high satisfaction): Table stakes. You need to maintain parity but will not differentiate here.
• Bottom-left quadrant (low importance, low satisfaction): Not worth addressing.
• Bottom-right quadrant (low importance, high satisfaction): Overserved. You may be over-investing.

Step 6: Map opportunities to product decisions

An opportunity score alone does not tell you what to build. It tells you where to focus. The translation from opportunity to product decision involves several additional considerations:

Cluster related outcomes. Several high-scoring outcomes may relate to the same job step. Addressing them together through a single feature or workflow redesign is often more efficient than tackling each one independently.

Assess feasibility. Some underserved outcomes may require technology that does not yet exist or organizational changes beyond your team's control. Factor in technical and organizational feasibility alongside opportunity size.

Validate with qualitative context. Return to your interview transcripts to re-read the stories behind the highest-scoring outcomes. The quantitative score tells you the outcome matters. The qualitative data tells you why, which informs how you design a solution.

This is another area where having your qualitative data organized in a single platform pays off. When your JTBD interview transcripts, outcome extractions, and thematic tags live alongside your quantitative findings—as they can in Dovetail—moving between the score and the story behind it becomes a natural part of the prioritization workflow rather than a cumbersome cross-referencing exercise.

Common pitfalls to avoid

Writing vague outcomes. "Improve the user experience" is not an outcome. Every outcome must specify a direction (minimize, reduce, increase), a measurable unit (time, likelihood, accuracy), and an object (what is being measured). Vague outcomes produce meaningless scores.

Surveying the wrong people. If your survey respondents do not actually perform the job, their importance and satisfaction ratings will be unreliable. Screen rigorously.

Skipping qualitative research. Running an ODI survey with internally generated outcomes defeats the purpose. The power of the method depends on measuring outcomes that come from real customer language and experience.

Over-indexing on a single segment. Opportunity scores can vary dramatically across customer segments. An outcome that is well served for enterprise customers may be deeply underserved for small teams. Analyze segments independently before making portfolio-level decisions.

Treating scores as absolute truth. ODI scoring is a prioritization tool, not a decision-making algorithm. Scores should inform product strategy alongside business objectives, competitive dynamics, and technical constraints.

How this approach changes roadmap conversations

When product teams bring ODI-scored opportunity data into planning discussions, the nature of the conversation shifts. Instead of debating whose idea is best or which stakeholder has the most influence, the team can point to a specific underserved outcome, reference the customer interviews that surfaced it, and discuss how to address it.

This does not eliminate judgment—teams still need to weigh feasibility, effort, and strategic fit. But it replaces opinion-driven prioritization with evidence-driven prioritization. It also creates a shared vocabulary across product, design, engineering, and leadership. Everyone can see why a given area was prioritized, and the reasoning is traceable back to customer data.

For research teams, this combination of JTBD and ODI also elevates the impact of research itself. Qualitative insights are no longer just interesting findings in a report—they become the foundation of a quantified prioritization framework that directly shapes what gets built.

Getting started

If you are new to this approach, start small. Pick a single core job that is central to your product's value proposition. Conduct a focused set of JTBD interviews, extract outcomes carefully, and run a modest ODI survey. The first cycle will teach you more about the mechanics of the process than any amount of reading.

As you build the muscle, the methodology scales. You can study multiple jobs, compare opportunity scores across customer segments, and track how scores shift over time as you ship improvements. The combination of qualitative depth and quantitative precision creates a research practice that consistently surfaces the opportunities most worth pursuing.