Jobs to Be Done Framework: How to Apply It in 5 Weeks, Step by Step
7 min read ยท 2026-10-11
The jobs to be done framework says that people do not buy products. They "hire" them to make progress in a specific situation. To apply it, interview people who recently switched to or away from a solution. Write down the job they were trying to get done, map the steps of that job and find the steps where they still struggle.
A small team can do this properly in 5 weeks. The plan below takes you from a vague target customer to a list of job statements, a job map and a set of roadmap items linked to real customer struggles. Each phase ends with a milestone you can check, so you know when to move on.
The roadmap at a glance
Goal: Turn real customer struggles into clear job statements and a prioritized set of roadmap items. Duration: 5 weeks
Scope the Job (Week 1)
Decide which customers and which situation you will study, so your interviews stay focused.
- Write one sentence that describes the customer group you will study, such as "freelance designers who send their own invoices".
- List the products, tools and workarounds these people use today, including spreadsheets, email and doing nothing.
- Write 3 to 5 guesses about the job they are trying to get done, so you can test them later.
- Draft a short interview guide built around a recent event, not opinions.
Milestone: One page with the target group, the current alternatives, your guesses and the interview guide, reviewed by the team.
Recruit and Interview Switchers (Weeks 2-3)
Talk to people who changed how they do the job recently, because they still remember why.
- Recruit 8 to 12 people who started using, stopped using or switched a solution in the last few months.
- Run 45-minute interviews about the last time they made the switch, from first thought to final decision.
- Record each interview with permission and take notes in the same template every time.
- Write a one-paragraph summary within 24 hours of each call, while details are fresh.
Milestone: At least 8 interviews completed, each with a written summary and a timeline of the switch.
Write Job Statements (Week 4)
Turn interview notes into short, solution-free statements of what people are trying to do.
- Highlight every moment where someone describes a goal, a struggle or a trigger.
- Group similar quotes and write one job statement per group, using verb, object and context.
- Remove any statement that names a feature or a product.
- Pick one main job and up to 3 related jobs to focus on.
Milestone: A shared document with one main job statement, its related jobs and the quotes that support each one.
Map the Job and Find Unmet Outcomes (Week 5, Days 1-3)
Break the main job into steps and spot where people still struggle.
- Lay out the steps of the main job in order, from getting started to finishing.
- Under each step, write the outcomes people want, such as "less time to find the right file".
- Mark each outcome as well served, poorly served or not served, based on the interviews.
- Circle the 3 to 5 outcomes that are both important and poorly served.
Milestone: A complete job map with the top unmet outcomes clearly marked.
Turn Jobs Into Roadmap Items (Week 5, Days 4-5)
Translate unmet outcomes into work your team can plan and explain.
- Write one roadmap item per top unmet outcome, phrased as the problem it solves.
- Link each item to its job step and to at least 2 interview quotes.
- Rank the items with the prioritization method your team already uses.
- Present the job map and the ranked items to stakeholders in one short session.
Milestone: A ranked list of roadmap items, each traced back to a job step and real customer evidence.
What the Jobs to Be Done Framework Is
Jobs to be done is a way of looking at demand. Instead of asking "who is our customer?", you ask "what progress is this person trying to make, and in what situation?". Clayton Christensen made the idea popular. Tony Ulwick built a more structured version called Outcome-Driven Innovation, which adds job maps and desired outcomes.
The key shift is that the job stays stable while solutions change. People have wanted to "keep track of what I owe and what I'm owed" for a long time. The tools they hire for it changed from paper ledgers to spreadsheets to apps. Once you understand the job, you can see competition you would otherwise miss, including a notebook or a habit.
Every job has three layers:
- Functional: the practical task, such as "send an invoice a client will pay on time".
- Emotional: how the person wants to feel, such as "not anxious about chasing money".
- Social: how they want to be seen, such as "look professional to a new client".
How to Write a Good Job Statement
A job statement is a short sentence that describes progress, not a product. A useful format is verb plus object plus context. For example: "Plan the next quarter's work before the leadership review" or "Get paid by new clients without awkward follow-ups".
Good statements share a few traits. They start with a verb. They contain no feature, brand or technology. They would have made sense ten years ago and will still make sense in ten years. If your statement says "use an app to" or "with AI", rewrite it.
Compare these pairs:
- Weak: "Use a dashboard to see sales". Better: "Know which deals will close this month".
- Weak: "Get push notifications for deadlines". Better: "Avoid missing a client deadline".
- Weak: "Export a report to PDF". Better: "Show my manager progress without a meeting".
How to Run a Switch Interview
The best source of job insights is a person who recently changed solutions. They made a real decision with real trade-offs, so their story is concrete. Opinions about the future ("would you use this?") are much less reliable than memories of the past.
Walk the person through their switch as a timeline. Ask them to tell it like a story, and keep pulling them back to specific moments. These questions work well:
Listen for four forces: the push of the current situation, the pull of the new solution, the anxiety about the change and the habit of the old way. A switch only happens when push and pull are stronger than anxiety and habit. That tells you what to build, and also what to remove.
- When did you first think your old way was not working anymore? What happened that day?
- What did you try or look at before choosing?
- What almost stopped you from switching?
- What was the moment you decided?
- What did you expect the first week to be like, and what actually happened?
How to Build a Job Map
A job map lists the steps a person goes through to get the job done, whatever tool they use. Ulwick's generic version has eight steps: define, locate, prepare, confirm, execute, monitor, modify and conclude. You do not have to use all eight words, but they help you avoid skipping a stage.
Here is a short example for the job "plan the next quarter's work before the leadership review":
Under each step, write desired outcomes in the form "minimize the time to..." or "reduce the risk of...". Struggles cluster in a few steps. Your roadmap should focus on those clusters.
- Define: decide what the quarter must achieve.
- Locate: gather requests, data and commitments from last quarter.
- Prepare: sort and estimate the candidate work.
- Confirm: check capacity and dependencies with the team.
- Execute: build the plan and share it.
- Monitor: track progress during the quarter.
- Modify: adjust when priorities change.
- Conclude: review what was delivered and what was learned.
How to Turn Jobs Into a Roadmap
A jobs-based roadmap groups work by the progress it creates, not by features. Each roadmap item answers one question: which step of the job does this make easier, and how will we know? This makes priorities easier to explain. It also makes it easier to say no to requests that do not serve the main job.
A simple structure is one phase per job step you want to improve, with the unmet outcome as the goal of the phase. Inside each phase, list the experiments or features you will try, and set a milestone tied to the outcome. For example, "reduce the time to gather last quarter's commitments" could become a phase with a discovery step, a first version and a check with 5 users.
Common mistakes to avoid
- Writing job statements that name a feature. Rewrite each one until it would still be true with a completely different product.
- Asking customers what they want. Ask them to describe the last time they actually tried to get the job done.
- Interviewing only happy users. Include people who switched away or chose a different solution.
- Defining the job too broadly, like "be productive". Narrow it to one situation and one result you can observe.
- Stopping at insights. Finish with roadmap items linked to job steps and quotes.
- Treating the job map as final. Review it each quarter with new interviews.
Frequently asked questions
What is the jobs to be done framework in simple terms?
It is a way to understand why people choose a product. You look at the progress they want to make in a specific situation, called the job. People "hire" products for that job and "fire" them when something does it better.
How many interviews do you need for jobs to be done?
A good starting point is 8 to 12 interviews with recent switchers. Stop when new interviews mostly repeat stories you have already heard. If they keep surprising you, your target group may be too broad.
What is the difference between jobs to be done and personas?
A persona describes who the customer is, such as age or role. A job describes what they are trying to achieve and in what situation. Two very different people can share the same job, which is why jobs often guide product decisions better.
Can I use jobs to be done for a personal or career roadmap?
Yes. Ask what progress you want to make and what situation triggered it. Then map the steps of that job and plan phases around the steps where you struggle most.