Jobs to Be Done vs Personas: Which One Should Your Team Use?

The short answer: use Jobs to Be Done when you need to know why people choose, switch or quit a product, and use personas when you need a team to share one clear picture of who it is building for. They answer different questions, so most mature teams use both: jobs to decide what to build and how to position it, personas to keep design and communication grounded in real people. The mistake is to treat them as rivals, or to build personas out of demographics and call it research.

The debate gets heated because each side has a fair criticism of the other. JTBD people say personas describe customers without explaining their choices. Persona people say jobs are abstract and hard to design for. Both are right about the weak versions. This guide explains what each tool is for, where each one fails, and how to run one round of interviews that feeds both.

What each tool actually is

A persona is a fictional but research-based character who stands for a group of users with similar goals and behaviour. Alan Cooper popularised the idea in The Inmates Are Running the Asylum (1999), arguing that designing for one specific, well-understood person produces a better product than designing for an elastic "user" who bends to fit every argument. A good persona has a name, a context, goals, frustrations, the tools they use today and a few real quotes.

A job to be done is the progress a person is trying to make in a particular circumstance. Clayton Christensen, Taddy Hall, Karen Dillon and David Duncan set out the idea in "Know Your Customers' 'Jobs to Be Done'" (Harvard Business Review, September 2016). In their words, "When we buy a product, we essentially 'hire' it to help us do a job." If it does the job well, we hire it again; if it does a poor job, we fire it and look for something else. A job is usually written as a situation, a motivation and an outcome: When I'm about to present the roadmap to leadership, I want evidence for each bet, so I can defend the plan without guessing.

The unit of analysis is the key difference. A persona groups people. A job groups situations. The same person can have five jobs in a week, and two very different people can be hiring the same product for the same job.

The case for Jobs to Be Done

Christensen's argument was aimed at a specific habit: segmenting customers by attributes and then reading patterns in the data. The HBR article warns that most managers have grown comfortable basing decisions on correlations, and that correlation is not causality. Knowing that your buyer is a 35-year-old product manager at a 200-person company does not tell you why they bought, or what would make them switch.

The stakes are high. Christensen pointed out in HBS Working Knowledge that each year 30,000 new consumer products are launched, and many of them fail. Most of those teams knew a lot about their customers. What they did not know was why those customers would choose the new product.

The best-known illustration is the milkshake study. A fast-food chain had tried to improve milkshakes by segmenting its market and asking customers who matched the milkshake-buyer profile what their ideal shake would be, with no effect on sales. Researchers then watched who bought milkshakes and when. As Carmen Nobel reported in HBS Working Knowledge (2011), 40 percent of the milkshakes were bought first thing in the morning, by commuters who were alone, bought nothing else and ordered them to go. They were hiring the milkshake for a long, boring commute: something that lasted, filled them up until lunch and could be held in one hand. The competition was not other milkshakes but bagels, bananas and boredom. No demographic profile would have surfaced that.

JTBD is strongest when you need to:

• Find real competitors. People compare you with whatever else they could hire, including spreadsheets, agencies and doing nothing.
• Position and message a product. Jobs give you the situation and the trigger, which is what good copy speaks to.
• Decide what to build next. Struggling moments in a job point straight at opportunities.
• Understand switching and churn. Switch interviews reconstruct the timeline of a decision, which is where the real causes live.

Anthony Ulwick's Outcome-Driven Innovation, a quantitative branch of JTBD, makes the strongest claim for the approach. Strategyn, Ulwick's firm, reports an 86% success rate for products developed with ODI against an industry baseline it puts at 17%. Treat that as a vendor's self-reported figure rather than an independent benchmark, but it shows how far the JTBD community thinks the gap can go.

The case for personas

Personas earn their place in a different part of the work. A job statement is precise, but it is hard to empathise with a sentence. Designers, engineers and stakeholders find it easier to keep a person in mind: someone who has three tools open, a manager asking for numbers and twenty minutes before the next meeting.

Personas are strongest when you need to:

• Align a team on who the product is for, and just as usefully, who it is not for.
• Make design trade-offs about skill level, frequency of use, device and context.
• Brief people who were not in the research, such as new hires, agencies and leadership.
• Plan recruitment so that each study reaches the right mix of people.

The research on how personas are used in practice is sobering, though. Tara Matthews, Tejinder Judge and Steve Whittaker interviewed experienced user-centred design practitioners for their CHI 2012 paper "How do designers and user experience professionals actually perceive and use personas?". They found practitioners used personas almost exclusively for communication rather than for design, and described them as abstract, impersonal, misleading and distracting. Their conclusion is worth pinning above any persona workshop: "Personas cannot replace immersion in actual user data."

Nielsen Norman Group makes a related point in Kim Flaherty's "Just-Right Personas" (2020): the scope of a persona set should follow from what the personas are for. A persona built for marketing segmentation looks different from one built to settle design arguments in one feature area.

Where each one goes wrong

Both tools fail in predictable ways, and most arguments between the camps are really arguments about these failures.

