Jobs to Be Done for B2B Product Teams

TL;DR. Jobs to Be Done (JTBD) says people don't buy products, they "hire" them to make progress on a specific job. In B2B, that job usually splits in two: the buyer's job (justify the spend, de-risk the decision, look good to their boss) and the user's job (get the work done day to day) — and they are often in tension. Find both by interviewing around a recent purchase or switch, not by asking people what features they want. Turn the jobs you find into roadmap decisions by scoring backlog items on how directly they advance the job, not how many people asked for them.

What is Jobs to Be Done?

Jobs to Be Done is the idea that customers "hire" a product to make progress on a job in their life or work — and they'll "fire" it for something that does the job better. The job is the unit of analysis, not the customer segment and not the feature. A job is stable even when solutions change: "get accurate visibility into pipeline health" was a job long before CRMs existed, and it will outlive whichever tool answers it today.

The framework's discipline is refusing two easy shortcuts:

• It is not a persona. "VP of Sales, 40s, data-driven" describes a person, not a problem. Two VPs of Sales can be hiring your product for completely different jobs.
• It is not a feature request. "I want a Slack integration" is a solution someone invented on the spot. The job underneath might be "know about a stalled deal before my Monday pipeline review" — which a Slack integration is one of several ways to solve.

Why B2B splits the job in two

Consumer JTBD usually has one job-holder: the person who decides and the person who uses are the same. B2B rarely works that way. A tool gets bought by someone with budget authority and used by someone who may never see the invoice. Treating that as one undifferentiated "customer job" is the most common JTBD mistake in B2B product teams, and it quietly produces roadmaps that ship features nobody asked for and skip the one thing that would close deals.

	The buyer's job	The user's job
Who holds it	Economic buyer, champion presenting upward	Day-to-day user
Typical job statement	"Get a decision I won't have to defend in six months"	"Get this task done with the least friction"
What satisfies it	ROI proof, security sign-off, migration plan, references	Speed, clarity, fewer clicks, fits existing workflow
Where it shows up	Procurement, security review, renewal conversation	Onboarding, daily usage, support tickets
Fails silently as	Champion goes quiet after a good demo	High signup, low activation

The two jobs are related but not identical, and they can conflict. A feature that makes the buyer's job easier — heavy admin controls, audit logs, approval workflows — can make the user's job harder if it adds friction to daily use. A product-led growth motion is, in JTBD terms, a bet that nailing the user's job well enough will do most of the work of satisfying the buyer's job too. That bet doesn't hold at every price point or in every regulated industry, which is why enterprise software still needs a separate answer for procurement.

Good B2B discovery interviews for both jobs separately, on purpose, even when the buyer and user are the same person wearing two hats at different points in the deal.

How to interview for jobs to be done

The reliable version of a JTBD interview reconstructs a real event — the moment someone went looking for a new way to solve the problem — rather than asking hypothetical questions about the future. Structure:

1. Anchor to the switch. Start with: "Take me back to the day you first looked for something like this." Not "what do you need," but "what actually happened."
2. Walk the timeline in order. What was going on right before that moment (the push)? What made this tool attractive specifically (the pull)? What almost stopped them from switching (the anxiety)? What kept them tied to the old way even as it failed them (the habit)? Note the first thought too — the earliest moment they can point to when the old way stopped being enough — it belongs on the switching timeline, not among the four forces, but it's often where the push began.
3. Separate the buyer thread from the user thread. If you're talking to the buyer, ask what they had to prove internally. If you're talking to the user, ask what made a Tuesday afternoon with the old tool painful.
4. Listen for forces, not features. "It was faster" is a feature comment. "My manager asked me twice in one week why the numbers didn't match" is a force — a specific, dated moment of pressure. Forces are what you're actually mining for.
5. Resist solutioning in the room. When someone says "I wish it just did X," ask "what were you trying to accomplish right before you wished that" instead of writing X on the roadmap. This is the same discipline behind good prioritization work — the request is a clue, not a spec.

Run 8–12 of these interviews per job you're trying to understand. Patterns across switch stories are far more reliable than a single detailed one, and far more reliable than a survey — surveys ask people to generalize about their own behavior, which people are bad at.

Turning jobs into roadmap decisions

Once you have job statements for both the buyer and the user, they earn their keep by changing what you build next, not by decorating a slide.

• Write the job as a testable sentence. Format: "When [situation], I want to [motivation], so I can [expected outcome]." A vague job ("be more productive") can't discipline a roadmap; a specific one ("when a deal stalls for 5+ days, I want to know before my pipeline review, so I can intervene before my manager notices") can.
• Score backlog items against the job, not against request volume. For each candidate feature, ask: does this directly advance the job statement, remove a force holding someone back, or reduce an anxiety about switching to us? Ten customer requests for a feature that's adjacent to the job but doesn't advance it should lose to one request that removes a real blocker.
• Segment your ICP by job, not just firmographics. Two companies with identical headcount and industry can be hiring you for different jobs — one to replace a spreadsheet, one to pass a compliance audit. Their roadmap weight should differ accordingly.
• Re-run interviews when the job might have shifted. Jobs are stable relative to solutions, but they do move — a company that hired you to solve "get set up fast" during a scramble may later be judging you on "prove this was worth the money" at renewal. That's the buyer's job resurfacing on a different clock.

The output of good JTBD work isn't a new document type — it's a roadmap where every line traces back to a specific, evidenced force in a specific job, for either the buyer or the user, instead of an averaged wish list.

Related reading

• How to Build an Ideal Customer Profile (ICP) — segmenting accounts by evidence, the natural next step after mapping jobs.
• Product Strategy, Explained — where job statements feed the strategic narrative.
• Prioritizing 101 for PMs — turning discovery input, including job statements, into a defensible backlog order.
• What Is Product-Led Growth? — the motion that bets on the user's job carrying the buyer's job with it.