From Customer Insights to Product Roadmap: The Translation Problem

The Insight Graveyard

Every enterprise innovation team has one. A folder — digital or physical — full of research reports that nobody reads anymore. Customer interview transcripts. Ethnographic studies. Survey results. Design sprint outputs. Personas that were workshopped with great enthusiasm and then never referenced again.

This is the insight graveyard. And its existence reveals the central failure of most enterprise product organizations: the inability to translate customer insights into roadmap decisions.

The research team produces insights. The product team nods. And then roadmap decisions are made the same way they always were — through a combination of executive opinion, competitive reaction, sales team pressure, and engineering enthusiasm. The insights sit in the graveyard, occasionally exhumed for a slide deck but never used to make a decision.

This is not a research quality problem. I have seen excellent customer research ignored because the product organization lacked a mechanism for converting findings into priorities. And I have seen mediocre research acted upon because it happened to confirm what the VP already believed.

The problem is structural. Most organizations have no systematic process for translating “here is what we learned about customers” into “here is what we will build, in what order, and why.” This article addresses that structural gap.

Why the Translation Fails

Gap 1: Insights Without Prioritization

Most customer research produces a list of findings. “Customers want faster changeovers.” “Maintenance is a pain point.” “The interface is confusing.” “Customers would like better reporting.”

These findings are all true. They are all potentially actionable. And they are all useless for roadmap decisions unless they are prioritized. How much faster do changeovers need to be? How many customers care about maintenance versus reporting? Is “confusing interface” a top-five issue or a top-fifty issue?

Without quantitative prioritization, every stakeholder selects the insights that support their pre-existing agenda. Engineering gravitates toward technically interesting challenges. Sales gravitates toward recent customer complaints. The VP gravitates toward competitive threats. Everyone has “customer data” supporting their position. Nobody agrees on what to build first.

Gap 2: Different Languages

Research teams speak in terms of needs, pain points, and user journeys. Product teams speak in terms of features, epics, and stories. Engineering speaks in terms of systems, components, and architecture. Sales speaks in terms of deals, objections, and competitive gaps.

There is no common language that connects “what the customer needs” to “what we should build.” A pain point like “changeover takes too long” could map to dozens of different product features, each with different cost, complexity, and impact. Without a structured translation mechanism, the mapping from insight to feature is ad hoc and inconsistent.

Gap 3: Organizational Politics

In many enterprises, the roadmap is not a strategic document — it is a political one. It reflects the power dynamics of the organization: which business unit has the most budget, which VP has the CEO’s ear, which key account threatened to switch suppliers.

Customer insights, in this environment, are ammunition rather than guidance. They are selectively cited to support positions already held. The research itself becomes politicized: “Let’s do a study to prove that customers want [thing my team has already started building].”

Opportunity Scores: The Missing Bridge

ODI’s opportunity scoring provides the structural bridge between customer insights and roadmap decisions that most organizations lack. Here is why it works:

The Mechanism

For every desired outcome in the customer’s job to be done, opportunity scoring measures two things:

1. Importance: How important is this outcome to the customer? (1-10 scale)
2. Satisfaction: How satisfied is the customer with their current ability to achieve this outcome? (1-10 scale)

The opportunity score formula — Importance + max(Importance - Satisfaction, 0) — produces a single number that captures both the value of the outcome (importance) and the gap in current solutions (dissatisfaction).

This formula has specific properties that make it strategically useful:

• Outcomes that are important and unsatisfied score highest — these are the real opportunities
• Outcomes that are important and satisfied score moderately — these are table stakes, not differentiation opportunities
• Outcomes that are unimportant score low regardless of satisfaction — even if customers are dissatisfied, they will not pay for improvement on outcomes they do not care about

From Scores to Priorities

When you calculate opportunity scores for all 50-150 outcomes in a job, you get a prioritized list. This list is the single most valuable artifact in the entire product strategy process because it answers the question that every other piece of research leaves open: Which outcomes should we address first?

The list is:

• Quantitative: Based on survey data from 180+ respondents, not on qualitative impressions from a handful of interviews
• Customer-driven: Reflects what customers actually value, not what internal stakeholders assume they value
• Comparable: All outcomes are measured on the same scale, so you can directly compare the relative value of “faster changeover” versus “better reporting” versus “easier maintenance”
• Defensible: Try arguing with a statistically validated dataset in an executive meeting. It changes the dynamics fundamentally

