Design Thinking vs. Jobs to Be Done: What Works Better?

Two Frameworks, One Question

Design thinking and Jobs to Be Done — both promise better products through better customer understanding. Both have prominent advocates, impressive client references, and substantial consulting communities built around them.

But they are fundamentally different in their logic, their methods, and what they actually produce. A product team that understands both can deploy them with precision. A product team that knows only one has blind spots.

This article is not a diplomatic comparison that ends with “both are useful, it depends.” It is an honest assessment of strengths, weaknesses, and conditions — with clear recommendations for when each approach creates the most value and when it falls short.

Design Thinking: What It Is and What It Delivers

The Core

Design thinking was formalized in the 1990s at Stanford’s d.school and IDEO. It is an iterative process with five phases:

1. Empathize: Observe users, conduct interviews, understand context and lived experience.
2. Define: Articulate the problem — typically as a “Point of View” statement or “How Might We” question.
3. Ideate: Generate as many solution ideas as possible, without evaluation.
4. Prototype: Build simple, rapid prototypes of promising directions.
5. Test: Test prototypes with users, incorporate feedback, iterate.

The Genuine Strengths

Empathy generation. Design thinking creates genuine understanding of the user and their context. For teams that have spent years thinking primarily about their product rather than the person using it, the empathy phase is revelatory. It opens eyes.

Creative divergence. The ideation phase, with its explicit rule that no idea is a bad idea, encourages divergent thinking. This can produce unexpected solution approaches that more analytical processes would not surface.

Rapid prototyping culture. The emphasis on building something quickly and simply lowers the organizational threshold for experimentation. Instead of spending months planning, teams build something testable in hours.

Interdisciplinary collaboration. Design thinking brings different professional perspectives into the same room — designers, engineers, business strategists — and gives them a shared process for working together.

Accessibility. Design thinking is learnable in days and teachable in workshops. This makes it popular and broadly deployable across organizational levels.

The Honest Weaknesses

No prioritization mechanism. Design thinking has no built-in way to determine that this customer problem is five times more important than that one. The empathy phase surfaces many problems — but not a ranked assessment of their strategic significance. Prioritization happens through team consensus (“dot voting”), facilitation judgment, or management decision — all of which are subjective.

Premature convergence on solutions. The process moves to idea generation relatively quickly after an empathy phase. After a two-day empathy sprint, the team is brainstorming solutions — without having systematically identified all relevant customer needs. The result: creative solutions to partially defined problems.

Not quantitative. Design thinking produces qualitative insights: stories, observations, empathy maps, journey maps. It does not produce statistically defensible data on which customer needs are most important, how satisfied customers currently are with existing solutions, or how large different customer segments are.

Facilitator dependence. The quality of a design thinking workshop depends heavily on the facilitator’s skill. An experienced design thinking facilitator can guide the process productively. An inexperienced one produces elaborate Post-it displays with little strategic content.

No segmentation. Design thinking identifies user types through personas but does not segment by patterns of unmet needs. It cannot show that 34 percent of customers have a specific, highly important unmet need that the other 66 percent do not share — which is precisely the segment data that drives strategic product decisions.

Jobs to Be Done: What It Is and What It Delivers

The Core

Jobs to Be Done (JTBD) rests on the insight that customers do not buy products — they hire products to accomplish goals. Outcome-Driven Innovation (ODI), the operational methodology built on JTBD theory, has six steps: define the market, discover customer needs as desired outcomes, quantify those needs, identify opportunity segments, formulate a growth strategy, and generate directed solution concepts.

The Genuine Strengths

Systematic need identification. JTBD/ODI captures 100 to 150 desired outcomes — solution-independent, measurable statements of customer need at each step of the job. That is categorically more complete than any empathy map or customer journey map.

Quantitative prioritization. Every outcome is rated by a representative customer sample on importance and satisfaction. The opportunity score — Importance + (Importance − Satisfaction) — shows with statistical confidence where the largest growth opportunities lie. This replaces opinion with evidence in the most consequential product decisions.

Need-based segmentation. ODI identifies customer segments defined by their patterns of unmet needs, not by demographics. These segments are strategically actionable: they tell you which group of customers will pay for better solutions and what specifically those solutions must deliver.

Reproducibility. The process is standardized. Two different teams analyzing the same job with rigorous ODI methodology will arrive at comparable results. Design thinking outcomes vary substantially based on who is in the room and who is facilitating.

Direct strategic application. JTBD/ODI does not just produce insights — it produces the inputs for a data-grounded product strategy, roadmap, and concept evaluation. The output connects directly to investment decisions.

The Honest Weaknesses

Not inherently creativity-generating. ODI tells you what customers need — not how to solve it. Solution generation is deliberately separated from need identification. This is methodologically correct, but it can frustrate teams that want to build something quickly.

Time-intensive. A full ODI project takes three to six months, requires qualitative interviews, quantitative surveys, and statistical analysis. It is not a sprint workshop.

Methodologically demanding. Formulating desired outcomes correctly requires training. Interpreting opportunity scores and segment data requires experience. Without methodological competence, errors in the qualitative phase produce unusable data in the quantitative phase.

Less immediately tangible. Design thinking produces prototypes you can touch and experience. ODI produces data tables and opportunity score rankings that must be interpreted. For teams accustomed to visual, tactile work, ODI can feel abstract.

