JTBD in B2B vs B2C: Why the Same Framework Behaves Differently

JTBD behaves differently in B2B and B2C because the unit of analysis changes. In B2C, one person feels the struggle, chooses the product, pays for it, and uses it — the job belongs to them alone. In B2B, a committee of four to ten people shares one purchase decision, and each person is hiring the same product to solve a different problem: functional, financial, political, or careerist.

Quick answer: In B2C, Jobs-to-be-Done research targets a single job-holder with one dominant story of progress. In B2B, the "job" is really a bundle of five or more competing jobs — the end user's functional job, the economic buyer's ROI job, IT's risk job, and the champion's career job — and a roadmap that satisfies only one of them stalls in procurement or churns at renewal.

Why the Same Question Gets Different Answers in B2C and B2B

JTBD asks a deceptively simple question: what progress is this person trying to make, and what are they hiring a solution to do? In B2C, that question has one respondent. In B2B, it has several, each with a different stake — so the "correct" job statement depends entirely on whose desk you're standing at.

This is easy to miss because the research method looks identical on the surface. You still run struggle-moment interviews. You still write when / I want to / so I can statements. You still map forces of progress. What changes is the object you're studying.

Christensen's original milkshake study works cleanly because the commuter buying the milkshake is also the one drinking it. That clean overlap disappears the moment "the customer" is actually an org chart. For the mechanics of the base framework, see our complete guide to Jobs-to-be-Done — what follows here is specifically about what breaks when you apply it to enterprise buying.

The practical failure mode is a PM who moves from consumer to enterprise (or back) and keeps running the same playbook. They interview one persona, write one job statement, and wonder later why a well-loved feature didn't move renewal numbers. The theory didn't fail; the scope did.

The Buying Committee Is a Bundle of Competing Jobs

Enterprise research from Gartner puts a typical B2B purchase decision in the hands of roughly six to ten stakeholders, and Geoffrey Moore's classic distinction from Crossing the Chasm — economic buyer, technical buyer, user buyer — still holds up decades later. Each role is, quite literally, hiring your product for a different job, and none of them is wrong about their own.

Here's what that looks like when you break a typical enterprise SaaS deal down by role:

None of these are secondary jobs. They're all primary, within their role. Anthony Ulwick's Outcome-Driven Innovation work treats each stakeholder's desired outcomes as separately scoreable — importance and satisfaction rated independently per role, not blended into one average persona that represents nobody.

That's the core mechanical difference from consumer JTBD: in B2B, you're not looking for the job. You're mapping a small portfolio of jobs and deciding which underserved ones are worth building for first.

Emotional and Social Jobs Quietly Run the Enterprise Deal

In consumer JTBD, the emotional job is usually personal — feel confident, feel healthy, feel in control of a chaotic moment. In B2B, the dominant emotional and social jobs are almost always about career risk: not looking incompetent to a manager, not being blamed if the tool underdelivers, and being seen as the person who solved a real problem.

Bob Moesta's Forces of Progress framework — push, pull, anxiety, habit — describes every purchase as a tug-of-war between the discomfort of the current situation and the pull of something new, held back by anxiety and existing habits.

In B2B, the anxiety force is rarely "will this software actually work?" It's closer to "will backing this decision make me look bad in six months, in front of people whose opinion of me matters for my next promotion?"

That reframing matters for roadmap decisions. A feature that's functionally excellent but does nothing to reduce a champion's political exposure, or an IT buyer's audit anxiety, will get quietly deprioritized in renewal conversations even if usage metrics look fine. The social and emotional jobs aren't a soft layer on top of the "real" functional job — in enterprise deals, they're frequently the deciding factor.

This is also where B2B JTBD research diverges hardest from B2C: you're not just asking "what were you trying to accomplish," you're asking "what happens to you personally if this goes wrong," and that second question rarely comes up unprompted.

When the Executor's Functional Job and the Buyer's ROI Job Pull the Roadmap Apart

Consider accounts-payable automation software sold into a mid-market finance team. The AP analyst's functional job is "get invoices approved without chasing five people over Slack." The CFO's economic job is "cut days payable outstanding and prove this tool's ROI before renewal." Those two jobs pull the same roadmap toward opposite features.

Here's how that tension typically plays out:

