Jobs to Be Done on MYLES — Strategy & Innovation Consulting

From JTBD to Product Requirements: Bridging the Gap

Sun, 15 Mar 2026 00:00:00 +0100

The Most Dangerous Gap in Product Development

You did the research. You mapped the job. You captured 130 desired outcomes, surveyed 300 customers, and identified 15 outcomes with opportunity scores above 12. You know — with quantitative confidence — what your customers need.

And then nothing happens.

The JTBD insights sit in a research report. The product roadmap continues on its pre-existing trajectory. Engineering works on features that were decided before the research was complete. The beautifully constructed JTBD Canvas hangs on a wall, admired and ignored.

Functional, Emotional, and Social Jobs: Understanding the Full Picture

Sun, 15 Mar 2026 00:00:00 +0100

The 70% of Customer Needs That Your Product Team Ignores

When I ask product teams in manufacturing and MedTech what their customers need, the answer invariably focuses on performance specifications. Faster cycle times. Higher precision. Better durability. Lower weight. More throughput.

These are functional needs — and they matter. But they are not the whole picture. Not even close.

In every JTBD/ODI study we have conducted — across loader cranes, surgical instruments, feeding systems, power management, agricultural equipment — emotional and social outcomes account for 30-40% of the total underserved need landscape. In some categories, they dominate it. A product team that captures only functional needs is making investment decisions based on 60-70% of the available information. They are leaving the rest to chance — and to competitors who pay attention.

How to Conduct a JTBD Interview: Questions, Process, and Template

Sun, 15 Mar 2026 00:00:00 +0100

Why Most Customer Interviews Produce Useless Data

Your team runs customer interviews. You hear phrases like “it would be great if…” and “we really need a way to…” and “our biggest pain point is…” You diligently record these insights, synthesize them into themes, and feed them into your product roadmap.

And then you build the features, launch them, and discover that adoption is lukewarm.

The problem is not that you talked to the wrong customers. The problem is that you asked questions designed to extract feature requests when you should have been asking questions designed to extract desired outcomes. Traditional customer interviews are solution-oriented — they probe what customers want in a product. JTBD interviews are outcome-oriented — they probe what customers are trying to accomplish and how they measure success.

Jobs to Be Done Canvas: A Step-by-Step Guide

Sun, 15 Mar 2026 00:00:00 +0100

The Tool That Makes JTBD Actionable

Jobs to Be Done is a powerful theory. But theory without structure is philosophy, not strategy. The JTBD Canvas is the structured tool that transforms JTBD thinking into a documented, shareable, and actionable artifact that product teams can use to drive decisions.

If you have ever walked out of a JTBD workshop with sticky notes full of insights and no clear path forward, you know the problem. The Canvas solves it. It provides a single-page framework that captures the job, its context, the job map, desired outcomes, emotional and social dimensions, and the current competitive landscape — all in a format that a product manager can present to an engineering team, a VP can present to a board, or a cross-functional team can use as a working reference.

Jobs to Be Done Method: A Guide for Product Managers

Sun, 15 Mar 2026 00:00:00 +0100

Why a Forty-Year-Old Insight Is Still Misunderstood

“Jobs to Be Done” sounds like an MBA buzzword. And yes, the framework comes from Harvard — developed by Clayton Christensen, then operationalized into a rigorous methodology by Tony Ulwick. But the reason it persists, decades after its introduction, is not because consultants like selling it. It is because the core insight keeps proving itself correct.

The insight: People do not buy products. They hire products to do a job in their lives.

JTBD Examples: Real-World Applications in Manufacturing and MedTech

Sun, 15 Mar 2026 00:00:00 +0100

Beyond the Milkshake: JTBD Where It Matters Most

Every article about Jobs to Be Done tells you about milkshakes and morning commutes. These examples are useful for explaining the concept. They are useless for showing you how JTBD works in contexts where product decisions carry multi-million euro consequences, regulatory constraints shape what is possible, and the end user’s job literally determines whether people live or die.

