From Opportunity Scores to Product Roadmap Priorities

The Prioritization Problem That Data Was Supposed to Solve

Every product manager I have worked with has experienced the same meeting. The roadmap review. Everyone has opinions. The VP of Sales wants the CRM integration because a large customer mentioned it. The VP of Engineering wants the architecture refactor because the technical debt is becoming untenable. The CEO wants the feature she saw at a competitor’s booth last month. The product manager has twelve user stories all tagged “high priority.”

Nobody has data. Everyone has conviction.

This meeting happens in companies that call themselves data-driven. It happens after customer advisory boards, after NPS surveys, after customer interviews. All of that research happened. None of it resolved the debate because it produced qualitative themes — “customers want more automation,” “usability is a concern,” “pricing is competitive” — that could be interpreted to support any position in the room.

Opportunity scores are different. They are the specific numeric output of the Outcome-Driven Innovation process that makes this debate resolvable. An opportunity score is not a sentiment. It is a calculation — importance plus the gap between importance and satisfaction — applied to each desired outcome that customers use to judge whether a product is doing its job well. When you sort 120 customer outcomes by opportunity score, the prioritization argument does not go away, but it becomes a data argument rather than a conviction argument. And data arguments have better endings.

This article explains what opportunity scores are, how they are calculated, and specifically how to translate them into product roadmap priorities without losing the strategic context that makes them meaningful.

The Opportunity Algorithm: A Quick Recap

Before discussing translation to roadmap, the calculation deserves brief explanation for readers who are not yet familiar with Ulwick’s opportunity algorithm.

Every desired outcome is rated by survey respondents on two dimensions:

• Importance: How important is it that you are able to accomplish this outcome? (Rated 1-10)
• Satisfaction: How satisfied are you with how well current solutions allow you to accomplish this outcome? (Rated 1-10)

The opportunity score is calculated as:

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

The logic: if importance exceeds satisfaction — if customers care about the outcome more than they are being served on it — that gap represents unmet need. If satisfaction exceeds importance, the outcome is overserved (current solutions are delivering more than customers care about), and the surplus does not add to opportunity.

In practice, scores range from roughly 2 to 20 on this scale. Ulwick’s interpretation:

• Scores above 10: Significant opportunity — these outcomes deserve product attention
• Scores above 12: Substantial opportunity — these are candidates for core product strategy
• Scores above 15: Major opportunity — these are “golden opportunities” that represent strong differentiation potential
• Scores below 8: Low opportunity — either adequately served or not important enough to prioritize

For a full treatment of the algorithm and how to design the survey that feeds it, see the opportunity algorithm guide.

The Gap Between Opportunity Scores and Product Decisions

Opportunity scores tell you what matters and where current solutions fall short. They do not automatically tell you what to build. The translation from score to roadmap item requires judgment at three distinct points, and understanding where judgment is required — and what principles should guide it — is the difference between using ODI well and using it poorly.

Gap 1: From Outcomes to Features

An opportunity score attaches to a desired outcome statement, not to a feature. “Minimize the time it takes to confirm that the configuration is correct before beginning the process” is an outcome. It does not specify a feature. Multiple features — some incremental improvements to existing capabilities, some entirely new product functions, some digital extensions of a physical product — might address this outcome.

The translation from outcome to feature requires ideation: generating candidate solutions that would address the underserved outcome and selecting from among them based on feasibility, cost, and strategic fit. This ideation phase is distinct from the measurement phase, and the separation matters. Teams that skip it — reading an opportunity score and immediately assigning a feature — often implement the most obvious solution without exploring whether a better one exists.

Gap 2: From Features to Priorities

Even with a list of features tied to high-opportunity outcomes, you face a prioritization within the high-opportunity space. Not every high-opportunity outcome can be addressed in the same product cycle. The factors that determine priority within the high-opportunity space include:

• Addressability: How much of the opportunity can current technology and team capability actually address? A high-opportunity outcome that requires a technology that is five years from maturity may not be actionable now.
• Coverage: Which features address the most outcomes simultaneously? A single feature that moves the needle on five high-opportunity outcomes is more valuable than five separate features each addressing one.
• Segment concentration: Is the high-opportunity outcome high across the entire market, or concentrated in a specific, strategically important segment?
• Competitive timing: Are competitors approaching this opportunity? The calculus of urgency changes when a competitor is six months from shipping a solution to your highest-opportunity outcome.

Gap 3: From Priorities to Roadmap

