jobs to be done

I taught Jobs to Be Done for six years across cohorts at Pragmatic Leaders. Thousands of PMs learned the framework, quoted Christensen, referenced the milkshake story. And then I tracked what happened after the course.

Fewer than 20% could apply JTBD within a month of learning it.

Not because they were bad PMs. Because the framework, as commonly taught, has a gap between theory and application that nobody talks about. This page is my attempt to close that gap.

The framework in sixty seconds

Clayton Christensen studied why a fast-food chain was failing to increase milkshake sales. The team had optimized flavor, thickness, price — the usual levers. Nothing moved.

Christensen’s researchers sat in the restaurant and watched. They found that most milkshakes were sold before 8 AM. Buyers were commuters. They needed something that fit in a cup holder, lasted the 40-minute drive, kept them full until lunch, and could be consumed one-handed.

The milkshake’s competition was not other milkshakes. It was bananas, donuts, bagels, and boredom. The commuters were “hiring” the milkshake for a specific job: make my morning commute less tedious and keep me full.

That is the core insight of JTBD: people do not buy products. They hire them to make progress in a specific circumstance.

The framework asks you to stop thinking about your product’s features and start thinking about the job the customer is trying to get done. The job is the unit of analysis — not the persona, not the segment, not the feature request.

Why it breaks down in practice

Here is where most JTBD training stops. You learn the milkshake story, you nod along, and then you go back to your desk and try to apply it to a B2B SaaS dashboard used by Indian mid-market companies.

It does not translate cleanly. Three reasons.

1. “Job” is too abstract for most teams to act on.

“When I am onboarding a new employee, I want to reduce time-to-productivity so I can focus on my own work” — this is a perfectly formed job statement. It is also useless for a sprint planning meeting. Your designer needs to know which screen to build. Your engineer needs to know which API to call. A job statement gives you strategic direction but zero tactical clarity.

2. Indian B2B context makes job discovery harder.

In the US, customers will tell you their problems in a 30-minute Zoom call. In India — especially in mid-market and enterprise — the buyer, the user, and the decision-maker are often three different people with three different jobs. The CFO who signs the cheque has a different job than the accounts manager who uses the software daily. JTBD as taught assumes a single “hiring” decision. Indian B2B buying rarely works that way.

3. Teams confuse job stories with user stories and nothing changes.

I have watched PMs rename their user stories to job stories — swapping “As a user, I want…” with “When I am…, I want to…, so I can…” — and believe they have adopted JTBD. The words changed. The thinking did not. They were still building feature lists, just with different sentence templates.

When JTBD actually works

Despite its limitations, JTBD is powerful in three specific situations. Use it there. Do not try to make it your universal framework.

Situation 1: You are entering a new market and do not know who the real competitors are.

JTBD forces you to look beyond category competitors. If you are building a meditation app, your competition is not just Headspace and Calm. It is YouTube lo-fi playlists, a walk around the block, scrolling Instagram, or a cup of chai. JTBD reveals the actual competitive set.

Situation 2: Your feature requests make no sense.

When customers ask for things that seem random — “add an export to PDF” next to “add a Slack integration” next to “make the dashboard load faster” — JTBD helps you find the underlying job. Often these seemingly unrelated requests share a common job: “I need to share progress with my manager without scheduling a meeting.” Now you have a design direction, not a feature list.

Situation 3: You are stuck on differentiation.

When every product in your space has the same features, JTBD helps you find differentiation at the job level. Two CRMs can have identical feature lists but serve completely different jobs — one helps salespeople manage pipeline (job: close more deals), the other helps founders track relationships (job: never lose touch with someone important).

The practical method: job mapping

Here is how I teach JTBD now — not as a philosophy but as a method you can execute this week.

Step 1: Find the struggle moment.

Do not ask customers what they want. Ask them about the last time they struggled. “Tell me about the last time you tried to [do the thing your product does] and it was frustrating.” The struggle moment is where the job reveals itself. People do not hire new products when things are going well. They hire them when something breaks.

Step 2: Map the job in four parts.

The circumstantial part is where 90% of the value lives. “Process payroll” is a job anyone can identify. “Process payroll for 200 people from Excel with Indian compliance in a two-person team” — that is a job you can build a product around.

Step 3: Identify the current “hire.”

What are they using today to get this job done? Not what product — what combination of tools, hacks, workarounds, and manual processes? In India, the answer is often “Excel plus WhatsApp plus a CA who handles compliance.” That combination is your real competitor, and it has advantages your product does not (familiarity, flexibility, trust in the CA’s expertise).

Step 4: Find the firing trigger.

People do not switch products because yours is better. They switch because something in their current solution became intolerable. A compliance penalty. A payroll error that caused an employee grievance. An audit that exposed manual mistakes. The firing trigger is the moment they start looking. Your marketing and sales should speak directly to that trigger.

Common mistakes

Mistake 1: Writing job stories for every ticket. JTBD is a discovery and strategy tool. Using it for every Jira ticket is like using a telescope to read a book. Reserve it for when you are genuinely confused about what to build or who to build for.

Mistake 2: Ignoring the circumstantial context. “People want to save time” is not a job. It is a platitude. Without the circumstance — who, when, where, what constraints — a job statement has no actionable information.

Mistake 3: Treating JTBD as a replacement for personas. JTBD and personas answer different questions. Personas tell you who your user is. JTBD tells you what they are trying to accomplish. Use both. The payroll HR manager (persona) processing salaries under Indian compliance rules (job) — you need both halves to build the right thing.

Test yourself

Where to go next

• The skill that makes JTBD interviews work: User Research Methods — interview techniques, open-ended questions, and how to probe behavior instead of opinions.
• Connecting jobs to what you build: Writing PRDs — how to translate a job into a spec your team can execute.
• The broader discovery toolkit: Market Research — competitive analysis, sizing, and positioning.
• Thinking clearly before reaching for frameworks: Product Thinking — first principles, hypothesis-driven development, and the discipline of asking why before what.