For a deeper treatment of opportunity scoring methodology, see our article on the opportunity algorithm.

The opportunity algorithm transforms innovation from a game of opinions to a game of facts. When you can show an executive team exactly which customer outcomes are most underserved — with statistical confidence — the argument shifts from ‘I think we should build X’ to ’the data shows outcome Y is the biggest opportunity.’ That shift changes everything.

The Translation Process: From Opportunity Scores to Roadmap

Here is the step-by-step process for converting opportunity score data into a defensible product roadmap:

Step 1: Identify the Opportunity Clusters

Individual outcomes rarely map one-to-one to product initiatives. More commonly, several related outcomes can be addressed by a single initiative. The first step is to cluster high-opportunity outcomes into themes.

Example: For a packaging equipment manufacturer, these three outcomes might cluster together:

• “Minimize the time required to switch between package formats” (score: 14.8)
• “Minimize the number of manual adjustments during format changeover” (score: 13.2)
• “Minimize the risk of quality defects in the first units after changeover” (score: 12.7)

These three outcomes form a natural cluster: “Rapid format changeover.” A single product initiative (e.g., an automated format changeover system) could address all three.

Step 2: Score the Clusters

Each opportunity cluster inherits a composite score from its constituent outcomes. Simple approaches include:

• Average opportunity score of all outcomes in the cluster
• Maximum opportunity score in the cluster (if addressing the single most underserved outcome is the goal)
• Weighted average that accounts for the number of outcomes in the cluster

The composite score tells you which clusters represent the largest total opportunity.

Step 3: Assess Feasibility and Effort

For each opportunity cluster, the engineering and development teams estimate:

• Technical feasibility: Can we actually build a solution that addresses these outcomes?
• Development effort: How long and how expensive?
• Dependencies: Does this initiative depend on other initiatives or technologies?
• Risk: What are the main technical and market uncertainties?

Step 4: Build the Priority Matrix

Plot each opportunity cluster on a 2x2 matrix:

• X-axis: Opportunity score (customer value)
• Y-axis: Feasibility / effort (internal capability)

This produces four quadrants:

Step 5: Sequence Into Roadmap

Taking the prioritized clusters from the matrix, sequence them into a time-based roadmap considering:

• Dependencies: Some initiatives enable others
• Resource constraints: What can your team actually execute in parallel?
• Market timing: Are there trade shows, regulatory deadlines, or competitive moves that affect timing?
• Strategic arc: Does the sequence tell a coherent story about your product’s evolution?

Step 6: Define Success Metrics

For each initiative on the roadmap, define success metrics using the underlying outcome statements:

Initiative: Automated format changeover system Success metrics:

• Changeover time reduced from 45 minutes to under 10 minutes (addresses “minimize time required to switch between formats”)
• Zero manual adjustments required during changeover (addresses “minimize number of manual adjustments”)
• First-unit quality defect rate below 0.1% after changeover (addresses “minimize risk of quality defects”)

These metrics are directly connected to the customer outcomes that justified the initiative. This creates traceability from customer need to product feature to success measurement — the full chain that most roadmaps lack.

Making Roadmap Decisions Defensible

One of the most valuable side effects of outcome-driven roadmap prioritization is that it makes decisions defensible. Not in an academic sense, but in the practical, organizational sense of surviving executive review and cross-functional debate.

The Old Way: Opinion vs. Opinion

Product Manager: “We should build the automated changeover system. Customers keep asking for faster changeovers.” VP Sales: “Our biggest accounts are asking for better connectivity and IoT features. We should build that first.” CTO: “We have a new AI-based quality inspection technology that could differentiate us. Let’s productize that.” CFO: “Which one has the best business case? Show me the spreadsheets.”

Everyone is right from their perspective. The debate is unresolvable without data. The decision defaults to whoever has the most organizational power.

The New Way: Data-Informed Prioritization