Translating priorities into a time-sequenced roadmap requires additional inputs beyond opportunity scores: development estimates, resource constraints, dependencies, and go-to-market timing. This is traditional product management work — and it is not replaced by ODI. What ODI does is provide the strategic inputs (which outcomes to prioritize) so that the traditional product management work is operating on the right foundation.

A Practical Framework: Translating Scores to Strategy

Here is the framework I use with clients to move from opportunity data to a structured roadmap. It takes the full set of scored outcomes and organizes them into strategic buckets before any roadmap decisions are made.

Step 1: Sort and Threshold

Take the full dataset of outcome scores and sort by opportunity score descending. Apply the threshold: mark everything above 10 as “in play,” everything below 8 as “out of play,” and the range 8-10 as “monitor.” This is not a final roadmap — it is a triage to focus the strategic conversation.

In a typical 120-outcome ODI dataset, you will have roughly 15-25 outcomes above score 10, 50-60 in the middle range, and the remainder below 8. The distribution tells you something immediately: if almost all outcomes are below 10, the market is well-served and you need to reconsider your strategy (reduce cost, not add features; or look for an entirely new job to address). If 60 outcomes are above 10, the market is dramatically underserved and the strategic question is where to prioritize in a target-rich environment.

Step 2: Segment the High-Opportunity Space

Before assigning features to high-opportunity outcomes, identify whether the opportunity is concentrated in one or more need-based segments. Run cluster analysis on the outcome importance data to identify groups of customers whose patterns of underserved needs differ from each other.

This step prevents a common mistake: designing a product that attempts to address all high-opportunity outcomes uniformly — producing something mediocre for everyone — when a targeted solution that addresses the most pressing outcomes for a specific segment would win that segment decisively.

For example, a 120-outcome survey for an industrial equipment job might reveal:

• Segment A (40% of market): Primarily underserved on precision and verification outcomes (Confirm and Execute stages)
• Segment B (35% of market): Primarily underserved on speed and documentation outcomes (Define and Conclude stages)
• Segment C (25% of market): Primarily underserved on remote monitoring and adjustment outcomes (Monitor and Modify stages)

A product strategy that attempts to address all three segments simultaneously will do none of them justice. A strategy that targets Segment A first — with a product configuration that addresses precision and verification outcomes — will win that segment and generate the revenue to fund the next product generation for Segment B.

Step 3: Map Outcomes to Existing Product Capabilities

Before generating new feature ideas, audit what your current product already does against the high-opportunity outcomes. In most ODI engagements, some portion of the high-opportunity outcomes are partially addressed by existing capabilities that are either not discoverable, not usable, or not positioned correctly.

This audit produces three categories:

• Outcomes currently well-addressed: These outcomes are high-importance but satisfaction is also high — they are not actually high-opportunity, which the scores confirm. You do not need to invest here.
• Outcomes partially addressed: Current capabilities touch these outcomes but don’t fully close the satisfaction gap. These are candidates for improvement rather than new development — often the fastest ROI.
• Outcomes not addressed at all: These require new feature development or adjacent product investment. These are where innovation investment is justified.

Step 4: Generate and Score Feature Ideas

For each cluster of high-opportunity outcomes not addressed by existing capabilities, run a structured ideation session. The brief for this session is specific: generate solutions that address these particular outcomes. Not “what features could we build?” but “how could we minimize the likelihood that a calibration error goes undetected before the process begins?”

After ideation, evaluate each candidate feature idea by scoring how many high-opportunity outcomes it addresses and how significantly it would move the satisfaction needle on each. Features that address multiple high-opportunity outcomes simultaneously — outcome coverage — are the ones to prioritize.

Step 5: Build the Evidence-Based Roadmap

With outcome-to-feature mapping complete, you have the inputs for a structured roadmap conversation:

• A ranked list of high-opportunity outcomes
• A set of feature ideas tied to those outcomes
• An outcome coverage score for each feature idea
• Segment concentration data showing which opportunities are largest and most strategically valuable

The roadmap conversation now has a factual basis. “We should build X” can be evaluated against “X addresses outcomes Y and Z, which score above 12 for Segment A, which represents 40% of the market and 55% of the revenue potential.”

This does not eliminate judgment — timing, resource constraints, and competitive context still require judgment. But it grounds the judgment in evidence rather than opinion.

A Real Example: Before and After

Let me describe a pattern I have seen repeated across multiple client engagements — anonymized but representative.

