skip to content

In product design, how does jobs-to-be-done framing differ from a persona, and when is it the more useful lens?

level: middleimportance: should knowfreq 38%

answer

  1. who versus situation
  2. people hire products for progress
  3. when…, I want to…, so I can…
  4. competitors include workarounds
  5. personas can carry jobs

basics

~20 s

A persona centres on who the user is; jobs-to-be-done centres on the progress someone seeks in a situation, largely independent of who they are. It is more useful when different people share a need or when framing solution-agnostic opportunities.

solid answer

~50 s

Jobs-to-be-done treats people as “hiring” a product to make progress in a specific circumstance. The unit is the **job** — situation, motivation, desired outcome — not the person, and it is **solution-agnostic**: “when a parcel arrives while I'm out, get it inside safely”, not “a remote-unlock button”. That changes what counts as competition: a neighbour with a key, a parcel locker or doing nothing all compete for the job. A persona, by contrast, describes who someone is — goals, behaviours, context — and is strongest when differences between people change the design. Jobs framing is the better lens when very different people share a need, when exploring opportunities before committing to a solution, or when demographic personas are steering the team into stereotypes. The two combine well: a persona can list the jobs it hires the product for.

go deeper

for a junior

Recall that a persona describes who, while a job describes a situation and the progress sought, and be ready to write one job story.

for a middle

Explain why jobs are solution-agnostic and stable, how that widens competition to workarounds, and when differences between people still call for a persona.

for a senior

Show how you would reframe a feature-led roadmap debate around jobs, and combine them with personas where user constraints change the design.

for a principal

Weigh which framing an organisation standardises on for discovery, knowing each blinds teams differently: jobs to who struggles, personas to shared needs.

## Two different units of analysis A **persona** answers “who are we designing for?” — an archetype with goals, behaviours and context. **Jobs-to-be-done** (JTBD), popularised through Clayton Christensen's work on innovation, answers a different question: “what progress is someone trying to make, in what situation, and what would they hire to make it?” The unit of analysis moves from the **person** to the **job**. The same person has many jobs; very different people can share one. ## What a job is A job has a few defining properties: - **Situational** — it arises in a circumstance: away from home, a heating bill higher than expected, a guest about to arrive. - **Progress-seeking** — the person wants to move from a current state to a better one. - **Solution-agnostic** — it describes the need, not a feature. “Get a delivery inside while I'm out” is a job; “a remote-unlock button” is one possible solution. - **Stable** — the job persists while solutions change; people wanted to know who was at the door long before connected cameras existed. - **Multi-dimensional** — alongside the **functional** job there are **emotional** (feel in control, not anxious) and **social** (look responsible to housemates) dimensions. Because the job is solution-agnostic, **competition** widens. For the parcel job, a smart-home app competes with a neighbour holding a key, a parcel locker, a note on the door and simply rescheduling the delivery. Those workarounds are evidence that the job is real, and a benchmark the product must beat. ## Writing a job statement A widely used format is the **job story**: “When [situation], I want to [motivation], so I can [expected outcome].” For a smart-home control app: - “When the heating bill arrives higher than I expected, I want to see what drove it, so I can change the schedule without guessing.” - “When I'm away and someone rings the bell, I want to know who it is, so I can decide whether it matters.” The situation clause does the work a persona's demographics often fail to do: it names the **trigger and context** that shape the design. A job story is a framing tool for discovery; turning it into delivery work items is a separate practice with its own conventions. ## Persona versus job | | Persona | Jobs-to-be-done | |---|---|---| | Unit | A type of person | A situation and the progress sought | | Core question | Who are we designing for? | What are they trying to get done, and why now? | | Stability | Drifts as users and the market change | The job persists while solutions change | | Competition in view | Similar products for similar people | Anything hired for the job, workarounds included | | Typical risk | Demographic stereotypes, decoration | Losing sight of who struggles and their constraints | | Best output | Shared picture of users to design against | Opportunity framing and solution-agnostic criteria | ## When each lens is more useful Jobs framing tends to be the better lens when: 1. very different people share a need — the owner, a tenant and a visiting relative all need to know the door is locked; 2. the team is exploring **what to build** and should not anchor on a feature yet; 3. demographic personas are steering decisions into stereotypes; 4. the team needs to understand what it really competes with. A persona tends to be the better lens when: - differences **between people** change the design — technical confidence, whether they installed the system, whether they can modify the home; - a team needs a vivid, shared reference to argue decisions against; - skills, access needs or context constraints differ sharply across users. ## Using them together The two are not rivals. A common pattern is to identify jobs first, then describe personas by **which jobs they hire the product for and what constrains them**: the household configurer and the household member may share the “know the house is secure” job but face very different obstacles in getting it done. Both still need grounding in evidence. A job invented in a meeting is as fictional as a decorative persona; jobs are confirmed by finding people who recently struggled in that situation and seeing how they coped.

  • Why does jobs-to-be-done widen who counts as a competitor?
    Because the job is defined by the progress sought, anything a person hires to make that progress competes — including workarounds that are not products at all. For getting a parcel inside, a neighbour with a key or a parcel locker competes with a smart lock. Those workarounds show the job is real and set the bar the product must beat.
  • What goes wrong when a job statement names a feature?
    It stops being a job and becomes a solution in disguise, so the team only evaluates the feature it already imagined. “I want a geofence toggle” hides the real job — “when I leave home, make sure nothing is left on” — which other solutions might serve better.
  • Does jobs-to-be-done remove the need for research?
    No. Jobs are hypotheses until evidence shows people actually struggle in that situation and how they cope today. Looking at recent real events and observed workarounds is how teams confirm a job; one invented in a meeting is as fictional as a decorative persona.

saying these in an interview costs you the question

  • A job is a feature the user asks for, like a geofencing toggle.
  • Jobs-to-be-done and personas are rival methods, so a team must pick one.
  • Jobs-to-be-done lets a team skip user research entirely.
  • A product's competitors are only other apps in the same category.
  • Everyone in one demographic segment has the same jobs.