By Mehdi HassanWhat is Jobs to Be Done in product design?
Jobs to Be Done (JTBD) is a way of understanding customers by the progress they're trying to make in a specific situation, rather than by who they are. In product design, it means deciding what to build and how to present it based on those jobs. The core idea, popularized by Clayton Christensen, is that people 'hire' a product to get a job done and 'fire' it when something does the job better.
The classic illustration is Christensen's milkshake story: customers buying milkshakes on their morning commute weren't hiring them as a dessert, they were hiring them to make a long, boring drive more bearable and keep them full until lunch. The competition wasn't other milkshakes, it was bagels, bananas and boredom. The same thinking applies to software.
Most JTBD guides stop at theory. This one carries jobs all the way through to information architecture, interface copy and screens. It's part of our user research for startups playbook, which covers how to gather the evidence that JTBD needs.
How do you find the jobs your customers are hiring you for?
You find jobs by interviewing people about the moment they started looking for a solution, and everything that led up to it. JTBD interviews are often called switch interviews, because they reconstruct the story of switching from an old way of doing something to a new one. The trigger, the struggle and the hoped-for outcome all point to the job.
Talk to recent switchers
Interview people who recently started using your product or a competitor, or who recently gave up on one. Their memory of the decision is still fresh.
Find the first thought
Ask when they first realized the old way wasn't working. What happened that day?
Map the struggle
What did they try? What made them hesitate? What almost stopped them switching?
Capture the hoped-for outcome
Ask what they expected life to look like once the problem was solved. That's the progress they're hiring for.
Note the forces
Push of the current problem, pull of the new solution, anxiety about switching and habits that keep them stuck.
The questioning style matters as much as the topic. Our guide to running customer interviews covers how to ask about past behavior without leading.
How do you write job stories?
A job story describes a job in a single sentence: When [situation], I want to [motivation], so I can [expected outcome]. It replaces the classic user story format, 'As a [persona], I want…', with the situation that triggers the need. That shift keeps the focus on context, which is what drives design decisions.
Format | Example | What it tells the designer |
|---|---|---|
User story | As a finance manager, I want to export reports. | Who and what, but not when or why |
Job story | When month-end is two days away and numbers don't match, I want to see which transactions are unreconciled, so I can close on time without staying late. | The trigger, the urgency, the real goal |
Job statement | Close the books accurately and on time. | The stable, high-level job behind many stories |
Write the situation in concrete terms from your interviews, not generic ones. 'When I'm busy' is weak. 'When a client emails asking where their invoice is' is a design brief. Use customers' own words wherever you can, because those words will become your copy later.
How do jobs shape information architecture?
Jobs shape information architecture by deciding what the top-level areas of your product are and what they're called. Group related job stories together, and each group becomes a candidate for a navigation section. The result is a product organized around what users came to do, not around your database tables or your team structure.
- Cluster job stories. Put all your job stories on a board and group the ones that share a situation or outcome.
- Name each cluster as a goal. 'Get paid' is clearer than 'Invoices' when the job is getting money in.
- Rank clusters by frequency. The job people do daily belongs at the top of navigation. The job done once a year belongs in settings.
- Check against real terms. Test labels with card sorting or a quick first-click test, using the language from interviews.
Not every label should be a verb. Familiar nouns such as 'Invoices' or 'Projects' often test better because users recognize them. The point is that the grouping comes from jobs, so the right things sit together. Our dashboard design examples show how strong products put the most frequent job front and center.
How do you turn jobs into interface copy?
You turn jobs into copy by writing every headline, empty state and button around the outcome the user wants, using the words they used in interviews. Copy is where JTBD pays off fastest, because a change of wording costs little and tells users immediately that you understand why they're here.
Element | Feature-led copy | Job-led copy |
|---|---|---|
Dashboard headline | Overview | What needs your attention before month-end |
Empty state | No invoices yet | Send your first invoice and get paid faster |
Primary button | Create | Send invoice |
Onboarding step | Connect integration | Bring in your transactions so we can spot what doesn't match |
Upgrade prompt | Upgrade to Pro | Add your team so nobody waits on you to close the month |
The same principle applies to your marketing site. A value proposition built on the job reads as a promise of progress rather than a list of features. Our guide to writing a value proposition shows how to turn a job statement into a headline. For technical products where the job is hard to explain, our guide to website design for complex products covers how to make it clear.
How do jobs decide what goes on each screen?
Each screen should serve one primary job, and that job decides what appears first, what's secondary and what can be hidden. When a screen tries to serve every job, it ends up serving none. Start each screen design by writing the job story at the top of the Figma frame.
Write the job at the top
One job story per screen, visible in the design file, so every review starts by asking whether the screen does that job.
Put the job's answer above everything else
If the job is 'see what needs attention', the list of attention items comes before charts and summaries.
Make the next step obvious
The primary action should be the thing that completes the job.
Push other jobs aside
Secondary jobs get smaller entry points, not equal billing.
Define done
Decide what success looks like for this job, so you can measure it after launch.
For example, suppose a bookkeeping SaaS redesigns its home screen around one job
For example, suppose interviews with small-business owners using a bookkeeping tool keep returning to the same story: 'When my accountant asks for something, I want to find and send it quickly, so I don't look disorganized.'
In this hypothetical, the team writes that job at the top of the home screen design. The default dashboard of charts moves down. At the top goes a short list titled 'Requests from your accountant', each with a one-click way to attach and send the document. The empty state reads 'No requests right now. Your accountant can ask for documents here.' The navigation adds a clear 'Share with accountant' area.
To check whether it worked, the team tracks how often requests are completed and how long they take, alongside a few follow-up interviews.
How do you check that a JTBD-led design worked?
You check a JTBD-led design by measuring whether the job gets done more often, faster or with fewer errors, then confirming with a few follow-up conversations. Every job story already contains the success measure: the outcome after 'so I can'. Turn that outcome into a metric before you ship.
For the example above, the metric might be the share of accountant requests completed within a day. For an onboarding job, it might be how many new accounts reach their first meaningful result. Our guide to UX metrics for SaaS explains how to turn these outcomes into analytics events, and our guide to research synthesis helps you combine numbers with interview evidence.
JTBD isn't the only lens. Personas still help some teams keep a picture of their users in mind. Our comparison of personas vs Jobs to Be Done explains when each one helps and when each misleads. If you'd like a team to turn your job stories into visual directions, our brand & design sprint is $3,000, fixed scope, with 10 website and product explorations in Figma.
