“We Tried JTBD. It Didn’t Work.”
I have heard this sentence, or a version of it, at least a dozen times in the last five years. Always from a senior product manager or VP who invested real time and budget into a JTBD initiative, generated a job map, ran some interviews, produced a slide deck — and found that six months later, the product roadmap looked essentially identical to what it would have been without any of it.
They are not wrong that something failed. They are wrong about what failed.
What failed was not Jobs to Be Done. What failed was a partial implementation that stopped before the methodology could produce its most valuable outputs. It is the equivalent of hiring a structural engineer to design a bridge, using their initial sketches to brief the architects, and then skipping the load calculations — and then concluding that structural engineering “didn’t work” when the bridge has problems.
JTBD is a rigorous methodology with specific steps and specific outputs. When it produces something other than better product decisions, it is almost always because one or more of those steps was executed poorly, skipped, or replaced with a well-intentioned approximation that looks like JTBD but lacks its operative mechanism.
This article catalogs the eight most common JTBD mistakes I have seen in client engagements and in reviewing other organizations’ innovation processes. For each one, I will describe what it looks like, why it happens, what it costs, and what the correct practice looks like.
Mistake 1: Defining the Job Around the Product
What it looks like
The team writes a job statement. It sounds like a job statement. It uses a verb and an object. But look closely and you will find the product embedded in it.
“Use our diagnostic software to identify equipment faults” is not a job. It is a feature description wearing job-statement clothing. The same problem appears in: “Operate the conveyor system to move product through the assembly line.” “Use the monitoring platform to track patient vitals.” Each of these makes the current solution a precondition of the job.
Why it happens
It is genuinely difficult to think about customer goals without referencing the solution your organization currently provides. Your team has spent years thinking about the product. The product vocabulary is embedded in every meeting, every document, every customer conversation. Stripping it out requires a deliberate act of abstraction that most teams have never been asked to perform.
What it costs
A solution-embedded job statement narrows your competitive view and your innovation space simultaneously. If the job is “use our software,” you will only discover outcomes related to software use. You will miss outcomes that reveal adjacent opportunity — needs that your product is not positioned to address but that competitors (or non-obvious substitutes) might. You will also fail to see your real competitive set: not just similar products, but any alternative way customers could accomplish the goal.
I worked with a MedTech company whose initial job statement was “operate the infusion pump to deliver medication at the prescribed rate.” After three rounds of revision, we arrived at “deliver precise pharmacological therapy to critically ill patients who cannot self-administer.” The difference between those two statements redefined the competitive set, expanded the addressable market, and revealed outcome categories that the original statement would have excluded entirely.
The fix
A well-formed job statement has three components: a verb (functional action), an object (what the action is applied to), and a contextual clarifier (the situation in which the job occurs). None of these should reference the current solution.
Test your job statement by asking: “Could a completely different technology accomplish this job?” If yes, the statement is sufficiently abstract. If the answer is “only our technology can do this,” the statement is too product-specific.
Mistake 2: Stopping at the Job Map
What it looks like
The team completes qualitative interviews. They build a job map — a process decomposition of the job into its functional steps. They have a well-structured artifact showing the eight stages of the job, with some preliminary outcomes noted at each stage. The project closes. The job map becomes a reference document, occasionally surfaced in product reviews, never integrated into a product decision.
Why it happens
The job map is satisfying. It is visual, structured, and gives the team a new vocabulary for talking about customer needs. It looks like progress. And often, the budget or organizational patience for the project runs out at exactly the point where the job map is complete. The qualitative phase is done; the quantitative phase is expensive and slow.
What it costs
The job map is the input to the measurement phase, not the output of the JTBD process. Without quantitative measurement — without surveying a representative sample of customers on the importance of each desired outcome and their satisfaction with current solutions — you cannot tell which needs are underserved. You have a map, but no topography. You know what the job steps are, but not where the hills and valleys of customer frustration are located.
A job map without opportunity scores is like a market research report without data: interesting, possibly directionally correct, but not decision-grade. Teams that stop at the job map end up prioritizing based on the qualitative hunches they had before — now reinforced by a structured artifact that makes them feel more grounded.
The fix
Treat the job map as infrastructure, not output. Its purpose is to organize the outcome statements you will eventually measure. If you cannot commit to the quantitative phase, be explicit about what you are producing: qualitative insight, useful for improving how you talk about the market, but not sufficient for prioritizing product investment. For a complete picture of how interview-based discovery feeds into measurable outcomes, see our JTBD interview guide.
Mistake 3: Writing Outcomes as Solutions
What it looks like
The team produces a list of “desired outcomes” from their interviews. The list looks like this:
- “Customers want a dashboard that shows all readings in one place”
- “Need faster alerts when thresholds are exceeded”
- “Want integration with existing ERP systems”
These are not desired outcomes. They are solution requirements expressed in customer vocabulary.
Why it happens
Customers talk in solutions. When you ask “what would make this better?” or “what do you wish the product could do?”, they answer in product terms because that is the reference frame the question establishes. Researchers who are not trained in outcome statement syntax will record what customers say — which is solution language — and label it “outcomes.”
What it costs
Solution statements cannot be measured against the full competitive set. If you survey customers on “how important is it that the dashboard shows all readings in one place?” you are measuring preference for a specific design pattern, not an underlying need. A different solution might address the same underlying need — “minimize the time it takes to assess the current status of all monitored parameters” — in a completely different way. By encoding the solution in the outcome statement, you eliminate the possibility of discovering that solution.
Info
The fix
Outcome statements follow a strict syntax: direction of improvement + metric + object of control + contextual clarifier. The direction is almost always “minimize” (time, likelihood of error, cost, effort) or “maximize” (accuracy, yield, completeness). There is no room in this syntax for product or solution references.
“Minimize the time it takes to assess the status of all monitored parameters across active sessions” is an outcome statement. “Add a unified dashboard” is a solution requirement. The difference is not cosmetic — it is the difference between a customer need that any solution might address and a feature requirement that locks you into a specific design direction.
Mistake 4: Using the Wrong Sample for Quantitative Research
What it looks like
The team runs the quantitative survey. But the respondent pool is: their most vocal existing customers, the contacts that sales agreed to share, the people on the newsletter list who clicked “interested in research.” The survey goes to 150 people and returns 60 responses, mostly from power users who are highly satisfied with the current product.
Why it happens
Recruiting a representative sample of 200-600 customers — including users of competitive solutions, lost prospects, and non-consuming customers — is harder and more expensive than using existing contacts. The path of least resistance is to survey the people you already have access to.
What it costs
A biased sample produces biased opportunity scores. If your respondents skew toward satisfied existing customers, you will underestimate the opportunity in underserved outcomes — because satisfied customers report lower importance for the things they are already getting well and lower dissatisfaction than the broader market would show. You may also completely miss segments that are not represented in your customer base at all: the non-consumers who would buy if the right need were addressed.
I have seen this mistake produce exactly the wrong strategy recommendation. A company surveyed its top 100 customers, found that most outcomes scored low-opportunity (customers were mostly satisfied), concluded that the market was well-served, and halted a planned product investment. A subsequent properly scoped study that included the competitive user base found three high-opportunity outcome clusters — unmet needs that the satisfied existing customers were compensating for through workarounds so habitual they had stopped noticing them.
The fix
Define the population before designing the survey. The right population is everyone who is trying to do the job — not everyone who currently uses your product. That includes users of competitive solutions, people using manual workarounds, and in some cases non-consumers who have a genuine need but have not found an acceptable solution. Work with a research firm or use panel services to recruit from this broader population. The investment in a proper sample pays for itself in the quality of the strategic outputs.
Mistake 5: Treating JTBD as a One-Time Project
What it looks like
The JTBD initiative runs for four months. It produces a job map, opportunity scores, and a strategic recommendation. The recommendation is incorporated into the roadmap. The JTBD materials are filed and occasionally referenced. Two years later, the competitive situation has shifted, a new market entrant is addressing outcomes you scored as low-priority, and your product is struggling in areas where your data said you were well-positioned.
Why it happens
JTBD/ODI is resource-intensive. Running the full cycle — qualitative interviews, survey design, quantitative fieldwork, analysis, strategic synthesis — takes time and budget that most organizations treat as a project investment rather than a recurring operational cost. Once the project is “done,” there is no standing budget or process for repeating it.
What it costs
The job is stable. Customer satisfaction with current solutions is not. When a competitor improves their product, outcomes that were previously low-opportunity (customers were adequately served) can become high-opportunity (the new entrant has changed the baseline expectation). If your data is two years old, your opportunity map reflects a market that may no longer exist.
The fix
Build JTBD/ODI into your planning cycle, not your project portfolio. At minimum, re-run the quantitative survey annually for your most strategically important markets. The job map and outcome statements can usually be reused with minor updates — the expensive part of the first study. The quantitative fieldwork is faster and cheaper in subsequent cycles because the infrastructure is already built. For teams that have invested in building internal JTBD capability, the annual refresh becomes a standard research operation rather than a strategic initiative.
Mistake 6: Confusing Customer Segments with Opportunity Segments
What it looks like
The team has done the quantitative research and found high-opportunity outcomes. Now they need to decide who to target. They reach for their existing segmentation: enterprise vs. SMB, by industry vertical, by geography. They map the opportunity scores to these segments and build a strategy.
Why it happens
Demographic and firmographic segmentation is familiar, available, and easy to operationalize in sales and marketing. If your CRM already slices customers by industry, it is natural to use that slice to interpret your JTBD findings.
What it costs
Demographic segments do not align with need patterns. Two surgeons at the same hospital, in the same specialty, with identical titles and tenure, may have radically different patterns of underserved outcomes — because their workflow, their team dynamics, and their personal working style lead them to struggle with different steps of the job. If you average their outcome data together under the label “surgeon,” you lose the signal that distinguishes them.
Real JTBD segmentation uses cluster analysis on the outcome data itself: group customers by the pattern of outcomes they rate as highly important and poorly satisfied. These clusters are what Ulwick calls opportunity segments — and they are almost always cut differently than any demographic or firmographic segmentation your sales team is using.
The fix
Run cluster analysis on your outcome importance/satisfaction data before applying any demographic lens. Identify the need-based segments first, then characterize them demographically second. In most ODI engagements, we find two to five distinct opportunity segments. Once they are identified, we can usually describe them in terms that sales and marketing can use for targeting — but those descriptions emerge from the data, not from the pre-existing organizational view of the market. Understanding how JTBD compares to personas makes this distinction concrete.
Mistake 7: Generating Ideas Before Opportunity Scores Are Complete
What it looks like
Midway through the JTBD process — often after the job map is built but before the quantitative survey is fielded — the team gets excited and starts brainstorming product ideas. By the time the opportunity scores come back, the team is already attached to the ideas they generated. The opportunity scores are used to justify the pre-existing ideas rather than to generate new ones.
Why it happens
Ideation is fun and feels productive. Job maps are abstract and feel like homework. The organizational pressure to “make progress” in a visible way is constant. Jumping to ideation before measurement is complete satisfies that pressure in the short term.
What it costs
Ideas generated without opportunity scores are generated in an information vacuum. They reflect the biases, experiences, and assumptions of the people in the room. When the opportunity scores finally arrive, teams that have already invested in ideas are poorly positioned to let the data change their direction. Confirmation bias takes over: high-scoring outcomes that align with pre-existing ideas get emphasized; high-scoring outcomes that would require pivoting the concept get rationalized away.
Ideation before measurement is the innovation equivalent of writing a prescription before the diagnosis. You might get lucky. But you are taking a risk you do not need to take — especially when the diagnostic tool is sitting right there.
The fix
Build a process firewall between the measurement phase and the ideation phase. Do not hold ideation sessions until the opportunity scores are analyzed and the high-priority outcome clusters are identified. Brief the ideation participants on the opportunity scores, not on the job map. Their task is to generate solutions that address specific, quantified needs — not to brainstorm generally around a job statement.
Mistake 8: Assigning JTBD to Junior Researchers
What it looks like
The VP of Product is convinced that JTBD is worth trying. She assigns the initiative to the UX research team or to a product manager who is two years into the role. They read the books, attend a workshop, and build a good-faith effort. The job map they produce is coherent. The interviews they conduct generate rich qualitative data. But the outcome statements are inconsistently formed, the survey design has methodological gaps, and the opportunity score interpretation is uncertain.
Why it happens
JTBD looks like user research, and user research is often a junior or mid-level function. The Christensen-style JTBD — rich with interview techniques and narrative — is accessible enough that a competent researcher can execute it without deep methodology training. The assumption is that ODI is an extension of the same skill set.
What it costs
ODI is a precision tool. Subtle errors in outcome statement construction propagate through the entire process: a poorly formed outcome produces unreliable survey data, which produces misleading opportunity scores, which produces a wrong strategy recommendation. A senior practitioner with deep ODI experience will catch these errors in the formulation phase — before they contaminate everything downstream. A junior researcher will not know what to look for.
The fix
Either train your team properly — which means formal die ODI-Praxis training, not a JTBD workshop — or bring in an experienced ODI practitioner for the first engagement and use it as a supervised training project. The former is an investment in capability; the latter is an investment in getting the first project right while building toward capability. Neither is cheap, but both are far less expensive than running a flawed JTBD process at scale. For teams that want to understand the JTBD canvas methodology before committing to a full engagement, it is a good starting point for calibrating expectations.
A Diagnostic Framework: Is Your JTBD Initiative on Track?
Use this checklist to evaluate any JTBD initiative — yours or a vendor’s:
Job Definition
- Does the job statement use a verb + object + contextual clarifier?
- Is the job statement fully solution-agnostic (no product references)?
- Is the job at the right level of abstraction — not too broad (survive) and not too narrow (insert bolt A into slot B)?
Outcome Capture
- Do outcome statements follow the direction + metric + object + clarifier syntax?
- Are outcomes written from the customer’s perspective, not the company’s?
- Do outcomes avoid referencing the current solution or any specific technology?
Quantitative Research
- Does the sample represent the full population of people trying to do the job — not just current customers?
- Is the sample size adequate (minimum 200 respondents; 400+ for segment analysis)?
- Is the survey designed to measure both importance and satisfaction independently for each outcome?
Analysis
- Are opportunity scores calculated using the correct algorithm?
- Is segment analysis based on outcome data, not demographic pre-segmentation?
- Are high-opportunity outcomes identified before ideation begins?
Process
- Is the project designed as a full ODI engagement, not just a qualitative study?
- Is there a plan for periodic refresh of the quantitative data?
- Are the strategic outputs connected to specific roadmap decisions?
If you cannot answer “yes” to all of these, you have identified exactly where your JTBD initiative is falling short.
Frequently Asked Questions
Avoid Costly JTBD Mistakes from the Start
Book a complimentary discovery call to explore how these ideas apply to your organization.
