Jobs to be done template: how to write job statements from interviews

Most jobs to be done template pages give you empty boxes. The boxes are the easy part. What decides its value is how you fill it, so this one pairs every field with the interview question that fills it.

You will also get a blank copy, a test for job statements and a filled-in example. If your team built the feature everyone asked for and nobody uses it, our product discovery services run this research with you and turn it into build decisions.

What is a jobs to be done template?

A jobs to be done template is a form that records why a customer switched to a product: the situation, the progress they wanted and what nearly stopped them. It turns one interview into notes your team can compare with the next one.

The idea behind it is simple. The Christensen Institute describes a job as the progress someone is trying to make in particular circumstances, and says people "hire" products when those jobs arise. So the template studies the situation and leaves the demographic profile aside.

That difference matters when you plan. A customer profile tells you who bought, while a job tells you what they were trying to get done on the day they bought. Two very different people can share one job, and one person can have different jobs at different times.

Jobs to be done and Clayton Christensen's milkshake

The jobs to be done Clayton Christensen wrote about start with a situation, not a customer profile. Christensen was a Harvard Business School professor, and his best-known example with his co-authors is a milkshake.

In "Finding the Right Job For Your Product" (MIT Sloan Management Review, Spring 2007), a fast-food restaurant first asked people who fit its customer profile how to improve its milkshake. It acted on their feedback, and sales did not change.

A researcher then spent a day in a restaurant. He found that 40% of milkshakes were bought in the early morning, by people alone, who bought nothing else and drank them in their cars. They wanted something to make a long, boring commute more interesting and to hold off hunger, with one free hand. The real competition included bagels, donuts and bananas, not only another chain's milkshake.

Christensen and his co-authors repeated the core argument in "Know Your Customers' 'Jobs to Be Done'" (Harvard Business Review, September 2016): firms focus too much on customer profiles and correlations in data. It is not the only school. Anthony Ulwick wrote "Turn Customer Input into Innovation" (Harvard Business Review, January 2002) about the gap between what customers ask for and what succeeds. We use the interview-led approach here because it is a jobs to be done framework product management teams can run without a survey budget.

The jobs to be done template, field by field

This jobs to be done framework template has ten fields, and nine of them come straight from an interview. You write the job statement afterward, from your notes. Use one copy per person you interview, and keep their own words wherever you can.

Here is the blank version. Copy it into your own document.

Case: who switched, from what, to what, and when
Situation:
Old way:
Push:
Pull:
Anxiety:
Habit:
Candidates:
Hiring criteria:
Dimensions (functional, social, emotional):
Job statement: When [situation], I want [progress], so I can [outcome].

How to write a jobs to be done statement

Write a jobs to be done statement in one sentence: when a situation arises, I want some progress, so I can reach an outcome. Name no product, because the same job can be done by your product, a rival or a workaround.

This is the shape of a job story, which Alan Klement described on the Intercom blog in 2013 as a way to explore causality, anxieties and motivations. Three tests catch most weak statements.

• The situation test. Could you tell which day this applies? The authors of the milkshake article say the aim is to understand the situation, not the customer.
• The rival test. Could a competitor, or doing nothing, do the job? If only your product fits, you have described a feature.
• The evidence test. Can you point to the interviews behind it? If you cannot, it is a guess.

How to run the interview that fills the template

Interview people who recently made the switch, and walk through the story from the first thought to the decision. Ask what they did, not what they would like next, because past choices are your evidence.

Start with who you talk to. In a 2024 Business of Software session, Bob Moesta, whom the event calls an architect of Jobs to be Done, said to find the person who took the risk of bringing the product in. Others can tell you they like it, but they cannot tell you who had the first thought. He books an hour per interview and says it usually takes about 45 minutes, then spends another hour on a team debrief.

The timeline: four stages

1. First thought. Something happens that opens space for a change.
2. Passive looking. They start noticing options they ignored before.
3. Active looking. They raise a hand and compare what is out there.
4. Deciding. They weigh trade-offs, because no product is perfect for them.

The four forces: push, pull, anxiety and habit

Moesta listens for four forces in each story. Push and pull are the fuel for change: what is going wrong now, and what the new option would let them do. Anxiety and habit work against the change, and he says the change happens when push and pull outweigh them.

Teams tend to work on pull by adding features. Moesta argues that the larger gain usually sits in lowering anxiety, and he finds it with a plain question: what made you hesitate right before you bought it?

The Christensen Institute gives a clear example. Buyers of new condominiums kept bringing up what to do with their dining room table, which stood for family. The builder added moving services and storage, which eased the anxiety of leaving that table behind.

How to turn interviews into one clear job

Turn each interview into a short situation case, then group the cases until the jobs show themselves. One interview gives you a story, while a set of stories gives you a pattern you can plan around.

The MIT Sloan article describes the method in four moves, and it is the part most template pages skip.

1. Write the case. Record the chronological trail of events, experiences and thought processes behind the decision. The template above is that record.
2. Collect enough of them. The authors say about 25 situation cases generally make critical mass.
3. Group by similar situations. Often one large group appears, with a few smaller groups and outliers. Summarize the job for each group.
4. Compare the candidates. Build a table with job candidates down the left and the required experiences across the top. It shows your real competition.

You will not always reach 25 before you need a decision. Moesta described a working pattern with 10 stories: pair the two most similar, find the one most different, and keep sorting. He says you usually end with three to five groups, based on where people started and where they wanted to end up. Treat a small set as an early read, and keep adding cases while the groups are still moving.

A filled-in example

This invented example shows one case for a client reporting tool, told by the owner of a small marketing agency. Only the structure carries over, because your own cases must come from your own interviews.

Read the anxiety and hiring criteria rows together. A team that heard only "faster reports" would ship speed. This case points at trust instead: showing where each number came from did more to win the sale than any added chart.

Jobs to be done product management: what to build next

In product management, use jobs to be done to decide what to build and what to leave out. A feature earns its place when it does a job your cases support, or lowers the anxiety that stops people from switching.

The method works alongside your other tools. Each one answers a different question.

Klement argued that user stories can hide why a feature failed, because they mix the implementation with the motivation. You can keep them for delivery and still start from the job. Our user persona template covers the who, and the two forms share interview notes.

A job also gives your roadmap a sharper test during idea validation or a wider product discovery process. If you cannot name the job, or the rival that does it today, keep researching before you build. You can test the job's demand with our guide on how to validate a business idea.

How we use jobs to be done in discovery

We use this template when a team is unsure why customers buy, why they leave or which feature comes next. In a product discovery workshop, we run the interviews with your team, sort the cases together and turn the jobs into decisions your engineers can act on.

Every engagement is under an NDA, and the IP is always yours. Each project is different, so we quote it after a short call.

Frequently asked questions