JTBD vs. Personas: Why You Need Both

The False Debate

Two frameworks. One argument. Zero winners.

The product management world has been arguing for years: "Should we use JTBD or personas?" It is the wrong question.

JTBD answers: "What are we building?"

Personas answer: "Who are we building it for and how do we reach them?"

You would not build a product without knowing what it does (JTBD). And you would not launch a product without knowing who it is for (personas). The question is not which framework to use. It is how to use both.

The confusion comes from treating JTBD and personas as competing approaches to the same problem. They are not. They solve different problems. JTBD solves the "what should we build?" problem. Personas solve the "how do we reach the people who need it?" problem. When you use only one, you get half the picture -- and half a picture is how teams ship the wrong thing to the right audience or the right thing to nobody.

What Each Framework Does

Two frameworks. Two different problems. Let us see what each one produces.

Before combining them, it helps to see clearly what each framework produces on its own.

JTBD: The "What" Framework

JTBD describes the progress a customer is trying to make. Here is an example:

"When my board meeting is in 3 days, I want to compile our key metrics into a defensible narrative so I can answer any question the board asks."

What JTBD tells you:

• What features advance this job -- build them
• What features do not advance this job -- do not build them
• What job your product actually serves -- your core positioning
• What job your competitors serve -- your competitive map

What JTBD does not tell you:

• Who to target first (VP of Analytics or Founder?)
• What channel to reach them on (LinkedIn or conference?)
• What language resonates ("revenue intelligence" or "board-ready metrics"?)

These gaps are exactly where personas fill in.

The insight: JTBD alone tells you what to build but leaves every go-to-market decision unanswered.

Personas: The "Who" Framework

Personas describe the people who share the same job but have different contexts. Here is the key insight: the job can be identical across personas while the context, anxiety, and language are completely different.

Notice: the job is the same. The context, anxiety, and language are different. This is why you need both frameworks.

What personas tell you:

• Who to target first (the segment with the most acute job and the budget to pay)
• What channel to reach them on (where they already spend time)
• What language to use (the words they use, not the words you use)
• What anxieties to address in your messaging

What personas do not tell you:

• What features to build (that is JTBD)
• What to prioritize on your roadmap (that is JTBD + Kano)
• Whether a feature request is worth building (that is JTBD -- does it advance the job?)

The insight: Personas alone produce pretty positioning for a product nobody needs.

The Four Quadrants

Four combinations. Only one wins.

Here is what happens when you use each framework alone, both, or neither. The pattern explains why most SaaS companies are building the right thing for an audience they cannot reach.

Most SaaS companies are in the bottom-left quadrant: right product, invisible to the right audience. They have JTBD (they know what their retained customers are trying to accomplish) but no persona strategy (they do not know how to reach the next segment that shares the same job).

When to Use JTBD Alone

There are situations where JTBD is sufficient and personas are overhead.

• Early-stage product (under $2M ARR): You have 1 segment. The job is the only thing that matters.
• Technical infrastructure product: Your buyer and user are the same person (developer, data engineer). Personas add little beyond "senior engineer vs. junior engineer."
• Commoditized product: If your product serves a universal job with no meaningful segment variation, personas are marketing decoration, not strategic tools.

The insight: JTBD alone is sufficient when you have one segment and one buyer type. Everything else needs personas.

When Personas Matter Most

There are 3 situations where personas become critical to growth.

• Multi-segment product: Your product serves the same job for VPs, founders, and individual contributors -- but each segment has different buying criteria and budgets.
• Enterprise sales: The buyer (CFO), the user (analyst), and the champion (VP) are different people with different jobs and different personas. You need all 3.
• International expansion: The job is the same across markets, but the personas (roles, language, channels, compliance concerns) are completely different.

The insight: Every additional segment with a different buying criteria multiplies the cost of getting personas wrong.

How to Combine JTBD and Personas

Four steps. No shortcuts.

The combined framework works in 4 steps. Each step builds on the previous one, and the output is a product and go-to-market strategy that connects what you build to who you build it for.

Step 1: Find the Core Job (JTBD)

Run 10-15 switch interviews with retained customers. Extract the job statement that they all share. This is your core job. If you need the exact interview questions for each phase, see the JTBD interview script.

The insight: The core job is the one thing every retained customer was trying to accomplish. If you cannot find it in 15 interviews, you are looking too broadly.

Step 2: Segment by Context (Personas)

Within your retained customers, identify the segments that share the core job but have different roles and responsibilities, company sizes and stages, decision criteria and anxieties, and channels and language. Each segment becomes a persona.

The insight: Two customers with the same job but different buying criteria are two different personas. Same job, different path to purchase.

Step 3: Map Features to Jobs, Messaging to Personas

For each persona, answer 3 questions. What features does this persona need? The features that advance the core job for their specific context. How do we position these features? The language, channel, and anxiety that this persona responds to. What is the pricing this persona can afford? The price that matches their budget authority and perceived value.

The insight: The same feature can be positioned completely differently for each persona. The feature serves the job. The messaging serves the persona.

Step 4: Validate with Data

Once you have the mapping, validate it against real behavior.

• Are customers in Persona A using the features you built for their job? JTBD validated.
• Is Persona A converting at a higher rate from your messaging? Persona validated.
• Is Persona B churning faster than Persona A? Either the job is not served well for Persona B, or you are acquiring the wrong segment.

The insight: Data does not lie. If your persona mapping predicts behavior and the behavior does not match, your personas are wrong, not the data.

The most common mistake is using personas to decide what to build. "Our enterprise persona wants advanced reporting" sounds like a product decision, but it is really a positioning assumption. The JTBD question is: "Does advanced reporting advance the core job?" If the core job is "compile a defensible narrative for the board," then yes. If the core job is something else, then no -- and you just built a feature for a persona, not for the job.

For teams that want to connect this combined framework to feature prioritization, the JTBD + Kano Workshop adds ODI scoring and Kano classification on top of the JTBD-plus-personas foundation.