Applying JTBD Insights to Build a Product Manager Roadmap
This skill teaches you how to convert job maps, outcome scores, and opportunity landscapes into a prioritized product manager roadmap, feature definitions, and positioning statements grounded in real customer evidence.
Start by ranking your scored outcome opportunities from highest to lowest. Group the top opportunities into strategic themes that map to job steps. For each theme, define the product capabilities needed, estimate effort, and sequence them into a roadmap. Prioritize themes where importance is high but satisfaction is low, because those represent the largest gaps between what customers need and what current solutions deliver.
Outcome: You produce a product roadmap where every initiative traces back to a quantified customer outcome opportunity, making it possible to defend priorities to stakeholders with evidence instead of opinion and to align engineering, design, marketing, and sales around shared customer problems.
Prerequisites
- Completed job map with defined job steps (see Creating Job Maps)
- Scored desired outcome statements with importance and satisfaction data (see Writing Desired Outcome Statements)
- An opportunity landscape or scored list from Identifying Underserved Outcome Opportunities
- Basic understanding of product roadmap formats (now/next/later, timeline, or theme-based)
- Access to customer segment data, ideally from JTBD-based segmentation
Overview
Most product manager roadmap debates stall because teams lack a shared framework for deciding what matters. One stakeholder pushes a feature because a big customer requested it. Another pushes a different feature because a competitor shipped it. Without a common evidence base, the loudest voice or the highest-paid person's opinion wins. The Jobs-to-be-Done (JTBD) Framework fixes this by grounding every roadmap decision in quantified customer outcomes. When you have scored outcomes sorted by opportunity size, the question shifts from "what should we build?" to "which underserved outcomes should we address first, and what capabilities would address them?"
This skill sits at the end of the JTBD workflow and depends on everything upstream. You need a job map that breaks the customer's core functional job into discrete steps. You need desired outcome statements scored by importance and satisfaction across a representative sample. And you need those scores translated into an opportunity landscape that highlights where the biggest gaps exist between what customers need and what they currently have. Without those inputs, this skill cannot produce a defensible roadmap. It can only produce a decorated wish list.
The concrete artifact you produce is a theme-based product roadmap where each theme maps to one or more underserved outcomes, each initiative within a theme describes the capability to build, and each capability links back to the specific outcome statements it addresses. Alongside the roadmap, you produce positioning briefs for the top themes, which marketing and sales teams use to message the product in the language of the customer's job. The roadmap is not a Gantt chart with fixed dates. It is a sequenced set of strategic bets ranked by opportunity size, adjusted for effort, and validated against segment-level data.
Success looks like this: when someone asks "why are we building this instead of that," you can point to a specific outcome statement, show its opportunity score, identify the customer segment it affects, and demonstrate that no current solution adequately addresses it. The roadmap becomes a living argument, not a static slide. It updates as new outcome data arrives and as you re-score outcomes after each product release to measure whether you actually moved satisfaction upward.
How It Works
The mental model behind this skill is the opportunity algorithm. In JTBD, opportunity is defined as outcomes where importance is high and satisfaction is low. Tony Ulwick's formula expresses this as: Opportunity = Importance + (Importance - Satisfaction). When importance is 9 out of 10 and satisfaction is 3 out of 10, opportunity is 9 + (9 - 3) = 15. When importance is 9 and satisfaction is 8, opportunity is 9 + (9 - 8) = 10. The formula double-weights importance because a high-importance, low-satisfaction outcome is a bigger strategic bet than a moderate-importance, low-satisfaction one. Outcomes scoring above 12 on this scale are typically strong candidates for investment. Outcomes between 10 and 12 are worth investigating. Below 10, the outcome is either adequately served or not important enough to move the needle.
The reason this formula works as a roadmap input is that it encodes both customer value and competitive whitespace into a single number. High importance means the customer cares. Low satisfaction means nobody is solving it well. That combination is the definition of a market opportunity. By sorting outcomes this way, you are not building features customers ask for. You are building capabilities that address the problems customers most want solved but cannot currently solve, which is a fundamentally different and more valuable lens.
However, opportunity scores alone do not make a roadmap. You need a second layer: grouping outcomes into themes that represent coherent product investments. A single feature might address three related outcomes across two job steps. Two seemingly unrelated outcomes might require the same underlying platform capability. The grouping step is where product judgment enters. The data tells you what matters. Your understanding of the product architecture, the team's capabilities, and the market timing tells you how to bundle those outcomes into shippable initiatives.
A third layer adjusts for effort and risk. An outcome with an opportunity score of 15 that requires 18 months of platform rearchitecture may be a worse near-term bet than an outcome scoring 13 that you can ship in six weeks. The JTBD framework does not prescribe a specific effort-estimation method, so you can use whatever your team already uses, whether that is t-shirt sizing, story points, or weeks of engineering time. The key is that effort adjusts the sequence of themes on the roadmap but does not remove high-opportunity themes entirely. A high-opportunity, high-effort theme moves to "next" or "later" rather than disappearing.
Finally, the model accounts for segments. When you apply customer segmentation by unmet needs, you may discover that one segment has wildly different opportunity scores than another. A product manager roadmap built on aggregate scores can miss segment-specific opportunities. The best practice is to examine the top opportunities at the segment level and decide whether to build for the largest segment first, the most underserved segment, or a segment that aligns with your go-to-market motion. This is a strategic choice, not a formula output.
Step-by-Step
Step 1: Compile and validate your opportunity landscape
Gather the scored outcome statements from your JTBD research. You need, at minimum, the outcome statement text, the job step it belongs to, the average importance score, the average satisfaction score, and the calculated opportunity score. If you completed identifying underserved outcome opportunities, you already have this. Export it into a spreadsheet or table where you can sort, filter, and annotate.
Before proceeding, validate the data. Check that your sample size is large enough (minimum 50 respondents per segment for quantitative confidence). Confirm that no outcome was scored by fewer than 80% of respondents, which would indicate ambiguity in the statement. Flag any outcome where importance and satisfaction are both above 8, because these are over-served outcomes and building more here wastes resources.
Tip: Sort by opportunity score descending and draw a line at score 12. Everything above the line is your primary candidate pool. Everything between 10 and 12 is your secondary pool. Ignore everything below 10 for roadmap purposes, but keep the data because scores shift after every product release.
Step 2: Identify the top 10-15 outcome opportunities
From the sorted list, select the 10-15 highest-scoring outcomes. This is your raw opportunity set. Copy these into a working document with columns for: outcome statement, job step, opportunity score, segment(s) most affected, and a blank column for theme assignment. If your research included segment-level scoring, check whether the top opportunities differ by segment.
It is common for the aggregate top 10 to miss outcomes that are critical for a specific high-value segment. If you serve multiple segments, run the sort per segment and compare the lists. Add any segment-specific outcomes that score above 12 for a target segment but fell below the aggregate cutoff. Your working set might grow to 15-20 outcomes, and that is fine at this stage.
Tip: If two outcomes share a job step and describe closely related struggles (e.g., "minimize the time it takes to identify relevant data" and "minimize the likelihood of overlooking critical data points"), keep both. They may point to the same feature, but collapsing them too early hides nuance that matters during design.
Step 3: Group outcomes into strategic themes
Review your 10-20 candidate outcomes and look for natural groupings. Grouping criteria include: outcomes that belong to the same job step, outcomes that would be addressed by the same product capability, outcomes that serve the same customer segment, or outcomes that share a common root cause. " A good theme contains 2-5 outcomes. If a theme contains only one outcome, it may be too narrow to justify a roadmap slot.
If it contains more than 6, it may be too broad to execute as a single initiative. Each outcome should belong to exactly one theme. If an outcome fits two themes, assign it to the one where it has the strongest causal link to the proposed capability.
Tip: Write the theme name before you think about features. Themes describe the customer problem space, not the solution. "Accelerate data validation" is good. "Build a validation dashboard" is premature, because it locks you into a solution before design exploration.
Step 4: Score each theme for aggregate opportunity and effort
For each theme, calculate an aggregate opportunity score. The simplest method is to average the opportunity scores of the constituent outcomes, but a better approach is to sum them, because a theme addressing five outcomes at 13 each represents more total opportunity than a theme addressing two outcomes at 14 each. " Next, estimate the effort required to address each theme. Work with engineering leads or use your team's standard estimation process.
Assign a rough effort level: small (2-4 weeks of a squad), medium (1-2 months), or large (a quarter or more). You do not need precise estimates at this stage. The goal is to separate themes you can ship quickly from themes that require significant investment. Calculate a simple ratio: total opportunity divided by effort (where small=1, medium=3, large=6).
This gives you an opportunity-per-effort index for sequencing.
Tip: Do not let effort alone kill a theme. If your highest-opportunity theme is also your highest-effort, it should still appear on the roadmap. Sequence it for "later" rather than cutting it. Cutting it means you are conceding the biggest customer problem to competitors.
Step 5: Sequence themes into now / next / later buckets
Using the opportunity-per-effort index from Step 4, sort themes from highest to lowest. Assign the top 1-2 themes to "now" (current quarter). Assign the next 2-3 to "next" (following quarter). Place remaining themes in "later" (6+ months).
Adjust the raw sort based on three factors. First, dependencies: if Theme B requires platform work from Theme A, Theme A must come first regardless of score. Second, segment alignment: if your go-to-market motion targets a specific segment this quarter, prioritize themes that serve that segment. Third, quick wins: if a medium-opportunity theme can ship in two weeks and generate visible customer value, pulling it into "now" builds momentum and credibility for the larger bets.
Document the rationale for each sequencing decision. This is the artifact that defends your roadmap in stakeholder reviews.
Tip: Limit "now" to 1-2 themes. Product teams that try to address four themes simultaneously ship none of them well. Focus increases the odds that you move satisfaction scores measurably on your next outcome survey.
Step 6: Define capabilities for each 'now' theme
For each theme in the "now" bucket, translate the outcome statements into product capabilities. A capability is not a feature spec. It is a description of what the product must enable the customer to do, written in the language of the job. " Each capability should reference the specific outcome statements it addresses, by number or text.
Write 2-4 capabilities per theme. Each capability becomes an input to your design and engineering teams, who will propose specific features, interfaces, and technical approaches. This step bridges the language of customer outcomes and the language of product development. Without it, engineering teams receive abstract themes and build whatever they interpret, which may or may not address the underlying outcomes.
Tip: Test each capability statement by asking: if we shipped this, would the customer's satisfaction score on the linked outcomes increase by at least 1 point on a 10-point scale? If the answer is unclear, the capability is too vague or misaligned.
Step 7: Write positioning briefs for each theme
For each theme, write a one-page positioning brief that marketing, sales, and customer success teams can use immediately. The brief contains five sections: (1) the customer segment this theme serves, described by their unmet-need profile rather than demographics, (2) the job step and outcome statements being addressed, in the customer's own language, (3) the capabilities being built, described as benefits, (4) the current alternatives the customer uses to get this job done today and why those alternatives fall short, and (5) a draft positioning statement in the format: "For [segment] who struggle with [outcome], [product] enables [capability] unlike [current alternatives] which [limitation]." These briefs ensure that every function in the company describes the product the same way. They also prevent the common failure where engineering builds something valuable but marketing messages it in terms that do not match how customers think about the problem.
Tip: Pull exact phrases from your JTBD interview transcripts for section 2 and 4. Customers describe their struggles in vivid, specific language that outperforms anything a copywriter invents from scratch. See [conducting JTBD customer interviews](/skills/conducting-jtbd-customer-interviews) for how to capture this language.
Step 8: Validate the roadmap against business constraints
Before finalizing, run the roadmap through three validation checks. First, resource feasibility: does your team actually have the capacity to execute the "now" themes in the planned timeframe? " Second, revenue alignment: does the roadmap serve the segments that represent your revenue targets? If your sales team is targeting enterprise and your roadmap is optimized for SMB outcomes, you have a misalignment that needs resolution.
Third, competitive urgency: check whether any competitor has recently shipped capabilities that address your top themes. If so, you may need to accelerate or differentiate. This validation step often causes 1-2 theme swaps between buckets, which is healthy. It means your roadmap is being pressure-tested against reality rather than existing in a data vacuum.
Tip: Invite one stakeholder from sales, one from engineering, and one from marketing to review the draft roadmap. Give them the opportunity scores and let them challenge the sequencing. If they cannot produce data that contradicts your ranking, the roadmap holds. If they can, update it.
Step 9: Establish a measurement plan and refresh cadence
For each "now" theme, define how you will measure success after launch. The primary metric is a follow-up outcome survey: did satisfaction scores on the targeted outcomes increase? , time-to-completion for the relevant job step, task abandonment rate, support ticket volume related to the outcome). Set a target for each metric before you build.
" Schedule a quarterly roadmap refresh where you re-score the top outcomes, recalculate opportunity, and adjust the "next" and "later" buckets based on what shifted. Outcomes you successfully addressed should drop in opportunity score. New outcomes may emerge or rise as competitors move. The product manager roadmap is a living document, not a one-time output.
Tip: If you cannot run a full quantitative outcome survey after every release, use a lightweight version: survey 20-30 customers from the target segment with just the 5-10 outcomes related to the shipped theme. It takes two weeks and gives you directional data that is far better than no data.
Examples
Example: B2B SaaS project management tool (mid-stage startup, 40-person team)
A project management SaaS serving 2,000 customers surveyed 180 users across three segments: agency teams, internal ops teams, and engineering teams. They scored 45 outcome statements across 8 job steps. The top opportunities clustered around the "monitor progress" and "resolve blockers" job steps, with three outcomes scoring above 14 and seven above 12.
The product team pulled the top 12 outcomes into a working document and identified three themes: "Real-time blocker detection" (4 outcomes, total opportunity 56), "Cross-project visibility" (3 outcomes, total opportunity 41), and "Automated status reporting" (5 outcomes, total opportunity 53). Engineering estimated blocker detection as medium effort, cross-project visibility as large, and status reporting as small. 8). " Segment analysis revealed that agency teams had the highest opportunity scores for status reporting, aligning with the sales team's Q3 push into the agency vertical.
8, confirming the bet.
Example: Consumer fintech app (early-stage, 12-person team)
A personal finance app with 15,000 users conducted JTBD interviews with 25 users and then surveyed 120 users on 30 outcome statements related to the job "manage monthly household spending." The team had limited engineering capacity (3 developers) and needed to pick just one theme for the next quarter.
The survey revealed that the "categorize expenses" job step contained the three highest-scoring outcomes, all above 15. " However, the second-highest cluster, "Anticipate upcoming shortfalls" (two outcomes, both at 13), mapped to a capability the team could ship in two weeks using existing transaction data. The product lead made a deliberate sequencing call: ship the quick-win shortfall alerts first (2-week effort, opportunity 26 total), then dedicate the remaining 10 weeks to the categorization theme (opportunity 46 total). " This language tested well in app store listing experiments.
The team measured success by tracking whether users who received shortfall alerts reduced overdraft incidents, finding a 34% reduction within 60 days. 1, confirming the theme could move to maintenance mode.
Example: Enterprise healthcare analytics platform (large org, 200-person product org)
A healthcare analytics company surveyed 400 users across four segments: hospital administrators, clinical researchers, compliance officers, and IT directors. They scored 80 outcome statements across 12 job steps. The executive team wanted a single company-wide product manager roadmap that served all segments.
The product strategy team ran the opportunity sort at both the aggregate and segment levels. The aggregate top 10 was dominated by outcomes from the "interpret analysis results" job step. But the segment-level view revealed a critical divergence: compliance officers had their top outcomes in the "ensure audit readiness" step, scoring 15-16 on opportunity, while those same outcomes scored only 9 in the aggregate because other segments rated them as low importance. The team proposed a dual-lane roadmap: Lane 1 addressed the aggregate top themes ("Contextual result interpretation" and "Cross-dataset correlation") for the majority segments.
Lane 2 addressed "Continuous audit readiness" specifically for compliance officers, a segment the sales team had identified as a high-growth vertical with 40% higher average contract value. Each lane had its own now/next/later structure. " Engineering allocated 70% capacity to Lane 1 and 30% to Lane 2, reflecting the segment size ratio. Quarterly re-scoring showed that after two releases targeting Lane 1, three of the five targeted outcomes dropped below the opportunity threshold of 12, freeing capacity to shift toward Lane 2 themes.
Example: B2C e-commerce marketplace (growth stage, 60-person company)
An online marketplace for handmade goods surveyed 200 sellers (their primary revenue-generating segment) on 35 outcome statements related to the job "sell handmade products online." The product team had never used JTBD before and was transitioning from a feature-request-driven roadmap.
The initial opportunity landscape surprised the team. 5 respectively. 5. 2, meaning it was adequately served by existing workarounds.
The product lead used this data to retire 12 items from the old backlog that all scored below 11 on opportunity. The fulfillment theme was sequenced as "now" with a medium effort estimate (8 weeks). The positioning brief reframed the marketplace's value proposition from "beautiful storefronts" to "sell more by shipping faster," which the marketing team tested in paid acquisition campaigns. The fulfillment-focused ads produced a 22% higher click-through rate than the storefront-focused ads, validating that the outcome data reflected real market demand.
The team established a quarterly cadence of re-scoring the top 15 outcomes, making the product manager roadmap update a predictable process rather than an annual ordeal.
Best Practices
Always link every roadmap initiative back to specific outcome statements with their scores. This traceability is the entire point of the JTBD approach. Without it, you have a roadmap that looks evidence-based but cannot actually be interrogated. When a stakeholder asks why Feature X is prioritized over Feature Y, you should be able to say: "Feature X addresses outcomes #4, #7, and #11, with a combined opportunity score of 42, while Feature Y addresses outcome #15, which scores 11."
Separate the opportunity ranking from the sequencing decision and make both visible. Opportunity scores determine what matters. Sequencing accounts for effort, dependencies, segment focus, and business timing. When these two layers are conflated into a single priority list, teams lose the ability to see when they are making a strategic trade-off versus following the data.
Document both the raw opportunity ranking and the adjusted sequence with explicit notes on why they differ.
Re-score outcomes after every major release, not just annually. Satisfaction scores change when you ship improvements, and they change when competitors ship improvements. A roadmap built on 12-month-old data is making bets on yesterday's landscape. Quarterly re-scoring of your top 20 outcomes takes 2-3 weeks of survey fieldwork and keeps the roadmap calibrated to current reality.
Use segment-level data when segments have meaningfully different opportunity profiles. A product manager roadmap built on aggregate scores across all customers can lead you to build for the average customer, who does not actually exist. If your JTBD segmentation reveals that enterprise and SMB customers have different top-5 opportunities, acknowledge that in your roadmap and make an explicit choice about which segment to serve in which time horizon.
Keep themes small enough to ship and measure within a quarter. A theme that takes two quarters to execute delays your feedback loop. You will not know whether you moved satisfaction until the work ships and you re-survey. If a theme is too large, split it into sub-themes that each address a subset of the constituent outcomes, and ship the highest-opportunity sub-theme first.
Write positioning briefs at the same time as the roadmap, not after launch. Positioning is not a downstream marketing activity. It is a strategic decision about how you frame the product's value in the context of the customer's job. If you wait until engineering finishes building, marketing scrambles to retrofit a message, and the result often misaligns with the outcomes the feature was designed to address.
Resist the urge to add themes to the roadmap that lack outcome data. Stakeholder requests, competitor moves, and gut feelings are valid inputs to the discussion, but they should be validated against outcome data before consuming roadmap space. If a stakeholder insists on a feature, ask: which outcome statement does this address, and what is its opportunity score? If the answer is "we did not survey that," then survey it before committing resources.
Common Mistakes
Building features directly from outcome statements without grouping into themes
Correction
When teams skip the theme-grouping step and map each outcome to a separate feature, the roadmap balloons into a feature list with 15-20 items and no strategic coherence. This happens because outcome statements are granular by design. They describe atomic units of customer value, not shippable product increments. The signal to watch for is a roadmap where every line item addresses exactly one outcome.
Instead, group related outcomes into themes that represent a coherent product investment. Each theme should address 2-5 outcomes and ship as a cohesive experience improvement.
Using opportunity scores as the sole input to sequencing
Correction
Teams new to JTBD sometimes treat the opportunity score as a complete priority ranking, ignoring effort, dependencies, and segment alignment. The result is a roadmap that looks analytically perfect but is operationally impossible, such as starting with a theme that requires infrastructure that does not exist yet. Watch for a roadmap where the sequence exactly mirrors the opportunity ranking with no adjustments. The fix is to use opportunity scores to determine what matters and then apply a second pass that adjusts for effort, dependencies, and business context, documenting every adjustment with a clear rationale.
Aggregating scores across all segments when segments have different opportunity profiles
Correction
When outcome data is averaged across all respondents, high-opportunity outcomes for a niche segment get diluted by the majority segment's scores. This is especially dangerous when your growth strategy depends on winning a specific segment. The symptom is a roadmap that feels generic and does not excite any particular customer group. To catch this early, run the opportunity sort per segment before aggregating.
If the top-5 lists differ by segment, you need segment-specific roadmap lanes or an explicit decision about which segment to prioritize this cycle.
Treating the roadmap as a fixed plan rather than a living hypothesis
Correction
Some teams invest heavily in building a JTBD-based roadmap and then treat it as immutable for 12 months. The roadmap becomes a political artifact rather than a strategic tool. Satisfaction scores shift when you ship, when competitors ship, and when market conditions change. The red flag is a roadmap that has not been updated since it was created.
Establish a quarterly refresh cadence where you re-survey the top 20 outcomes, recalculate opportunity, and adjust the "next" and "later" buckets. The "now" bucket can stay stable within a quarter, but everything beyond it should be considered provisional.
Skipping the positioning brief and leaving messaging to marketing after launch
Correction
When positioning is deferred, marketing teams reverse-engineer the value proposition from feature specs and release notes. The resulting messaging often focuses on what the product does (features) rather than what the customer gets done (outcomes). This misalignment wastes the entire JTBD investment because the product is marketed in terms that do not match how customers think about their job. Write the positioning brief alongside the roadmap, using the exact outcome language from your research.
Hand it to marketing as a constraint, not a suggestion.
Including over-served outcomes on the roadmap because a vocal customer requested them
Correction
An outcome with high importance and high satisfaction is over-served. Building more capability here does not create value, it creates waste. This mistake happens when a large customer or an executive champions a feature that maps to an already-satisfied outcome. The tell is an initiative whose linked outcomes all score below 10 on the opportunity scale.
The fix is to show the requester the data: importance is 9, satisfaction is 8, opportunity is 10. There is no meaningful gap to close. Redirect the conversation to outcomes where the gap is real.
Other Skills in This Method
Conducting JTBD Customer Interviews
How to run switch interviews and timeline interviews that uncover the real jobs, hiring criteria, and switching triggers behind customer decisions.
Identifying Underserved Outcome Opportunities
How to use opportunity scoring (importance vs. satisfaction) to quantify which desired outcomes are most underserved and represent the best innovation targets.
Defining the Customer's Core Functional Job
How to identify and articulate the fundamental job a customer is trying to accomplish, using proper job statement syntax and structure.
Writing Desired Outcome Statements
How to craft properly structured outcome statements (direction + metric + object of control + context) that capture measurable customer success criteria at each job step.
Creating Job Maps to Visualize Customer Processes
How to break down a core functional job into its universal process steps (define, locate, prepare, confirm, execute, monitor, modify, conclude) to map the full customer journey.
Segmenting Customers by Unmet Needs
How to create outcome-based customer segments that group people by shared underserved outcomes rather than demographics, enabling more targeted product strategies.
Frequently Asked Questions
How do I build a product manager roadmap from JTBD data when I only have qualitative interview data, not quantitative scores?
You can still build a directional roadmap, but you lose the ability to defend precise sequencing. From qualitative interviews, count outcome frequency (how many interviewees mentioned each struggle) and intensity (how emotionally charged the language was). Use frequency as a proxy for importance and intensity as a proxy for dissatisfaction. Group the most frequent and intense outcomes into themes and sequence by your best judgment. Acknowledge to stakeholders that this is a hypothesis-stage roadmap and plan a quantitative survey within 60 days to validate or adjust. See [conducting JTBD customer interviews](/skills/conducting-jtbd-customer-interviews) for how to extract outcome language from interviews.
How many outcome opportunities should a product manager roadmap address per quarter?
For most teams, 1-2 themes covering 3-8 outcomes is the right scope per quarter. A single theme typically requires 4-10 weeks of focused execution. If you try to address three or more themes simultaneously, each theme gets diluted and you ship partial solutions that do not move satisfaction scores meaningfully. The goal is to fully address a theme so that when you re-score those outcomes, satisfaction has increased by 2+ points. 5 points waste the investment because customers do not perceive the improvement.
Should I apply JTBD insights to the product manager roadmap before or after segmenting customers by unmet needs?
After segmentation, if possible. Aggregate-level opportunity scores can mask critical segment-level differences, leading you to build for an average customer that does not exist. If you have already completed [segmenting customers by unmet needs](/skills/segmenting-customers-by-unmet-needs), run the opportunity sort per segment and compare the top-5 lists. If they align, your aggregate roadmap is fine. If they diverge, you need either segment-specific roadmap lanes or an explicit decision about which segment to prioritize. If you have not yet segmented, build the roadmap on aggregate data and plan segmentation as a next step.
How do I handle stakeholder pushback when the JTBD opportunity data contradicts their preferred features?
Show the data transparently. Pull up the specific outcome statement the stakeholder's preferred feature maps to and show its opportunity score relative to the themes on the roadmap. Often the preferred feature addresses a real outcome but one that is lower-priority than alternatives. , a competitive threat or a contractual commitment to a key customer), treat that as a legitimate business constraint that adjusts sequencing, not as a reason to discard the data. " This preserves the integrity of the framework while accommodating real-world pressures.
Why does my product manager roadmap keep drifting from the original JTBD-based priorities?
Drift usually comes from one of three sources. First, the roadmap was set once and never refreshed, so new requests accumulated without being scored against outcomes. Fix this by scheduling quarterly re-scoring. Second, urgent requests bypass the prioritization process entirely, which signals a governance problem, not a data problem. Fix this by requiring every unplanned request to reference an outcome statement and its score before it enters the backlog. Third, the original outcome data was too old or too narrow in sample size, making the team lose confidence in it. Fix this by running a larger survey or refreshing the data, then rebuilding trust in the numbers.
How do I use a JTBD-based product manager roadmap to align marketing and sales messaging?
The positioning briefs from Step 7 are the primary alignment mechanism. Each brief contains the customer segment profile, the outcome statements in customer language, the capabilities being built, the current alternatives and their shortcomings, and a draft positioning statement. Hand these to marketing as inputs for campaign messaging, landing pages, and sales collateral. The key principle is that messaging should use the language of the job and the outcome, not the language of the feature. Instead of "We built a new dashboard," the message should be "Spot project blockers before they delay your deadline," which mirrors the outcome statement. Sales teams can use the outcome language in discovery calls to test whether a prospect shares the same unmet need the product was designed to address.
Can I apply this skill if my company uses OKRs or another planning framework alongside JTBD?
Yes, and the two are complementary. OKRs define what the business wants to achieve (objectives) and how to measure it (key results). JTBD themes and outcome scores tell you which customer problems to solve to achieve those objectives. The mapping is straightforward: each OKR's key results should connect to specific outcome statements whose satisfaction scores you intend to move. For example, an OKR key result of "Increase NPS from 35 to 50" connects to the JTBD themes that address the highest-opportunity outcomes for your largest customer segment. The JTBD roadmap feeds the OKR planning process by providing evidence for which initiatives will most likely move the key results.