Most product frameworks start with the product. Jobs-to-be-done starts with the person.
The jobs-to-be-done (JTBD) framework, popularized by Clayton Christensen in The Innovator's Solution (2003), flips the standard product lens. Instead of asking "who is our user?" it asks "what task is the user trying to finish?" That shift is minor. The implications for product decisions are large.
What a "job" actually means
A job is the progress a person wants to make in a specific situation. Christensen and his co-authors define it this way: "A job to be done is the progress that a person is trying to make in a particular circumstance" (Christensen, Hall, Dillon, and Duncan, "Know Your Customers' 'Jobs to Be Done,'" Harvard Business Review, 2016).
A job has three parts:
- A situation ("when I am...")
- A motivation ("I want to...")
- An outcome ("so I can...")
The milkshake study is the canonical example. McDonald's wanted to sell more milkshakes. Researchers segmented by demographics, asked customers what they wanted, and got nowhere. Then they asked a different question: what job are people hiring this milkshake to do?
Almost half of milkshakes sold before 9 a.m. to solo commuters. Those customers were not buying dessert. They were hiring something to make a long, boring drive more entertaining and to hold off hunger until lunch. The competitor for that job was a banana or a bagel, not a Wendy's Frosty. That framing changed the entire product direction.
Why this matters in a PM interview
Interviewers use JTBD questions to test whether you think in problems or in features. Weak answers describe what to build. Strong answers explain the job the user is trying to finish and derives the feature from that job.
Consider this prompt: "How would you improve Spotify?"
The weaker answer: "I would add social features and better playlist discovery."
The stronger answer: "Commuters hire Spotify to fill dead time with zero cognitive load. The job is passive entertainment during a task that requires some attention. Better playlist discovery helps, but the real friction is the decision to start playback in the first place. I would reduce that friction before adding social surfaces."
Both answers are product opinions. One starts from the job. The other starts from a feature list.
The three job layers
JTBD practitioner Bob Moesta, who worked with Christensen to develop the framework, draws a line between functional, emotional, and social dimensions of every job (Moesta and Spiek, Demand-Side Sales 101, 2020).
Functional: The literal task the person needs to finish. Buy groceries. Send money to a friend. Schedule a meeting.
Emotional: How the person wants to feel after finishing the task. Confident, in control, not embarrassed.
Social: How the person wants to be perceived by others. Competent, generous, modern.
In an interview, naming all three shows you understand that users make decisions based on more than utility. A person hiring Venmo to split a dinner check has a functional job (transfer money), an emotional job (avoid the awkward moment of owing a friend), and a social job (look like someone who does not sweat small amounts).
How to apply JTBD in a product sense question
The structure is simple:
- Name the job. Write it in the format: "When [situation], I want to [motivation], so I can [outcome]."
- Identify what forces push the user toward hiring a product for that job (anxieties and habits that hold them back, desires that pull them forward).
- Derive features from the job, not the other way around.
Marty Cagan makes a related argument in Inspired (2018): product teams that start with solutions instead of problems waste most of their build capacity on features users tolerate rather than features users need. JTBD gives you the discipline to stay in the problem space longer.
A worked example: a task management app
Suppose you are in a design exercise for a task management app. The temptation is to compare features to Todoist or Notion and find gaps. JTBD asks you to go upstream.
Who hires a task manager, and for what job?
One segment: a knowledge worker with too many open loops. The job is: "When I finish a meeting, I want to capture every commitment quickly, so I can stop thinking about them and focus on the next thing." The enemy of that job is friction at capture time. Every extra tap is a risk that the commitment goes unrecorded.
A second segment: a team lead coordinating a sprint. The job is: "When I check in with my team, I want a current status view I can trust, so I can have an honest conversation about blockers." The enemy of that job is stale data. Every manual update step is a leak in accuracy.
Two different jobs. Different products live inside the same app shell. Conflating them into one "task management" persona produces a product that solves neither job with precision.
The switch: what JTBD reveals about competition
The most useful idea JTBD surfaces is that your real competition is often not who you think. When someone stops using your product, they do not always hire a direct competitor. They hire any product that finishes the job with less friction.
Students who stopped buying physical textbooks did not all switch to e-books. Many hired YouTube tutorials and Reddit threads. The job was "understand a concept before an exam," and the competitor was any path that finished that job faster.
In a PM interview, naming the non-obvious competitor shows a JTBD-level analysis. It signals you think in jobs, not just in product categories.
Interview takeaway
When a prompt gives you a product to improve or a user problem to solve, pause before listing features. Ask what job the user is trying to finish. Write out the job statement. Name the functional, emotional, and social layers. Then derive your solution from the job.
That sequence will not guarantee a correct answer. It will guarantee a structured one, which is what interviewers at most top companies are actually evaluating.
Works cited
Christensen, Clayton M., Taddy Hall, Karen Dillon, and David S. Duncan. "Know Your Customers' 'Jobs to Be Done.'" Harvard Business Review, September 2016, https://hbr.org/2016/09/know-your-customers-jobs-to-be-done.
Moesta, Bob, and Greg Spiek. Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress. Lioncrest Publishing, 2020.
Cagan, Marty. Inspired: How to Create Tech Products Customers Love. 2nd ed., Wiley, 2018.