By Mehdi HassanWhat is the difference between personas and Jobs to Be Done?
A persona is a profile of a representative user: their role, goals, frustrations and context, usually given a name and a photo. Jobs to Be Done (JTBD) describes the progress a person is trying to make in a particular situation, independent of who they are. Personas organize research around people. Jobs organize it around situations and outcomes.
Both aim to stop teams designing for themselves. They just pick different anchors. A persona says 'design for Priya, the finance lead'. A job says 'design for the moment month-end is two days away and the numbers don't match'. That second sentence tells a designer more about what the screen should do.
This comparison is part of our user research for startups playbook. For a full walkthrough of the JTBD side, see our guide to Jobs to Be Done for product design.
Personas | Jobs to Be Done | |
|---|---|---|
Core question | Who is the user? | What progress do they want, in what situation? |
Typical format | A one-page profile with a name, role and goals | Job stories: When…, I want to…, so I can… |
Built from | Interviews, surveys, analytics, sometimes assumptions | Switch interviews about real decisions |
Best at | Building empathy and shared context | Driving feature, IA and copy decisions |
Weakest at | Explaining why people switch or churn | Capturing skill level and constraints |
Shelf life | Goes stale as the market changes | Stable: core jobs change slowly |
When do personas mislead product teams?
Personas mislead when they're invented rather than researched, when they're full of details that don't affect design and when they become a substitute for talking to users. A persona built in a workshop from the team's assumptions just gives those assumptions a name and a stock photo, which makes them harder to question.
- Fiction dressed as research. If nobody can point to the interviews behind a persona, it's a guess with a face.
- Decorative demographics. Age, hobbies and favorite brands rarely change what a B2B screen should do.
- Too many personas. Seven personas means the team designs for none of them. Two or three is the useful limit.
- Frozen in time. Personas written at launch and never updated describe customers you used to have.
- Stereotypes. Personas built on demographics can quietly encode bias about who a user is.
A related trap is the proto-persona: a quick, assumption-based persona created before any research. Proto-personas can be useful as a list of hypotheses to test, as long as everyone treats them that way. They mislead when they're never replaced with evidence.
When do Jobs to Be Done mislead product teams?
Jobs to Be Done misleads when jobs are written so broadly that they describe every product in the category, when teams treat them as features in disguise and when they ignore who is actually doing the job. A job like 'manage my finances' is true and useless. It can't help you choose between two screens.
- Too abstract. 'Be more productive' is a job every tool claims. Narrow it to the situation and the outcome.
- Features as jobs. 'I want to export a CSV' is a solution. Ask why until you reach the real outcome.
- Ignoring the person. The same job looks very different for a first-time user and an expert. JTBD alone can miss that.
- Theory without evidence. Jobs written in a meeting are as unreliable as invented personas.
- Over-engineering. Some JTBD methods add layers of terminology that slow small teams down.
Personas vs Jobs to Be Done: which should guide product design?
Jobs to Be Done should guide most product design decisions, because it describes the situation and outcome that a screen, a feature or a piece of copy needs to serve. Personas are better as supporting context: reminders of skill level, role and constraints that shape how a job is done, not what the job is.
Pros
- Jobs translate directly into navigation, copy and screen priorities
- Jobs reveal real competitors, including spreadsheets and doing nothing
- Jobs stay stable over time, so they age better than personas
- Personas help teams remember who they're designing for in day-to-day work
- Personas capture constraints like skill level and time pressure
Cons
- Jobs can become too abstract to act on
- Jobs say little about experience level or accessibility needs
- Personas encourage demographic detail that rarely affects design
- Personas go stale and are rarely updated
- Both are useless if built without research
Different situations favor different tools. If you're deciding what to build next, jobs win. If you're onboarding a new designer or aligning a large team on who the customer is, a short persona helps. If you're designing for very different skill levels, such as admins and occasional users, you need the person layer as well as the job.
How do you combine personas and jobs in one template?
Combine them by starting with the job and adding a short profile of the people who do it. The job stays at the top and drives decisions. The profile underneath captures only the details that change design: role, experience level, frequency of use, constraints and the words they use. Leave out the stock photo and the hobbies.
Write the main job story
When [situation], I want to [motivation], so I can [outcome]. Use language from interviews.
List who does this job
Roles that perform it, such as the admin who sets it up and the team member who uses it daily.
Add design-relevant context
For each role: experience level, how often they do the job, devices they use and key constraints such as time pressure or approvals.
Record their words
Three to five real quotes that capture how they describe the situation and the outcome.
Note the evidence
How many interviews or tests support this, and when they happened, so the template can be updated.
For example, a hybrid job-and-profile card for a scheduling tool
For example, suppose a team is designing a scheduling tool for small clinics.
Job: When a patient cancels on the day, I want to fill the slot quickly, so I can keep the schedule full without spending the morning on the phone.
Who does it: the front-desk coordinator, daily, on a desktop, often while also answering calls. Occasionally the clinic owner, weekly, mostly to check how many slots went empty.
Constraints: interrupted constantly, needs to act in seconds, can't see patient medical details beyond what's necessary.
Their words: 'I'm juggling the phone and the screen', 'I just need to see who's on the waiting list'.
Evidence: hypothetical card, based on what a set of interviews might reveal. A real card would list the interview dates and count.
How do you build either one from real research?
Build personas or jobs from interviews with real customers or prospects, focusing on specific past situations. The interviews are the same for both. What changes is how you synthesize the notes: by person for personas, by situation and outcome for jobs.
- Recruit people with recent experience. Our guide to recruiting research participants covers how, even before launch.
- Ask about real events. 'Tell me about the last time…' produces both the person's context and the job. Our guide to running customer interviews has a script.
- Synthesize twice if needed. Group notes by situation to find jobs, then by role to find the context that changes design. Our guide to research synthesis explains the process.
- Date everything. Note when the research happened, so you know when to refresh it.
When research turns into recommendations for an existing product, present them clearly. Our UX audit report template shows how to frame findings so they get fixed. For AI features, where users' trust and experience level matter a lot, our guide to AI product UX covers the person-level context to capture. Once you know the job, our brand & design sprint, at $3,000 fixed, turns it into 10 website and product explorations.
