Every product team has shipped a feature that tested well in usability studies, hit no technical blockers, launched on schedule, and then sat untouched in production. The feature worked perfectly. Nobody wanted it.
The jobs to be done framework explains why this happens. Customers do not buy products. They hire them to make progress in their lives. When you understand the progress a person is trying to make (the “job”), you stop guessing which features to build and start designing solutions that people actually switch to, pay for, and keep using.
This is not abstract theory. Strategyn, the firm that commercialized the framework, reports an 86% product success rate across hundreds of engagements. Microsoft used JTBD to redesign its Software Assurance program and saw 100% year over year revenue growth. vAuto applied it to dealer inventory management and achieved a 20x increase in product installs. The framework works because it reorients your entire product conversation around why customers act, not just what they do.
Here is how to apply jobs to be done in your product work: from understanding the core concepts to conducting interviews, writing job statements, and using the four forces model to predict adoption.
Table of contents
- What is the jobs to be done framework?
- The three dimensions of every job
- Job statements: the format that makes JTBD actionable
- The four forces of progress
- How to run JTBD switch interviews
- Turning interview data into product decisions
- JTBD vs. personas, user stories, and design thinking
- Common mistakes teams make with JTBD
- Frequently asked questions
What is the jobs to be done framework?
The jobs to be done framework is an innovation methodology built on one insight: people do not buy products for their features. They “hire” products to help them accomplish something in a specific circumstance. Clayton Christensen popularized this idea with the famous milkshake study. When McDonald’s wanted to sell more milkshakes, traditional market research (demographics, taste tests, focus groups) produced nothing useful. But when researchers asked “what job are you hiring the milkshake to do?” they discovered morning commuters were hiring it to make a boring drive interesting and to keep them full until lunch. That insight led to product changes no survey would have suggested.
Tony Ulwick formalized the framework into a repeatable process called Outcome Driven Innovation (ODI) in the early 1990s. Bob Moesta developed the “switch interview” technique that maps the forces driving customer decisions. Together, these approaches give product managers a structured way to understand customer motivation at a level that feature requests and analytics never reveal.
The framework applies equally to B2C and B2B products. A person hiring a project management tool is trying to “coordinate work across remote team members so nothing falls through the cracks.” A person hiring a CRM is trying to “track every customer interaction so I never lose context before a sales call.” Once you articulate the job clearly, you can evaluate every feature against whether it helps the customer make that progress.
The three dimensions of every job
Every job has three dimensions. Most product teams only address the first one, which is why their solutions feel incomplete or fail to drive switching behavior.
Functional dimension. The practical task the customer needs to accomplish. “Transfer money to another country within 24 hours.” “Find a babysitter for Saturday night.” “Reduce page load time below two seconds.” This is the dimension that product teams default to because it is the easiest to measure and build for.
Emotional dimension. How the customer wants to feel (or avoid feeling) while doing the job. “Feel confident I am not overpaying.” “Feel in control of my project timeline.” “Avoid the embarrassment of presenting unreliable data to executives.” Emotional jobs explain why customers pay premium prices for functionally equivalent products.
Social dimension. How the customer wants to be perceived by others. “Look competent in front of my engineering team.” “Be seen as the person who introduced a better process.” “Avoid looking like I wasted company resources.” Social jobs explain adoption patterns in enterprise software, where the buyer’s reputation is tied to whether the tool succeeds.
When you design for all three dimensions, you create products that customers feel loyal to, not just satisfied with. A product strategy that accounts for emotional and social jobs generates differentiation that competitors cannot copy by replicating features.
Job statements: the format that makes JTBD actionable
A well written job statement turns vague customer needs into something your team can design against. The format follows a specific structure:
[Action verb] + [object of action] + [contextual clarifier]
Examples:
- “Coordinate cross-functional dependencies when planning a quarterly release”
- “Identify which customer segments are churning before the renewal conversation”
- “Communicate product decisions to stakeholders who were not in the room”
Notice what these statements do NOT include: any reference to a solution. “Use Jira to track bugs” is not a job statement. “Ensure no critical bug reaches production without visibility” is. The distinction matters because solution-free statements keep your team open to better approaches.
Outcome statements add a measurable layer. Tony Ulwick’s format specifies: [direction of improvement] + [metric] + [object of control]. For example:
- “Minimize the time it takes to identify which tasks are blocked”
- “Reduce the likelihood of misaligning with stakeholders on scope”
- “Increase the accuracy of effort estimates for new feature work”
When you combine job statements with outcome statements, you have a precise specification for what success looks like from the customer’s perspective. This becomes your north star for product discovery and prioritization.
The four forces of progress
Understanding jobs tells you what customers want to accomplish. The four forces model, developed by Bob Moesta, tells you whether they will actually switch to your product to accomplish it. This is critical because most products fail at adoption, not at functionality.
Four forces act on every switching decision:
Force 1: Push of the current situation. The frustration, pain, or limitation the customer experiences with their current approach. “My spreadsheet breaks every time we add a new team member.” “I spend three hours every Monday manually compiling metrics.” The stronger the push, the more motivated someone is to look for alternatives.
Force 2: Pull of the new solution. The attraction of what could be different. “Imagine automatically syncing data across all our tools.” “What if I could see blockers before standup instead of discovering them during?” Pull creates the desire to change.
Force 3: Anxiety of the new. The concerns, risks, and uncertainties about switching. “What if migration breaks our existing workflows?” “Will my team actually adopt this?” “What if the data does not transfer correctly?” Anxiety slows or kills adoption even when push and pull are strong.
Force 4: Habit of the present. The inertia of the status quo. “We have always used Excel for this.” “Everyone already knows how the old system works.” “Switching would require retraining 50 people.” Habit keeps people stuck even when they acknowledge the current situation is painful.
The switching equation: a customer hires a new product only when (Push + Pull) > (Anxiety + Habit).
This model explains why superior products often lose to inferior incumbents. It also tells you exactly what to address in your product roadmap: reduce anxiety (free trials, migration support, gradual rollouts), overcome habit (familiar UI patterns, backward compatibility), amplify push (surface pain points in onboarding), and strengthen pull (demonstrate progress quickly).
How to run JTBD switch interviews
The switch interview is the primary research tool for JTBD. Unlike standard user interviews that ask about preferences or satisfaction, switch interviews reconstruct the timeline of a specific decision: the moment a customer switched from one solution to another (or from nothing to something).
Who to interview. People who recently made a switching decision. “Recently” means within the last 30 to 90 days; beyond that, memory becomes unreliable. You need 10 to 15 interviews to surface the majority of actionable patterns.
The timeline structure. Walk the customer backward through their decision:
- First thought. “When did you first realize you needed something different?” This reveals the initial push event.
- Passive looking. “What did you do after that? Did you look around?” This reveals awareness channels and consideration criteria.
- Active looking. “When did it get serious? What triggered you to actively search?” This reveals the tipping point.
- Decision. “How did you decide? What made you pick this over alternatives?” This reveals pull factors and anxiety resolution.
- Consumption. “What was the first experience like? Did it deliver what you expected?” This reveals onboarding gaps.
What to listen for. Struggle moments (“I was frustrated because…”), workarounds (“I tried using X but it didn’t work for…”), tradeoffs (“I gave up Y to get Z”), and emotional language (“I was embarrassed,” “I finally felt in control”). These reveal jobs, outcomes, and forces that no survey will capture.
After five interviews, you will start hearing patterns. After ten, you will have enough data to build a discovery evidence base that your team can prioritize against.
Turning interview data into product decisions
Raw interview transcripts are useless without synthesis. Here is a practical process for turning JTBD research into decisions your team can act on:
Step 1: Extract job statements. Review each interview and pull out the core jobs the customer was trying to accomplish. Consolidate duplicates. A typical product covers 5 to 15 distinct jobs.
Step 2: Map outcome statements. For each job, list how customers measure success. What did they want to be faster, cheaper, more accurate, or less likely to fail? These become your outcome statements.
Step 3: Quantify satisfaction gaps. If possible, survey a broader audience on each outcome: “How important is this?” and “How satisfied are you with your current solution?” Outcomes that score high importance and low satisfaction represent your biggest opportunities. This is Ulwick’s opportunity algorithm: Opportunity = Importance + (Importance minus Satisfaction).
Step 4: Prioritize against forces. For each opportunity, assess: Is the push strong enough that people are actively looking for alternatives? Is the anxiety manageable? Is habit entrenched? A high opportunity score with insurmountable habit may need a different go to market approach (gradual migration, integration with existing tools) rather than a better feature set.
Step 5: Define success metrics. Translate each prioritized outcome into a measurable product metric. “Minimize time to identify blocked tasks” becomes “reduce average time from task blocker creation to PM awareness to under 4 hours.” Now your engineering team knows exactly what good looks like.
This process connects customer research directly to sprint planning without the usual telephone game of insights getting diluted through handoffs.
JTBD vs. personas, user stories, and design thinking
JTBD does not replace other product tools. It operates at a different level of abstraction and makes the other tools more effective.
JTBD vs. personas. Personas describe who the customer is (demographics, behaviors, goals). JTBD describes what progress they are trying to make. The same job can cut across multiple personas. A first-time founder and an enterprise VP can both hire the same product to “communicate product decisions to people who were not in the room.” JTBD reveals market segments that persona-based approaches miss.
JTBD vs. user stories. User stories describe what someone wants to do inside your product (“As a PM, I want to drag tasks between columns so I can update their status”). JTBD describes the underlying motivation that should inform those stories (“Ensure my team has real-time visibility into what is blocked”). Great user stories are written after you understand the job they serve.
JTBD vs. design thinking. Design thinking provides a process for ideating and prototyping solutions. JTBD provides the problem definition that makes design thinking productive. Without a clear job, design thinking can generate creative solutions to the wrong problem. Used together, JTBD defines the target and design thinking finds the path.
JTBD vs. opportunity solution trees. Teresa Torres’ framework maps opportunities to solutions. JTBD defines what qualifies as a real opportunity. The combination is powerful: jobs and outcomes feed the “opportunity” layer of the tree, ensuring you are solving problems customers actually have.
Common mistakes teams make with JTBD
Mistake 1: Writing job statements that describe solutions. “Hire a project management tool” is not a job. “Coordinate work across remote team members” is. If your job statement mentions a product category, you have described a solution, not a job.
Mistake 2: Ignoring emotional and social dimensions. If you only map functional jobs, you will build a feature-complete product that nobody prefers over the competition. The emotional job “feel confident presenting data to my VP” explains why some teams pay 5x for a polished analytics tool over a functionally equivalent open source alternative.
Mistake 3: Interviewing the wrong people. JTBD switch interviews require people who recently made a decision. Interviewing long-time loyal users tells you about satisfaction, not about switching forces. Interviewing people who never switched tells you about habit and anxiety, which is useful, but it will not reveal pull factors.
Mistake 4: Treating JTBD as a one-time exercise. Jobs are stable, but the competitive landscape changes. The job “stay informed about industry news” has not changed in decades, but the solutions people hire for that job (newspapers, RSS, Twitter, newsletters, AI summaries) shift constantly. Revisit your forces analysis quarterly.
Mistake 5: Skipping the quantitative step. Ten interviews reveal patterns, but they do not tell you which patterns represent large market segments. After qualitative research, validate with a broader survey to size opportunities before committing engineering resources.
Frequently asked questions
What is the jobs to be done framework?
Jobs to be done (JTBD) is a product innovation framework built on the principle that customers do not buy products for their features; they hire them to make progress in specific life or work situations. Developed by Clayton Christensen, Tony Ulwick, and Bob Moesta, the framework helps product teams understand the functional, emotional, and social dimensions of what customers are trying to accomplish, then design solutions that address those underlying motivations rather than surface-level feature requests.
What is a real example of jobs to be done?
The classic example: customers do not buy a drill because they want a drill; they hire it to make a hole in the wall. More relevantly, Basecamp discovered through JTBD research that customers were not hiring their product to “manage projects.” They were hiring it to reduce communication chaos, create accountability, and achieve a feeling of control over their workday. That insight shaped product decisions differently than feature parity analysis ever would.
How many JTBD interviews do I need to run?
Research consistently shows that 10 to 15 switch interviews reveal the majority of actionable patterns. Start with 5 to identify initial themes, then continue until you hear the same forces and jobs repeated. If you reach 12 interviews without convergence, you may be mixing customer segments that have fundamentally different jobs.
How is jobs to be done different from user stories?
User stories describe what a user wants to do within your product (“As a PM, I want to filter by sprint so I can see current work”). JTBD describes the underlying progress the user is trying to make in their life or role (“Ensure nothing falls through the cracks during a release cycle”). Jobs are stable and solution-agnostic; user stories are specific to a product’s implementation. The best user stories are written after the team understands which job they serve.
Can I use JTBD with agile or continuous discovery?
Yes. JTBD provides the problem definition layer that makes continuous discovery more effective. Use switch interviews during discovery to identify jobs and outcomes. Feed those outcomes into your opportunity solution tree as validated opportunities. Prioritize stories in sprints based on which underserved outcomes they address. The framework integrates naturally with Teresa Torres’ continuous discovery habits and with research synthesis practices that product teams already use.