What's the difference between a job statement and a persona?

A persona describes who a buyer is — title, company size, demographics. A job describes the circumstance and progress a buyer was seeking when they hired a product. Two people with the same title can have completely different jobs, which personas obscure.

How do I know if my JTBD statements are real or made up?

Ask where each one came from. If it was written by your product or marketing team in a workshop, it's a hypothesis. If it came from an interview with someone who actually switched, and the same trigger repeats across multiple interviews, it's evidence.

What questions should I ask in a Jobs to be Done interview?

Situational ones: what were you doing right before you started looking for a new solution, what specifically triggered the search, what else did you try first, and what almost stopped you from switching. Avoid attitudinal questions about preferences in the abstract.

How many customer interviews do I need before trusting a job statement?

There's no fixed number, but the discipline matters more than the count: track how many interviews independently describe the same trigger. A pattern repeating across most of your interviews is a signal; a trigger mentioned once or twice out of ten is likely noise.

Jobs to be Done: what your product is actually hired for

Q: Who came up with Jobs to be Done?

It's most associated with Clayton Christensen, who popularized it as part of his innovation work, with substantial contribution from Bob Moesta, who developed much of the switch-interview methodology used to surface real jobs from customer behavior.

Guide · frameworks · 5 min read · last verified 2026-07-21

Reviewed before publication Editorial board Independent commercial review

In shortJTBD becomes a persona exercise in a job-shaped template the moment it skips real switch interviews. Here's how to source job statements from evidence, with a worked pattern-check.

The product is not the job

Jobs to be Done starts from a simple reframe: customers don't buy products because of what the products are, they hire them to make progress against a specific problem in a specific circumstance. The idea is most associated with Clayton Christensen, who popularized it as part of his work on innovation, with substantial contribution from Bob Moesta, who developed much of the interview methodology used to actually surface jobs from real customer switching behavior. It's a genuinely useful reframe — but in B2B SaaS it gets flattened into something much weaker almost every time it's adopted.

Where JTBD becomes a persona exercise wearing a costume

The most common failure: a product or marketing team sits in a room and writes "job statements" like "When I am a project manager, I want a real-time dashboard, so I can see status at a glance." Read that sentence again — it's not a job, it's a restated feature with a job-shaped grammar wrapped around it. It describes what the product does, not the underlying progress the buyer was trying to make before your product existed, and it was produced entirely by internal guessing, with zero customer contact.

This happens because JTBD is procedurally easy to fake. The "When I... I want to... so I can..." template is simple to fill in from a whiteboard, and it looks methodologically rigorous because it has a name and a format. But the format isn't the method — the method is where the statement comes from. A job statement generated by your product team describes your product team's assumptions. A job statement generated from an actual interview with someone who recently bought or recently churned describes reality, or at least one data point of it.

The second common failure is treating JTBD as a rebrand of personas: swapping "IT Director persona" for "IT Director job" without changing the underlying research method. Demographics and titles are not jobs. Two people with the identical job title can be hiring your product for completely different reasons, in completely different circumstances, and a job statement pinned to a title obscures that instead of revealing it.

What an honest job statement requires

A real job comes from a switch interview — talking to someone who recently made a decision (bought, upgraded, churned, or actively chose not to buy) and reconstructing, in detail, the circumstance that led to that decision. The questions that matter are situational, not attitudinal: What were you doing right before you started looking for a new solution? What specifically triggered the search — a bad outcome, a deadline, a new requirement from someone above you? What else did you consider or try first? What almost stopped you from switching?

Within the JTBD tradition associated with Christensen and Moesta's work, this is often organized around a small set of forces acting on a buyer at the moment of decision: dissatisfaction with the current way of doing things (the push), the appeal of a new approach (the pull), anxiety about whether the new thing will actually work (the friction of switching), and the habit or inertia of the status quo (the pull back toward what's familiar). You don't need to adopt that exact vocabulary to get value from the method — the core discipline is the same regardless of terminology: find the trigger event, not the demographic.

The output of doing this honestly is a job statement grounded in a circumstance, not a persona: not "IT Directors want better dashboards" but something like "when a compliance audit surfaces a gap the current spreadsheet process can't catch in time, and the person responsible for the audit response has no way to show real-time status to the auditor, they go looking for a tool that can produce an audit-ready view without weeks of manual reconciliation." That's specific enough to be wrong, testable against more interviews, and useful for positioning in a way "wants better dashboards" never will be.

Worked example: telling a pattern from noise

Say you interview ten customers who converted in the last quarter, asking each one what was happening right before they started evaluating tools. Nine different answers would tell you the trigger is idiosyncratic, and any job statement you write is really just describing one customer, not a market. But if seven of the ten independently describe the same underlying trigger — for instance, a compliance or audit deadline that the old process couldn't meet in time — that's a 70% repeat rate on the same circumstance, which is a real signal worth building a job statement and positioning around.

Contrast that with a hypothetical where only two of ten mention a similar trigger, and the other eight each describe something different. Two out of ten is 20% — noise, not a pattern. Writing a job statement off that would mean generalizing from what's more likely a one-off circumstance than a repeatable buying trigger. The arithmetic is trivial, but doing it at all — actually counting how many interviews support a given job statement, rather than eyeballing "yeah, that sounds about right" after two or three conversations — is the difference between JTBD as evidence and JTBD as vibes with a template.

From validated job to positioning that holds up

Once a job statement is backed by a real repeat rate across interviews, it should change concrete things: the trigger event becomes the hook in top-of-funnel messaging instead of a generic feature list; the "what they tried before switching" data becomes your differentiation story against the actual alternatives buyers consider, which are often not your named competitors but the manual workaround or in-house process; and the ideal customer profile narrows to the circumstance, not just the firmographic, which tends to sharpen a beachhead market far more precisely than title and company size alone. If a positioning statement can't be traced back to an interview-sourced trigger, it's still a hypothesis, not a validated job — worth saying plainly in the doc rather than presenting it with more confidence than the evidence supports.