1. The analyst wants: faster approval routing, fewer clicks, in-app nudges to whoever's sitting on an invoice — this reduces personal friction and the awkwardness of nagging colleagues by hand.
2. The CFO wants: a dashboard showing the days-payable-outstanding trend, dollars saved versus the old process, and an audit trail defensible in a board meeting — this proves the line item was worth it.
3. If the roadmap only serves the analyst's job: the renewal conversation has no hard numbers behind it. The CFO can't defend the spend, and the contract becomes a target for cost-cutting.
4. If the roadmap only serves the CFO's job: analysts keep manually chasing approvals because the workflow never got easier. Adoption stalls, and the usage data behind that beautiful ROI dashboard turns out to be thin.

Notice the loop: weak adoption undercuts the ROI story, a shaky renewal case starves the budget for the executor-facing polish that would drive adoption, and low buy-in suppresses usage further. That's a reinforcing feedback loop of exactly the kind covered in our guide to systems thinking in product work — the fix isn't picking a side, it's recognizing the two jobs are structurally linked and need to ship together, not sequentially.

Writing job statements for both roles — instead of one generic "user" story — is also what keeps this nuance from getting flattened when it reaches engineering. Our piece on job statements that survive the engineering handoff covers how role-specific context tends to get lost in translation if it isn't made explicit in the ticket itself.

Writing and Weighting Job Statements Across a Committee

A single blended job statement can't represent five different stakeholders at once, so the practical fix is to write one statement per role, score each independently on importance and satisfaction, and let the resulting opportunity gaps — not an averaged persona — decide what ships first.

Using the standard when / I want to / so I can structure from our guide to writing a JTBD job statement, the analyst and CFO statements from the example above look like this:

• Analyst: "When an invoice is stuck waiting on someone else's sign-off, I want to see exactly who's holding it up and nudge them in one click, so I don't look like I'm the one behind on my own work."
• CFO: "When the board asks why we spent on this tool, I want a report that ties usage directly to reduced days payable outstanding, so I can defend the line item without guessing."

From there, apply Ulwick's opportunity-score formula — importance plus the gap between importance and satisfaction — separately to each role's job, rather than to one merged average. Our breakdown of the opportunity score formula walks through the math in detail. A few practical rules follow from doing this per-role:

1. Interview across roles, not just whoever signed the last contract or shouts loudest in the kickoff call.
2. Write a distinct job statement per role using a consistent format, so statements can be compared apples-to-apples.
3. Score importance and satisfaction independently for each role's job — don't blend them into one number.
4. Prioritize features that resolve an underserved job for two or more roles at once; these are usually your highest-leverage bets.
5. Explicitly flag, and sometimes kill, features that only satisfy one role's job at another role's expense.

That last point is the one teams skip. Building only for the loudest voice in the room — often the economic buyer, because they sign the check — is exactly how you end up with a reporting-heavy tool that the people actually using it quietly resent.

Where Prodinja Fits: Tracking a Committee's Competing Jobs

The hardest part of B2B JTBD isn't writing one good job statement — it's keeping five of them straight as stakeholders change roles, go quiet mid-deal, or get replaced, which is exactly the gap between a jobs framework on a whiteboard and a live account with real politics.

Prodinja's Customer Jobs tool is built around this JTBD-plus-Ulwick-opportunity-scoring approach, including prompts modeled on Moesta's Forces of Progress, for capturing and scoring job statements. For B2B jobs specifically, that tool is designed to work alongside Prodinja's Stakeholders CRM, which tracks each contact's role along with computed relationship health and alignment debt, and the Relationship Map, which lets you drag out an org-chart-style read of who reports to whom and who influences whom.

Together, they're meant to let a PM see at a glance which stakeholder's job is currently the underserved one — instead of relying on memory of a call from three months back, or discovering during renewal that nobody had been tracking the champion's job at all.

Key Takeaways

• B2C JTBD targets one job-holder; B2B JTBD targets a committee. Gartner's research puts typical B2B buying groups at roughly six to ten people, each hiring the purchase for a distinct reason.
• Geoffrey Moore's economic/technical/user buyer split is still the fastest way to spot competing jobs in an enterprise deal — map each role's job before writing a single feature spec.
• Emotional and social jobs in B2B are usually about career risk, not personal feeling — looking competent, avoiding blame, and protecting political capital drive decisions more than raw functionality.
• A functional job and an economic (ROI) job can pull the same roadmap in opposite directions, and building for only one creates a reinforcing loop that undermines renewal.
• Score jobs per role, not blended. Use Ulwick's opportunity-score formula independently for each stakeholder, then prioritize what resolves underserved jobs across multiple roles at once.
• Write a distinct job statement per role, using a consistent format, so different roles' needs stay legible instead of collapsing into one generic "user" story by the time engineering sees it.