What Is Jobs to Be Done? A Practical Guide With Interview Questions

Author: Inputly

What is Jobs to Be Done?

Jobs to Be Done explains customer behaviour by the progress a customer is trying to make, not by who they are. Every purchase was a hire: a situation appears, a motivation follows, and the customer picks whatever gets them to the outcome with the least friction.

It also changes what counts as competition. If the job is "get a clean summary to a client before the end of the day", your competitors are other apps, a spreadsheet, a copy-and-paste ritual, and doing nothing at all. The last one is usually the strongest and the only one nobody tracks.

TL;DR: A job is a situation plus a motivation plus an expected outcome, written without naming a product. Interview people about the last time they actually switched, never about what they might want, and treat every awkward workaround as evidence of a job that is not being served.

What is a job statement?

The formula is: when [situation], I want to [motivation], so I can [expected outcome]. The discipline is that your product name never appears, because the moment it does you have written a feature description instead of a job.

| Job statement | Why it works, or fails | | --- | --- | | When I finish a customer call and my notes live in three tools, I want one place that assembles a summary, so I can send it before the client forgets the call | Situation, friction and outcome, with no product named | | When a sales team grows past five people, they want better reporting so they can coach reps | Describes an organisation, not a person in a moment, so nobody can act on it | | When a customer asks for a dark mode, I want a theme switcher so I can stop the requests | A solution disguised as a job. The real job is comfort in long sessions | | When my weekly report eats two hours of copying numbers, I want the numbers to arrive assembled, so I can spend the time on the analysis | Specific and testable, and it implies what to build without naming it |

Write jobs at a level you can detect in your product. "Be more productive" is true and useless, because nothing in your data tells you when it is happening.

How do you run a Jobs to Be Done interview?

Interview people who recently switched, not people who might: a switch is a memory with events in it, and events are what you mine.

1. Recruit within a few months of a real decision, including people who chose a spreadsheet or a manual process instead of you.
2. Ask for the story of the decision, step by step, from the moment the problem first showed up.
3. Follow the timeline, not your hypothesis: "what happened next", "who else noticed", "what did you try before this".
4. Hunt the awkward moment and the cost of the old way: the workaround, the borrowed login, the hours spent, the deadline missed. Friction is the best evidence of a job that is not being served.

Keep the interview in the past. Questions about what a customer would want or would pay for return polite guesses, and guesses are what make teams build features nobody adopts.

Which interview questions reveal the real job?

• "Walk me through the day the problem came up for the first time."
• "What did you try before this?" then "why did that stop working?" for each answer.
• "What would you have done if you had not found us?" This one reveals your real competition, doing nothing included.
• "What had to be true for you to finally switch?" Timing, budget, trust and authority usually live in this answer.

Group the answers by situation, not by customer. Situations that repeat are your jobs, and the ones that appear once are anecdotes rather than strategy. The craft of the conversation itself is covered in user interview questions.

How is Jobs to Be Done different from a persona or a feature request?

A persona describes who the customer is, and it aligns a team on a segment, but it predicts behaviour weakly: the same person hires different products in different situations. A feature request names a solution, so it hides the problem underneath. A job sits between them and explains the switch. In practice the request tells you what someone asked for and the job tells you which situation produced it, so requests with no job behind them are usually one person's preference, while jobs with no requests yet are the gap nobody has reported, which is what product discovery exists to find.

What are the common mistakes?

• Writing the product into the job statement, which turns research back into a pitch.
• Interviewing future intentions instead of past behaviour, which returns a wish list.
• Embedding the hypothesis in the question, so the customer hears the answer you want.
• Only interviewing happy customers. People who left can describe the job your product stopped doing well.

How do you turn jobs into a roadmap?

Tag incoming feedback with the situation it came from, not only the feature it mentions, then sort by job. You will usually find that three loud requests belong to one job, which is an easier decision than arguing about three features.

From there, read your voice of customer data for repeating situations, map the requests onto them, and prioritise with how to prioritise feature requests or the Kano model when you need to know how much satisfaction each job carries. Then close the loop with the people who told you: nothing validates a job faster than shipping for it and hearing that the workaround is gone.

Frequently Asked Questions

1. What is the difference between a job and a need? A need is a state, a job is a situation with a goal attached. "I need better reporting" cannot be acted on, while "when the board asks for numbers two days before the meeting, I want them assembled already" can.
2. Do you need a special tool for Jobs to Be Done? No. A shared document of interviews and a tag for the situation behind each piece of product feedback is enough to start. The theory fails from skipped interviews, not from missing software.
3. How do you validate a job before building? Look for the workaround. If people are doing the job manually, badly, across three tools and a spreadsheet they built themselves, the job is real. If nobody is building anything, the situation is not painful enough yet.
4. Can a job statement change over time? Yes, so review it. Jobs get served better by the market, and a job that was urgent three years ago may now be table stakes.
5. How does Jobs to Be Done fit with Kano or RICE? Jobs explain what the customer is trying to do, Kano explains how much satisfaction a feature carries, and a scoring model sequences the work. Run the job first, because it decides which features deserve the other two analyses.

Start with the last five customers who switched and write down the situation that made them move. Run the interviews in a free space on Inputly, tag every request with the job behind it, and let the repeating situations decide what you build next.