This article presents JTBD applications from the industries where I have spent the past two decades: manufacturing, construction equipment, and MedTech. These are real scenarios drawn from companies operating in the DACH region — Palfinger in loader cranes, Fresenius in enteral nutrition, and MOTUS in mobility solutions. The details are illustrative and drawn from public information and our podcast discussions (episodes #7, #12, and #41), with some specifics generalized to protect proprietary information.

JTBD for B2B: How Enterprise Product Teams Use Jobs Theory

Sun, 15 Mar 2026 00:00:00 +0100

JTBD Was Built for Consumer Products. B2B Needs Something Different. Right?

Wrong.

This is the most common objection I hear when presenting Jobs to Be Done to B2B product teams: “Our market is different. We have buying committees, not individual consumers. Our sales cycles are 12 months, not 12 minutes. Our customers are engineers, not milkshake buyers. JTBD does not apply here.”

It applies here more than anywhere. And the reason is precisely the complexity that B2B teams cite as the objection.

JTBD vs. Personas: Why Traditional Segmentation Fails

Sun, 15 Mar 2026 00:00:00 +0100

The Six Personas That Were All Wrong

A medical device company — a mid-size European firm with strong positions in surgical instruments — came to us with a problem. They had invested six months and a significant budget developing buyer personas for their flagship product line. Six detailed profiles: “Efficient Eva,” “Research-Driven Rainer,” “Budget-Conscious Barbara,” and three others. Each persona had a name, a photo, a backstory, demographics, psychographics, goals, frustrations, and preferred information channels.

The Complete Guide to Jobs to Be Done

Sun, 15 Mar 2026 00:00:00 +0100

Why Most Innovation Fails — and What Jobs to Be Done Changes

Here is a number worth pausing on: industry research consistently puts the new-product failure rate at roughly 70% — Doblin’s well-known study reported 96% across all innovation initiatives; subsequent academic work has put the figure for new consumer products in the 70–80% range. Whichever number you trust, the majority of new products do not meet their financial targets. Not because teams lack talent. Not because budgets are thin. They fail because teams build products around what they think customers want rather than understanding what customers are actually trying to accomplish.

What Are Jobs to Be Done? A Primer for Product Leaders

Sun, 15 Mar 2026 00:00:00 +0100

The Question Your Product Team Is Not Asking

Every product team asks some version of “what do customers want?” It is the default question. It drives surveys, focus groups, advisory boards, and roadmap meetings. And it is the wrong question.

Customers do not want products. They want progress. They want to move from a current state — marked by frustration, inefficiency, risk, or dissatisfaction — to a better state. Products are just the means. When your product team focuses on what customers want in a product, they get a list of feature requests filtered through the customer’s limited awareness of what is technically possible. When they focus on what progress customers are trying to make, they get a durable understanding of the market that outlasts any single product generation.

The History of JTBD: From Christensen to Ulwick to Modern Practice

Sun, 08 Mar 2026 00:00:00 +0100

Two Men, One Idea, a 30-Year Argument

The history of Jobs to Be Done is not a clean origin story. It is a messy, contested, productive intellectual dispute between two of the most influential thinkers in innovation, each of whom claims a different version of where the idea came from and what it actually means.

Clayton Christensen, the Harvard Business School professor who coined the phrase, saw JTBD primarily as a narrative lens — a way of telling stories about customer motivation that made product decisions feel more human. Tony Ulwick, the practitioner who worked alongside Christensen at the beginning, saw something entirely different: a quantitative framework for eliminating product failure by measuring unmet needs with statistical precision.

Why JTBD Fails: Common Mistakes and How to Avoid Them

Sat, 07 Mar 2026 00:00:00 +0100

“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.

JTBD vs. User Stories: When to Use Which

Fri, 06 Mar 2026 00:00:00 +0100

A False Competition That Is Costing Product Teams Time

Every few years, the product management community invents a new thing that is going to replace user stories. Design thinking replaced them. Now JTBD is replacing them. Except user stories keep showing up in sprint planning, and the teams that abandoned them for something more sophisticated often find themselves arguing about what a feature should do without any shared language to resolve the argument.

The Job Map: Mapping What Customers Are Trying to Accomplish

Thu, 05 Mar 2026 00:00:00 +0100

The Mistake Everyone Makes Before Building a Job Map

When product teams discover Jobs to Be Done, they typically start in the same place: they write a job statement and then immediately ask “what do customers want?” They generate a list of needs, rank them by frequency of mention in qualitative interviews, and call the result a job map.

It is not a job map. It is a prioritized list of feature anecdotes organized under a job statement header. And it fails — consistently and predictably — because it skips the step that makes the job map actually useful: decomposing the job into its functional process steps before identifying any outcomes.