Product Manager: “Our JTBD research surveyed 240 customers across three segments. The top three underserved outcomes are all related to changeover speed and quality. The opportunity cluster scores 14.2 — well above the threshold for significant unmet need. IoT connectivity outcomes score 8.7 — important but adequately served by current solutions. AI-based quality inspection addresses outcomes that score 11.3 — worth pursuing but after changeover.”

This does not eliminate debate — nor should it. The CTO might argue that the AI technology creates competitive barriers. The VP Sales might point out that the IoT request comes from a strategic account worth EUR 50M. These are legitimate strategic considerations.

But the debate is now grounded in data. The burden of proof shifts. Instead of “I think customers want X,” the argument becomes “I believe strategic factor Y outweighs the quantitative opportunity data.” That is a much healthier discussion.

Common Failure Patterns in Roadmap Translation

Failure Pattern 1: The Feature Request Pipeline

The product team collects feature requests from sales, support, and customers, then prioritizes them by frequency or revenue at risk. This seems data-driven but is deeply flawed:

• Feature requests are solutions, not needs. Customers may request different features to address the same underlying outcome
• Frequency of requests is biased toward vocal customers and recent interactions
• Revenue-at-risk prioritization gives disproportionate weight to large accounts, whose needs may not represent the broader market

Fix: Convert feature requests into outcome statements. Multiple different feature requests often map to the same underlying outcome. Prioritize outcomes, not features.

Failure Pattern 2: The HiPPO Roadmap

HiPPO — Highest Paid Person’s Opinion — drives many enterprise roadmaps. The VP of Product (or the CEO, or the board) decides what to build based on their market intuition.

This is not always wrong. Experienced leaders often have good intuition. But intuition is uncalibrated — there is no way to know when it is right and when it is wrong until after the product launches.

Fix: Use opportunity data to calibrate executive intuition. Present the data before the strategy meeting. Let leaders react to quantitative findings rather than operating in a data vacuum.

Failure Pattern 3: The Competitor Copycat Roadmap

The product team benchmarks competitors at trade shows and reverse-engineers their feature set. The roadmap becomes: “close the gaps with Competitor X.”

This guarantees you will always be a follower, competing on dimensions your competitor chose. It also assumes your competitor made the right strategic choices — which, given industry-average product success rates, they probably did not.

Fix: Use opportunity scores to evaluate whether competitor features actually address high-value unmet needs. Some competitor features are strategic; many are not.

Failure Pattern 4: The Technology Push Roadmap

Engineering has developed a new technology and the roadmap is built around productizing it. The research phase consists of finding customers who might want the technology.

This is the most expensive failure pattern because it combines high development costs with low market fit probability.

Fix: Start with customer outcomes, then evaluate whether the new technology addresses high-opportunity outcomes. If it does, it earns a roadmap position. If it does not, shelf it or redirect it to a different application.

Maintaining the Roadmap Connection Over Time

The translation from insights to roadmap is not a one-time exercise. Markets evolve. Competitors launch new products. Customer needs shift. A roadmap built on two-year-old data is not much better than one built on opinion.

Quarterly Opportunity Reviews

Every quarter, review the opportunity landscape:

• Have competitor launches changed satisfaction scores on any outcomes?
• Have new technologies created solutions for previously unsolvable outcomes?
• Has the market segmentation shifted?

This does not require a full JTBD study every quarter. It requires maintaining awareness of how the opportunity landscape is evolving and adjusting the roadmap when significant shifts occur.

Post-Launch Outcome Measurement

When a product or feature launches, measure its impact using the outcome statements that justified its development:

• Did satisfaction scores for the target outcomes actually improve?
• Did the opportunity scores decrease (indicating the unmet need has been partially or fully addressed)?
• Were there unexpected effects on other outcomes?

This closes the feedback loop from insight to roadmap to execution to market impact — the full chain that most organizations leave open.

For guidance on defining the right innovation metrics, see our article on measuring what matters beyond patent counts.

The most frustrating pattern I see in enterprise product organizations is excellent research sitting unused. Teams invest hundreds of thousands in customer studies, produce genuinely actionable insights, and then make roadmap decisions the same way they did before the study. Opportunity scoring solves this because it does not just produce insights — it produces a prioritized decision tool that plugs directly into roadmap planning.

Frequently Asked Questions