Idea and Purpose: Jobs To Be Done is a framework for understanding customer needs by focusing on the underlying "job" or task the user is trying to accomplish, rather than on the specific product or solution. Popularized by Clayton Christensen (with the famous "milkshake example") and practitioners like Tony Ulwick, JTBD asserts that people "hire" products to get a job done.
In other words, a user isn't buying a drill for the drill's sake; they want a quarter-inch hole (the job to be done). By studying the "job," we can uncover true customer requirements and innovate more predictably. The core concept is that behind every purchase or product use, there's a desired outcome or problem being solved – the Job. Understanding that job in depth (its steps, struggles, and context) leads to better product design and strategy.
Structure and Components: JTBD involves identifying a Job Statement – a concise expression of what the user is trying to achieve. A well-defined job is usually phrased in verb-object terms, devoid of solution bias. For example: "Parents want to prepare a healthy dinner quickly after work." The job is not "use our cooking app" – that's a solution. It's the higher-level goal of the user. Tony Ulwick's approach defines a job as stable over time, solution-agnostic, and measurable by outcome criteria. Ulwick often breaks a job into steps in a "Job Map." Research shows most jobs have around 8 ± 2 steps from start to finish (e.g. Define, Locate, Prepare, Confirm, Execute, Monitor, Modify, Conclude – a generic template of steps many jobs entail).
By mapping the job's steps and analyzing where users encounter difficulties (outcome metrics that are underserved), teams can find innovation opportunities. Another practical structure is the Job Story format, used in product teams for feature definition: "When [situation], I want to [do something], so I can [achieve some outcome]." This template was introduced by the team at Intercom to replace user stories in some cases.
For example: "When I'm commuting, I want to listen to a news podcast, so I can stay updated on current events." This frames the feature around the job (staying informed during commute) rather than a persona.
Usage: To apply JTBD, teams often start by interviewing customers with a focus on why they use certain solutions and what outcome they seek. A classic line of inquiry is to explore the circumstances of a customer's decision: "Tell me about the last time you [hired or fired a product]. What led to it?" The aim is to get stories of their behavior, uncovering their true motivations and constraints.
Once jobs are identified, personas are less emphasized; instead, you consider the context. However, different customers can have different jobs or different priority outcomes, so segmentation might shift to "job segments" instead of demographics. JTBD frameworks like Outcome-Driven Innovation (ODI) involve capturing customer desired outcomes and quantifying which outcomes are underserved by current solutions. This reveals opportunities for improvement or new products.
Example: Consider a ride-sharing app. A traditional requirement might say "We need a feature to schedule rides in advance." But using JTBD thinking, we ask: What job might a scheduled ride fulfill? Perhaps "Ensure I arrive at the airport on time for an early flight." The user's underlying job is "get to an important appointment reliably". Once we frame that, we might find alternative solutions to satisfy that job better.
Common Mistakes: A frequent mistake is defining the "job" at the wrong level of abstraction. If it's too narrow or too broad, it loses value. Another mistake is confusing Jobs-To-Be-Done with user stories or tasks. JTBD is about the outcome and context, not a specific feature. Also, mixing up the "job" with the "solution" is an error. The job should be stated free of any technology or product features.
Variations: JTBD theory has different schools of thought. Ulwick's ODI is quantitatively rigorous, whereas others emphasize narrative techniques. Some teams use JTBD Canvas or similar tools. Also, JTBD dovetails with Lean Startup philosophy – treating new features as hypotheses about helping the user get a job done.
Summary: Jobs To Be Done reframes our thinking to why the user "hires" our product, leading to more user-centric and potentially innovative product decisions.
Paste your task description in the input field. Maximum 1000 characters supported.
Choose Jobs to be Done from the framework selector to validate against this specific methodology.
Click Analyze to receive instant AI-powered feedback with highlighted issues and improvement suggestions.
Review and implement the suggested fixes to transform your task into proper Jobs to be Done scenarios.