{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-10-13T16:47:39.097Z"},"content":[{"type":"documentation","id":"763d8b3f-7c0e-4ab3-ac0f-f9a45b1170cd","slug":"jobs-to-be-done-vs-personas","title":"Jobs to Be Done vs Personas: Which One Should Your Team Use?","url":"https://www.koji.so/docs/jobs-to-be-done-vs-personas","summary":"Jobs to Be Done and personas answer different questions. A persona groups people with similar goals and behaviour so a team can design for a specific user; a job groups situations and explains why people choose, switch or quit a product. Christensen and colleagues argued in HBR (2016) that profiling customers yields correlation, not causation, while Matthews, Judge and Whittaker (CHI 2012) found practitioners used personas mainly for communication and concluded that personas cannot replace immersion in user data. Most teams do best with job-based personas built from one round of interviews about real, recent decisions.","content":"# Jobs to Be Done vs Personas: Which One Should Your Team Use?\n\n**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.\n\nThe 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.\n\n## What each tool actually is\n\n**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.\n\n**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._\n\nThe 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.\n\n## The case for Jobs to Be Done\n\nChristensen'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.\n\nThe 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.\n\nThe 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.\n\nJTBD is strongest when you need to:\n\n- **Find real competitors.** People compare you with whatever else they could hire, including spreadsheets, agencies and doing nothing.\n- **Position and message a product.** Jobs give you the situation and the trigger, which is what good copy speaks to.\n- **Decide what to build next.** Struggling moments in a job point straight at opportunities.\n- **Understand switching and churn.** [Switch interviews](/docs/switch-interviews-jtbd-method) reconstruct the timeline of a decision, which is where the real causes live.\n\nAnthony 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.\n\n## The case for personas\n\nPersonas 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.\n\nPersonas are strongest when you need to:\n\n- **Align a team** on who the product is for, and just as usefully, who it is not for.\n- **Make design trade-offs** about skill level, frequency of use, device and context.\n- **Brief people who were not in the research,** such as new hires, agencies and leadership.\n- **Plan recruitment** so that each study reaches the right mix of people.\n\nThe 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.\"\n\nNielsen 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.\n\n## Where each one goes wrong\n\nBoth tools fail in predictable ways, and most arguments between the camps are really arguments about these failures.\n\n**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.\n\n**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](/docs/proto-persona-guide) is, but only if someone validates it.\n\n**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.\n\n**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._\n\n**Both go wrong when nobody updates them.** Markets move. A persona or job map from two years ago is a historical document.\n\n![Comparison of personas and Jobs to Be Done: personas describe who the user is, jobs describe the situation and the progress they want](/visuals/personas-vs-jobs-to-be-done-comparison/personas-vs-jobs-to-be-done-comparison.png \"Use this to agree which question your team is trying to answer before you pick the tool\")\n\n## How to choose: a quick decision guide\n\nAsk what decision the research has to inform, then pick the tool that answers it.\n\n| If your question is...                        | Lead with       | Why                                                  |\n| --------------------------------------------- | --------------- | ---------------------------------------------------- |\n| Why do people buy, switch or cancel?          | Jobs to Be Done | Causes live in situations and triggers, not traits   |\n| What should we build next?                    | Jobs to Be Done | Struggling moments in a job are opportunities        |\n| How should we position and message it?        | Jobs to Be Done | Copy speaks to the situation and the outcome         |\n| Who exactly are we designing this screen for? | Personas        | Design trade-offs need a concrete person and context |\n| How do we brief a new team or agency?         | Personas        | People remember people more easily than statements   |\n| Whom should we recruit for the next study?    | Both            | Jobs define the situation, personas define the mix   |\n\nIf 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.\n\n## Using them together\n\nThe 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.\n\nA practical structure:\n\n1. **Name and one-line situation.** \"The Rollout Owner: rolling a new tool out to forty people who did not ask for it.\"\n2. **Primary job,** written as when, want, so that.\n3. **Triggers.** What happened just before they started looking.\n4. **Struggling moments.** Where today's solution fails them, with quotes.\n5. **What they hire today.** Including workarounds and doing nothing.\n6. **Context that changes design.** Frequency, skill, device, who else is involved.\n\nThen 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](/docs/job-stories-vs-user-stories) carry the situation into the sprint.\n\n![Process for building job-based personas from interviews, from recruiting by situation to grouping people by shared jobs](/visuals/job-based-personas-process/job-based-personas-process.png \"One round of interviews can feed both your jobs and your personas\")\n\n## Running the interviews behind both\n\nYou 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.\n\n![A researcher listening as a customer describes the last time they had to solve a problem at work](https://images.unsplash.com/photo-1710362921917-2e33bb342a23?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w5NDUzMDN8MHwxfHNlYXJjaHwyfHx0d28lMjBwZW9wbGUlMjBpbnRlcnZpZXclMjBjb2ZmZWUlMjB0YWJsZXxlbnwxfDB8fHwxNzkxODcwNjEwfDA&ixlib=rb-4.1.0&q=80&w=1080)\n\n_Photo by [Phil Desforges](https://unsplash.com/@storybyphil?utm_source=koji&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=koji&utm_medium=referral)_\n\n- **Recruit by situation, not just by demographics.** Include people who recently bought, switched, stalled or cancelled, and people who solved the problem without you.\n- **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.\n- **Reconstruct the timeline.** First thought, passive looking, active looking, deciding, first use. The [Jobs to Be Done framework](/docs/jobs-to-be-done-framework) and switch interviews give you the prompts.\n- **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.\n- **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.\n\nAim for enough interviews to see the same jobs repeat across different kinds of people. For guidance on numbers, see [how many interviews is enough](/docs/how-many-interviews-enough).\n\n## How Koji helps\n\nKoji runs the interviews for you and does the first pass of analysis, so you can get to both jobs and personas from one study.\n\n- **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.\n- **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.\n- **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](/docs/structured-questions-guide).\n- **Screening questions** keep the sample to people who actually had the situation you are studying.\n- **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.\n\n![Koji personas table comparing three customer personas by need, goal, behaviour and quote](/email/shots/shot-personas.jpg \"Personas built from the interviews themselves, with the share of participants behind each one\")\n\nThe 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.\n\n## Related Resources\n\n- [Jobs to Be Done framework](/docs/jobs-to-be-done-framework)\n- [How to create research-backed user personas](/docs/user-persona-research-guide)\n- [Job stories vs user stories](/docs/job-stories-vs-user-stories)\n- [Switch interviews: the JTBD interview method](/docs/switch-interviews-jtbd-method)\n- [AI-generated customer personas](/docs/ai-generated-customer-personas)\n- [Structured questions guide](/docs/structured-questions-guide)\n\n## Sources\n\n- Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan, \"Know Your Customers' 'Jobs to Be Done'\", _Harvard Business Review_, September 2016.\n- Carmen Nobel, \"Clay Christensen's Milkshake Marketing\", _HBS Working Knowledge_, February 2011.\n- Alan Cooper, _The Inmates Are Running the Asylum_, Sams, 1999.\n- Tara Matthews, Tejinder Judge and Steve Whittaker, \"How do designers and user experience professionals actually perceive and use personas?\", _Proceedings of CHI 2012_, ACM.\n- Kim Flaherty, \"Just-Right Personas: How to Choose the Scope of Your Personas\", Nielsen Norman Group, 2020.\n- Strategyn, \"Outcome-Driven Innovation\", strategyn.com (self-reported success rate).\n","category":"frameworks","lastModified":"2026-10-13T05:50:10.914992+00:00","metaTitle":"Jobs to Be Done vs Personas: When to Use Each | Koji","metaDescription":"JTBD explains why people choose, switch or quit; personas show who you design for. Learn when to use each and how to build job-based personas.","keywords":["jobs to be done vs personas","jtbd vs personas","personas vs jobs to be done","job-based personas","jobs to be done","user personas","persona research"],"aiSummary":"Jobs to Be Done and personas answer different questions. A persona groups people with similar goals and behaviour so a team can design for a specific user; a job groups situations and explains why people choose, switch or quit a product. Christensen and colleagues argued in HBR (2016) that profiling customers yields correlation, not causation, while Matthews, Judge and Whittaker (CHI 2012) found practitioners used personas mainly for communication and concluded that personas cannot replace immersion in user data. Most teams do best with job-based personas built from one round of interviews about real, recent decisions.","aiPrerequisites":["Basic familiarity with customer interviews","Some exposure to personas or Jobs to Be Done"],"aiLearningOutcomes":["Explain the difference between a persona and a job to be done","Choose the right tool for a given product or design decision","Spot the common ways each tool goes wrong","Build job-based personas from one round of interviews","Run interviews that capture both jobs and persona context"],"aiDifficulty":"intermediate","aiEstimatedTime":"11 min read"}],"pagination":{"total":1,"returned":1,"offset":0}}