The Direct Comparison

Design thinking is an excellent entry point into customer-centric work. It opens eyes and shifts perspectives. But it is not a strategic tool. When you need to decide where to direct your next €5 million of development investment, you need quantified data — not Post-its. The problem is not that design thinking is bad. The problem is when it is applied to decisions it was not designed to answer.

When to Use Design Thinking

1. When Your Team Is Starting to Work Customer-Centrically

If your team has spent years thinking primarily about the product rather than the job the customer is trying to accomplish, design thinking is a valuable first step. The empathy phase changes perspective. The value is cultural as much as analytical: “we now think from the customer outward” is a genuine organizational achievement.

2. When You Are in Early Exploration Mode

If you do not yet know in which direction to innovate — if you are scanning possibilities, gathering inspiration, exploring adjacent spaces — design thinking is useful as a divergence tool. It opens the space of possibilities before narrowing.

3. When You Are Solving UX and Interface Questions

For the design of user interfaces, interaction flows, and product experience questions, design thinking is in its element. Rapid prototyping and usability testing are proven approaches for UX work. When the strategic direction is already set and the question is “how should this work for users,” design thinking delivers well.

4. When You Want to Mobilize and Align a Team

Design thinking workshops build team cohesion, encourage cross-functional collaboration, and generate genuine energy. If the objective includes cultural alignment and capability building alongside idea generation, design thinking serves those purposes effectively.

When to Use JTBD / ODI

1. When You Need to Make Strategic Product Decisions

When the question is “in what direction do we develop this product for the next three years?” or “which customer segment should we prioritize?”, you need quantified customer data. Design thinking does not provide this.

2. When You Are Working a Saturated Market

In markets that appear to offer no room for innovation, ODI consistently reveals hidden opportunities: needs that all existing solutions address inadequately, visible only when you map the full job and measure satisfaction against importance across all outcomes — not just the ones customers complain about loudest.

3. When You Work in Complex B2B Markets

Industrial markets — mechanical engineering, MedTech, process technology, B2B software — have complex jobs with many steps and hundreds of desired outcomes. The systematic decomposition that JTBD/ODI provides is necessary for this complexity. Design thinking’s empathy phase is not built for this depth of analysis.

4. When You Need Objective Evidence for Stakeholder Discussions

When product direction is internally contested — and it almost always is — opportunity scores provide an objective basis that moves the discussion from “whose preference wins” to “what does the evidence indicate.” That shift in the nature of the conversation is valuable regardless of what specific decisions are made.

5. When You Want to Measurably Improve Your Innovation Success Rate

Moving from a product launch success rate of 20 percent to 80 percent requires a systematic process with quantitative validation. Design thinking alone does not accomplish this. The documented success rate of ODI-guided launches is 86 percent — a benchmark that no methodology built primarily on qualitative empathy can match consistently.

The Combination: When Design Thinking Meets JTBD

The most sophisticated answer to the design thinking vs. JTBD question is often: both — but in the right order.

Step 1: JTBD/ODI for Strategic Direction

Define the job. Capture desired outcomes. Quantify opportunity. Identify segments. The output is a set of target coordinates: “These 12 outcomes are underserved. These outcomes represent the highest strategic opportunity in this segment.”

Step 2: Design Thinking for Solution Generation

Use the ODI outputs as the briefing for a design thinking workshop. Instead of the generic “how might we improve our product?”, the design brief becomes: “How might we address Outcome #34 (‘Minimize time to reconfigure for varying soil conditions’) better than any current solution?”

This is design thinking with target coordinates. The empathy phase becomes shorter because the direction is established. The ideation phase becomes more productive because it is focused. The prototype evaluation has a clear criterion: does this prototype address the prioritized outcomes?

Step 3: Quantitative Concept Validation

After the design thinking workshop, evaluate the developed concepts against the ODI data: which concept addresses the most underserved outcomes? Which concept has the largest potential improvement to the aggregate opportunity score?

This closes the loop: the creative output of design thinking gets filtered through the strategic rigor of ODI before investment decisions are made.

An Honest Note on Adoption Patterns

Design thinking has a strong community, prestigious academic institutions, and major consulting firms behind it. It is deployed far more frequently than JTBD/ODI. That is not because it is more effective at strategic product decisions. It is because it is easier to sell.

A two-day design thinking workshop costs relatively little, produces visible outputs, generates energy, and gives participants the feeling of having done something meaningful. A four-month ODI project costs more, requires sustained organizational commitment, and produces outputs — data tables and ranked opportunity scores — that look less impressive than a wall of colorful prototypes.

But the question is not which approach feels more productive in the short term. The question is which approach produces better product decisions. The evidence is unambiguous: ODI-guided product launches succeed at a documented rate of 86 percent. The success rate of design-thinking-guided launches is not systematically measured — which is itself an indication of how the methodology’s advocates think about accountability.

Design thinking is a valuable creative tool. It belongs in the innovation toolkit. But used as a strategic decision-making mechanism — as a substitute for quantified customer data when allocating serious R&D investment — it is the wrong tool applied to the wrong problem.

The right role for design thinking is as a solution-generation engine, deployed after JTBD/ODI has established what needs to be solved and for whom.

Frequently Asked Questions