Jobs to Be Done vs Personas: Which Framework Should You Use?

Personas and Jobs to Be Done are both frameworks for understanding users. They answer fundamentally different questions, which is why teams that use only one of them tend to make predictable mistakes.

Personas answer: who is your user?

JTBD answers: why did your user hire your product?

Both questions matter. Neither is sufficient alone.

What Personas Get Right (and Wrong)

A persona is a composite representation of a user segment: demographics, role, goals, frustrations, tools used, day in the life. They're useful for:

• Aligning the team on who they're building for
• Communication shorthand ("this is a feature for Priya, not for Arjun")
• Onboarding designers and new team members quickly

Where personas fall short: they describe attributes, not behaviors. "Priya is a 32-year-old PM at a Series B SaaS company who values speed and dislikes meetings" tells you almost nothing about why she'd use your product, what would make her switch, or what her actual workflow looks like.

The deeper problem: personas are often built from demographic data and user research that asks what people say they want — not what they actually do. The gap between stated preference and revealed behavior is where most product assumptions go wrong.

What Jobs to Be Done Gets Right

JTBD, developed by Clayton Christensen and popularized by Bob Moesta, starts from a different premise: people don't buy products — they hire them to do a job.

The "job" is the progress the user is trying to make in a specific situation. Christensen's classic example: people don't buy a milkshake because they like milkshakes — they hire it to do the job of getting through a boring morning commute with one hand free.

This reframe changes what you look for in research. Instead of asking "what features do users want?", JTBD research asks:

• What were you doing just before you searched for this product?
• What's the situation that triggered the search?
• What were you using before, and why wasn't it good enough?
• What made you finally decide to switch?

The "switch interview" — understanding what caused a user to change from an old solution to your product — is the core JTBD research method. It surfaces the functional, social, and emotional dimensions of the job, not just the task-level need.

The Four Forces of Progress

JTBD maps switching decisions along four forces:

Pulling toward the new: What made the new product attractive? ("PMRead extracts insights automatically — I don't have to re-read 20 transcripts manually.")

Pushing away from the old: What made the old solution inadequate? ("My spreadsheet of quotes became unmanageable at 100 interviews.")

Anxiety about switching: What hesitation did you have? ("I wasn't sure if the AI would miss nuance.")

Habit and inertia: What kept you from switching sooner? ("My whole team was used to the Notion workflow.")

Understanding all four forces tells you not just why users switch to you, but what objections you need to overcome in positioning and onboarding.

When to Use Personas vs. JTBD

The pattern: personas are most useful for communication and design. JTBD is most useful for discovery, positioning, and prioritization.

Using Both Together

The most effective product teams use them in sequence:

1. 1JTBD first — Run switch interviews with recent customers and churned users. Understand the functional job, the situation that triggered the search, and the four forces for each segment.

1. 1Personas second — Use the JTBD research to build personas grounded in actual behavior, not just demographics. The persona should include the job, not just the attributes.

A persona without a JTBD: "Priya is a 32-year-old PM who values speed."

A persona with a JTBD: "Priya is a PM who hires PMRead to do the job of synthesizing 20 customer interviews before a quarterly planning meeting — she needs the job done in 30 minutes, not 3 hours."

The second version tells you what to build, how to position it, and what the baseline experience bar is.

JTBD in Practice: The Switch Interview

The switch interview is a 45-minute conversation that reconstructs the customer's switching decision. Key questions:

• "Walk me through the day you first thought you needed something new."
• "What had changed that made the old solution not work anymore?"
• "When did you first start looking? What did you search for?"
• "What made you finally decide to try [product]?"
• "What almost stopped you from switching?"

Don't ask what features they want. Ask what happened. Let them tell the story. The moment of dissatisfaction with the old solution is usually more revealing than the moment of attraction to the new one.

Use our User Interview Script as a starting point for switch interviews — it includes the key sequence questions and probes for the four forces.

The Bottom Line

Personas tell you who is in the room. JTBD tells you why they showed up and what they're trying to accomplish.

Both are incomplete without the other. Build your personas from JTBD research, and your product decisions will be grounded in actual user behavior rather than demographic inference.