Before ODI: A €300M industrial equipment manufacturer has a roadmap driven by three inputs: the feature backlog (customer requests aggregated by sales), the technology roadmap (engineering’s view of what is technically achievable next), and the competitive response list (features competitors have shipped that the product lacks). Roadmap meetings are contentious. The VP of Sales dominates with volume of anecdotes. The VP of Engineering holds fast to the technology roadmap. The product manager mediates. The final roadmap is a negotiated compromise.

After ODI — the data: A 120-outcome survey across 400 respondents identifies that outcomes at the Define and Confirm stages score dramatically higher than outcomes at the Execute stage — where the current product is strongest and where the most recent engineering investment has been focused. The highest three scoring outcomes relate to: (1) determining the correct operating parameters for non-standard conditions, (2) confirming that all safety interlocks are properly configured for the specific application, and (3) documenting the completed operation for regulatory and maintenance records.

After ODI — the roadmap: The revised roadmap leads with a configuration guidance system (addresses outcomes 1 and 2), followed by an automated post-operation documentation tool (addresses outcome 3). Both are software features added to a physical product — not changes to the core mechanical engineering. They are faster and cheaper to develop than any of the mechanical improvements that were on the previous roadmap, and they address outcomes that were dramatically more underserved.

The outcome: the configuration guidance system, launched nine months after the ODI engagement concluded, became the most-cited factor in won deals within 18 months. The mechanical improvements it replaced on the roadmap were eventually shipped as a second priority.

Integrating Opportunity Scores into Ongoing Product Planning

Quarterly Roadmap Reviews

Once your ODI data is established, use opportunity scores as a standing reference in quarterly roadmap reviews. When a new feature request arrives from sales, from a customer advisory board, or from competitive monitoring, the first question is: “Which outcome does this address, and what is the opportunity score for that outcome?”

This does not mean low-opportunity features never get built. A feature that has a strategic account who will expand significantly because of it may be worth building even with a low opportunity score — the commercial context overrides the population-level data. But the conversation is explicit rather than implicit: “We are building this for commercial reasons, not because it addresses a broadly underserved need.”

Annual Outcome Re-Measurement

Opportunity scores are not permanent. As competitors improve their products, satisfaction with outcomes rises — and previously high-opportunity outcomes move out of the high-priority tier. Conversely, as markets evolve and customer contexts change, importance scores shift.

Build an annual re-measurement of outcome satisfaction into your customer research calendar. The job map and outcome statements from the original ODI engagement can be reused — the survey can be shorter and faster in subsequent years because the outcome set is already defined. What you are measuring is the change in satisfaction scores, which tells you whether your product investments are actually moving the needle and where new opportunities are emerging.

Connecting ODI to OKRs

One of the strongest organizational integrations I have seen is connecting ODI outcomes to OKRs (Objectives and Key Results). An outcome that scores high-opportunity becomes an objective: “Significantly improve how well we address the customer outcome [statement].” The key result is a defined improvement in customer satisfaction for that outcome, measured through the annual re-survey.

This connection makes ODI a standing part of the planning cycle rather than a periodic project. It also creates accountability: teams are measured not just on whether they shipped features but on whether those features actually improved customer satisfaction on the outcomes they were designed to address. For a broader view of how customer insights translate to product roadmaps across the full planning cycle, that extends this framework.

Common Mistakes in Translating Opportunity Scores to Roadmap

Treating every high-opportunity outcome as a separate roadmap item. If you have 20 high-opportunity outcomes and add 20 items to the roadmap, you have missed the opportunity for strategic synthesis. Look for the features that address clusters of related high-opportunity outcomes.

Prioritizing opportunity scores over commercial context. A high opportunity score in a segment that represents 5% of your market may be less strategically important than a medium opportunity score in a segment that represents 40% of your market. Opportunity scores are not standalone priorities — they are inputs to priority decisions that include strategic and commercial context.

Ignoring the overserved outcomes. Outcomes that score very low — high satisfaction, low importance — represent areas where you may be over-investing. These are candidates for simplification, cost reduction, or deprioritization. ODI tells you not just where to invest more but where to invest less.

Using opportunity scores to justify decisions already made. I have seen product managers who had their roadmap decisions made before the ODI data arrived, and used the data selectively to support their pre-existing conclusions. This is worse than not having the data, because it creates false confidence in decisions that are actually still driven by opinion.

The product teams that get the most from opportunity scores are the ones that let the data surprise them. If the data confirms everything you already believed, you either have excellent intuition or you have a measurement problem. In my experience, a properly executed ODI study almost always reveals at least one significant opportunity that nobody in the company expected — and that opportunity is almost always the most valuable one.

Frequently Asked Questions