Personas go wrong when they are built from demographics. Age, job title, a stock photo and a hobby make a persona memorable but not useful, and they invite the correlation-based thinking Christensen criticised. Matthews and colleagues found that this kind of detail is exactly what practitioners find misleading and distracting.

Personas go wrong when they are invented. A persona workshop with no interviews behind it produces a document of the team's assumptions. That is fine as a starting point, which is what a proto-persona is, but only if someone validates it.

Jobs go wrong when they are too abstract. "Help me be more productive" is true of almost every product and tells you nothing. A useful job is tied to a situation and has a measurable outcome.

Jobs go wrong when they are product-shaped. "Use Koji to analyse interviews" is not a job; it is a feature. The job sits above the product: understand why trial users stall before the renewal conversation.

Both go wrong when nobody updates them. Markets move. A persona or job map from two years ago is a historical document.

How to choose: a quick decision guide

Ask what decision the research has to inform, then pick the tool that answers it.

If you can only do one this quarter, start with jobs. A set of well-researched jobs makes better personas later, because you can group people by the jobs they hire you for instead of by their job titles. Going the other way, from demographic personas to jobs, usually means starting the research again.

Using them together

The most useful pattern is job-based personas: personas whose core is a primary job, its triggers and its struggling moments, with the human detail added only where it changes a design decision. NN/g's own persona guidance already asks for goals and behaviours rather than demographics; job-based personas push that one step further.

A practical structure:

1. Name and one-line situation. "The Rollout Owner: rolling a new tool out to forty people who did not ask for it."
2. Primary job, written as when, want, so that.
3. Triggers. What happened just before they started looking.
4. Struggling moments. Where today's solution fails them, with quotes.
5. What they hire today. Including workarounds and doing nothing.
6. Context that changes design. Frequency, skill, device, who else is involved.

Then use them for different jobs inside the team. Product strategy and positioning work from the job statements. Design reviews work from the personas. Both point back to the same interviews, so nobody has to choose which version of the customer to believe. If your team writes backlog items, job stories carry the situation into the sprint.

Running the interviews behind both

You do not need two studies. One round of interviews built around a recent, real decision gives you the raw material for jobs and personas at once.

Photo by Phil Desforges on Unsplash

• Recruit by situation, not just by demographics. Include people who recently bought, switched, stalled or cancelled, and people who solved the problem without you.
• Ask about the last time. "Tell me about the last time you had to..." keeps answers in real events. Opinions about the future are weak evidence.
• Reconstruct the timeline. First thought, passive looking, active looking, deciding, first use. The Jobs to Be Done framework and switch interviews give you the prompts.
• Capture context as you go. Role, team size, tools and frequency come up naturally when people tell a story. Note them for the persona layer.
• Analyse twice. First cluster the situations and outcomes into jobs. Then cluster the people by which jobs they hire you for and how they behave. Those clusters are your personas.

Aim for enough interviews to see the same jobs repeat across different kinds of people. For guidance on numbers, see how many interviews is enough.

How Koji helps

Koji runs the interviews for you and does the first pass of analysis, so you can get to both jobs and personas from one study.

• Start from a JTBD template. The template library includes a Jobs to Be Done interview, with open questions about the situation before someone started using a product and AI follow-ups that probe for the details a job statement needs.
• AI-moderated interviews, by voice or text. Every participant gets the same guide and the same depth of probing, in their own time. The interviewer follows up on vague answers instead of moving on.
• Structured questions alongside the story. Add single choice, multiple choice or scale questions to capture role, team size or how often the job comes up, so the persona context arrives as clean data. See the structured questions guide.
• Screening questions keep the sample to people who actually had the situation you are studying.
• Automatic themes and behaviour-based personas. The report groups themes across interviews and builds personas by clustering participants on shared needs, goals and behaviours, each with its share of participants and real quotes. Every finding links back to the responses behind it.

The difference from a persona workshop is the evidence trail: each persona and theme points back to what participants actually said, which is the immersion in user data that Matthews and colleagues found personas so often lack. You still write the final job statements and decide which personas matter. Koji gets you there faster and keeps the quotes attached.

Related Resources

• Jobs to Be Done framework
• How to create research-backed user personas
• Job stories vs user stories
• Switch interviews: the JTBD interview method
• AI-generated customer personas
• Structured questions guide

Sources

• Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan, "Know Your Customers' 'Jobs to Be Done'", Harvard Business Review, September 2016.
• Carmen Nobel, "Clay Christensen's Milkshake Marketing", HBS Working Knowledge, February 2011.
• Alan Cooper, The Inmates Are Running the Asylum, Sams, 1999.
• Tara Matthews, Tejinder Judge and Steve Whittaker, "How do designers and user experience professionals actually perceive and use personas?", Proceedings of CHI 2012, ACM.
• Kim Flaherty, "Just-Right Personas: How to Choose the Scope of Your Personas", Nielsen Norman Group, 2020.
• Strategyn, "Outcome-Driven Innovation", strategyn.com (self-reported success rate).