Jobs to Be Done was developed independently by Harvard Business School professor Clayton Christensen and innovation consultant Tony Ulwick in the 1990s and popularized through Christensen's book The Innovator's Solution (2003) and Bob Moesta's practical application work at the ReWired Group.
The core insight: when a customer buys a product, they are "hiring" it to make progress in a specific circumstance. The milkshake example is the canonical illustration — McDonald's discovered that half of their milkshakes were sold in the morning to commuters. The commuters were not buying a milkshake because they wanted a beverage; they were hiring it to keep them occupied during a boring commute and to provide a feeling of fullness until lunch. The job was "make my commute less boring and delay hunger until noon." This insight revealed that McDonald's was competing not with other milkshakes but with bagels, bananas, and podcasts — none of which McDonald's had considered competitors.
JTBD changes how product teams think about competition, user research, and feature design. Instead of asking "what features do users want?" (which produces feature requests), JTBD asks "what job is the user trying to get done, and what are they hiring today to do it?" (which produces insight into unmet needs and unexpected competition).
JTBD vs user personas vs user stories
Jobs to Be Done: Focuses on the circumstance and desired outcome — the "job" the user is trying to accomplish regardless of who they are. A 35-year-old product manager and a 22-year-old junior PM might hire the same tool for different jobs. JTBD ignores demographics and focuses on motivation and context.
User personas: Focuses on who the user is — demographics, behaviors, goals, and pain points. Personas are useful for communication and alignment ("we're designing for Sarah, the senior PM at a startup") but can mislead when the persona's characteristics predict feature preferences incorrectly. JTBD is often used to enrich or replace demographic personas with motivation-based ones.
User stories: Operational-level descriptions of what a user wants to do in a product context. User stories are derived from JTBD — once you know the job, you write user stories that describe how your product enables the user to get the job done. JTBD is the upstream discovery; user stories are the downstream specification.
How to Use Jobs to Be Done in Product Management
The JTBD interview format, developed by Bob Moesta, focuses on the moment of switching — when a customer first adopted your product or a competing solution. The key questions:
- "Walk me through the first time you decided to look for [product type]."
- "What was happening in your life at that point that made you look?"
- "What did you try first? What worked and what didn't?"
- "The day you switched to [product] — what happened that day that made you decide?"
The goal is to identify the "struggling moment" — the specific circumstance that triggered the customer to look for a solution. This reveals the actual job they were hiring for, which is almost always more specific and context-dependent than what any user persona or NPS survey would suggest.
JTBD job statements follow the format: "When [situation], I want to [motivation], so I can [expected outcome]." This is more specific than a user story because it includes the situation — the circumstance that triggers the need. A job statement for Scriptonia: "When I have a new feature approved by my CPO, I want to generate a complete engineering spec immediately, so I can hand off to engineering at the next sprint planning without a week of documentation work."
Jobs to Be Done Examples
1JTBD for a PRD tool (Scriptonia)
Job: 'When I have a validated feature idea and engineering resources available, I want to produce a complete, engineering-ready specification immediately, so I can start the sprint without losing a week to documentation.' Current hire: manually writing PRDs in Notion or Google Docs. Competing alternatives: ChatGPT with PRD prompts, ChatPRD, Confluence templates. What triggers the switch to Scriptonia: the frustration of spending 4+ hours on a PRD that still gets rejected by the tech lead for missing edge cases.
2JTBD for a task management app
Job (discovered through JTBD interviews): 'When I leave the office on Friday afternoon, I want to feel confident that I have not forgotten anything important, so I can actually relax over the weekend.' Note: this job has nothing to do with task management during the workweek — it is about the emotional outcome of mental closure at the end of the week. A competitor is not Asana or Jira — it is the habit of writing a Friday summary in a journal. This insight could drive a 'weekly review' feature that no task management app had built before.
3JTBD for an analytics tool
Job: 'When I present quarterly metrics to leadership, I want to explain not just what happened but why it happened, so I can demonstrate product judgment rather than just data reporting.' Current hire: manually building slide decks from Amplitude exports + adding commentary. The job is not 'visualize data' (what the tool does) — it is 'demonstrate PM credibility in leadership meetings' (what the user needs). This insight suggests investing in narrative-generation features and executive summary templates rather than more chart types.
How Scriptonia Automates This
JTBD informs Scriptonia's core product philosophy. The job product managers hire Scriptonia for is not "write a document" — it is "get a validated feature from idea to engineering-ready specification as fast as possible without losing context or completeness." This job statement drove the decision to generate all 10 PRD sections simultaneously (not sequentially), and to include engineering tickets as part of the output rather than as a separate step.
When writing a PRD in Scriptonia, the job statement for the feature you are specifying goes in the problem statement field — phrased in JTBD terms ("When [situation], the user wants to [motivation], so they can [outcome]"). This framing produces more user-centric PRDs than feature-centric problem statements, and generates more accurate edge cases and acceptance criteria from the AI.