The Jobs-to-be-Done Framework: Beyond the Buzzword Into Actual Practice

February 27, 2026•By Rasp Team

"What job did you hire this product to do?"

If you've read anything about product management in the last decade, you've heard about Jobs-to-be-Done (JTBD).

The theory sounds simple: People don't buy products. They hire them to make progress in their lives.

The practice is confusing: How do you actually apply this? What questions do you ask? How do you translate "jobs" into features?

Most PMs treat JTBD as a buzzword. They say "we're using a jobs-to-be-done approach" but just end up building feature requests anyway.

Here's the truth: JTBD is powerful when used correctly. But it requires discipline, specific techniques, and a shift in how you think about products.

This is how to actually use Jobs-to-be-Done — not just talk about it.

What Jobs-to-be-Done Actually Means

The Core Insight

People don't want products. They want to make progress.

Example:

Users don't want a drill. They want a hole in the wall.
Users don't want a hole. They want to hang a picture.
Users don't want to hang a picture. They want their home to feel personal.

The "job": Make my home feel personal.

The product: Could be a drill. Could also be adhesive hooks, command strips, or a picture ledge that requires no holes.

What JTBD reveals: The job (outcome) stays constant. The solution (product) can vary.

The Wrong Way to Think About JTBD

Wrong: "What features do users want?"

Still wrong: "What tasks do users need to accomplish?"

Right: "What progress are users trying to make?"

The difference:

Features: "I want a dark mode"
Tasks: "I want to read in low light"
Job: "I want to work late without eye strain"

Why it matters: Dark mode is one solution. But you could also solve with brightness controls, reading modes, or scheduled themes.

The JTBD Framework Components

Component 1: The Main Job

Format: "When [situation], I want to [motivation], so I can [outcome]."

Examples:

"When I'm managing a project, I want to see what everyone's working on, so I can identify blockers quickly."
"When I'm hiring, I want to screen candidates efficiently, so I can find the right person without wasting time."
"When I'm analyzing data, I want to spot trends visually, so I can make decisions faster."

Not: "I want a dashboard" or "I need better reporting."

Component 2: The Emotional Job

What it is: The feeling users want (or want to avoid).

Examples:

Feel confident (not anxious)
Feel productive (not overwhelmed)
Feel in control (not stressed)
Look competent (not foolish)

Why it matters: Products that solve functional AND emotional jobs win.

Example:

Functional job: Track expenses
Emotional job: Feel financially responsible
Product: Mint (makes you feel like a responsible adult, not just tracks numbers)

Component 3: Social Jobs

What it is: How users want to be perceived.

Examples:

Appear knowledgeable
Seem productive
Look professional
Be seen as innovative

Why it matters: People often hire products to signal identity.

Example:

Functional job: Take notes
Social job: Appear organized and thoughtful
Product: Notion (signals you're a productivity-minded professional)

Component 4: Constraints

What it is: The context and limitations around the job.

Examples:

Time constraints ("I have 5 minutes")
Skill constraints ("I'm not technical")
Resource constraints ("I have no budget")
Social constraints ("I can't look incompetent")

Why it matters: Same job, different constraints = different solutions.

How to Discover Jobs (Not Features)

The Switch Interview Method

Instead of asking about your product, ask about their last "switch."

The premise: People reveal jobs most clearly when they switch solutions.

Interview structure:

Part 1: First Thought (5 min)

"Tell me about when you first thought about switching from [old solution] to something else."

Listen for:

What triggered the thought?
What was broken?
What progress were they unable to make?

Part 2: Passive Looking (5 min)

"What did you do between that first thought and actively looking for alternatives?"

Listen for:

How long did they wait?
What finally pushed them?
What workarounds did they try?

Part 3: Active Evaluation (10 min)

"Walk me through how you evaluated options."

Listen for:

What criteria mattered?
What concerns did they have?
What trade-offs did they consider?

Part 4: Decision (5 min)

"What made you choose [new solution]?"

Listen for:

What was the deciding factor?
What anxieties did they have?
What got them over the hump?

Part 5: First Use (5 min)

"Tell me about your first day using it."

Listen for:

What was their first task?
What went well?
What was confusing?

What You're Actually Listening For

Not: Feature requests

But:

The push: What was broken in old solution?
The pull: What attracted them to new solution?
The anxiety: What made them hesitate?
The habit: What kept them on old solution?

Example from real interview:

PM: "Tell me about switching to Notion."

User: "I was using Google Docs for everything. But I kept losing files, couldn't organize projects, and my team couldn't find anything. I spent 30 minutes every morning just finding the right doc."

Analysis:

Job: Quickly access organized information
Push: Disorganization causing time waste
Anxiety: Will team adopt it?
Constraint: Needs to work for non-technical team

What NOT to build: Better search in docs

What to build: Structure that makes information findable without search

The JTBD Interview Question Library

Opening Questions

1. "Walk me through the last time you [did relevant task]."

Forces specific example, not hypothetical.

2. "What were you trying to accomplish?"

Gets at the outcome, not the process.

3. "What would success have looked like?"

Reveals the job (desired end state).

Digging Deeper

4. "What did you try before this?"

Uncovers failed solutions and why they failed.

5. "What almost stopped you?"

Reveals anxieties and barriers.

6. "How did you feel when [relevant moment]?"

Surfaces emotional jobs.

7. "Who else was involved?"

Identifies social jobs and stakeholders.

8. "What would have happened if you didn't solve this?"

Tests urgency and importance.

Understanding Trade-offs

9. "What did you give up to use this solution?"

Reveals what they value (and don't).

10. "If you could only keep one aspect, what would it be?"

Forces prioritization.

11. "What almost made you choose [alternative]?"

Shows competing jobs and solutions.

Validation Questions

12. "How has this changed your [workflow/life]?"

Tests if job is actually being fulfilled.

13. "Would you go back to the old way?"

Measures satisfaction and switching costs.

14. "Who have you recommended this to?"

Tests if social job is being fulfilled.

Translating Jobs into Product Decisions

Step 1: Identify the Core Job

Bad job statement: "Users want better analytics."

Good job statement: "When reviewing performance, users want to quickly identify what's working so they can double down on successful strategies."

How to get there:

Ask "why" three times:

"Why do you want better analytics?"
→ "To see what's working"
"Why do you need to see what's working?"
→ "So I can focus on successful strategies"
"Why focus on successful strategies?"
→ "So I can grow revenue without wasting time"

The real job: Identify growth levers quickly

Step 2: Map Jobs to Solutions

Don't jump to features. Consider multiple solutions.

Example:

Job: "Quickly identify what's working"

Possible solutions:

Advanced analytics dashboard
Automated insights ("Your top performer this week is...")
Comparative benchmarks
AI-generated recommendations
Weekly email digest
Simplified metrics (show only what matters)

Which to build? Depends on constraints:

Time: Digest wins (fastest to consume)
Skill: Automated insights (no analysis needed)
Control: Dashboard (deep diving)

Step 3: Define Success Criteria

For each job, ask:

How will we know this job is being fulfilled?
What's the measurable outcome?

Example:

Job: "Quickly identify what's working"

Success metrics:

Time to insight: <5 minutes (vs. 30 before)
Confidence: 80%+ feel confident in decisions
Action: 70%+ take action within 24 hours

Not: "Feature adoption rate" or "dashboard views"

Real-World JTBD Examples

Example 1: Uber

Feature mindset: "People want to hail cabs faster."

JTBD mindset:

Main job: Get from A to B reliably
Emotional job: Feel in control of arrival time
Social job: Not look like you're lost/waiting
Constraints: Don't want to carry cash, deal with uncertainty

What Uber built:

Upfront pricing (control)
GPS tracking (anxiety reduction)
Cashless (convenience)
Arrival time estimate (planning)

Key insight: The job wasn't "hail cabs faster." It was "predictably get somewhere without stress."

Example 2: Intercom

Feature mindset: "People want better live chat."

JTBD mindset:

Main job: Help customers before they churn
Emotional job: Feel like you're providing good service
Social job: Appear responsive as a company
Constraints: Can't hire 50 support people

What Intercom built:

Targeted messages (proactive, not reactive)
Automation (scale without hiring)
User context (feel personalized)
Response time tracking (measure responsiveness)

Key insight: The job wasn't "chat with customers." It was "appear responsive at scale."

Example 3: Figma

Feature mindset: "Designers want better design tools."

JTBD mindset:

Main job: Collaborate with team on designs
Emotional job: Feel productive, not blocked
Social job: Show design thinking to stakeholders
Constraints: Team is distributed, can't all use same computer

What Figma built:

Real-time collaboration (unblocked)
Web-based (no installation barrier)
Commenting (async feedback)
Dev handoff (whole workflow)

Key insight: The job wasn't "design faster." It was "design collaboratively without friction."

Common JTBD Mistakes

Mistake #1: Jobs Are Too Narrow

Bad: "Create invoice"

Why: That's a task, not a job.

Better: "Get paid for work quickly and professionally"

Fix: Ask "why" until you get to the outcome.

Mistake #2: Jobs Are Too Broad

Bad: "Be successful in business"

Why: Too vague to be actionable.

Better: "Make data-informed decisions confidently"

Fix: Add context (when, where, what constraints).

Mistake #3: Confusing Jobs with Solutions

Bad: "Use a spreadsheet"

Why: That's a solution, not a job.

Better: "Track data in a flexible way"

Fix: Ask what progress they're trying to make with that solution.

Mistake #4: Focusing Only on Functional Jobs

Problem: You build something that works but nobody loves.

Example:

Functional job: Track expenses ✓
Emotional job: Feel financially responsible ✗
Result: Works but feels like homework

Fix: Always identify emotional and social jobs too.

Mistake #5: Asking About Jobs Directly

Bad: "What job are you hiring this product to do?"

Why: Users don't think in JTBD terms. They'll give surface answers.

Better: Ask about specific situations, decisions, and switches.

Fix: Use the switch interview method.

The JTBD Research Template

Use this template for JTBD interviews:

# JTBD Interview: [User Name]

## Background
- Role: [Title]
- Company: [Name]
- Context: [Relevant info]

## The Switch Story

### First Thought
Q: When did you first think about switching from [old solution]?
A:

What triggered it:
What was broken:

### Passive Looking  
Q: What happened between that first thought and actively looking?
A:

How long:
What workarounds:

### Active Evaluation
Q: How did you evaluate alternatives?
A:

Criteria that mattered:
Concerns:
Trade-offs:

### Decision
Q: Why did you choose [new solution]?
A:

Deciding factor:
Remaining anxieties:

### First Use
Q: Tell me about your first day using it.
A:

First task:
What went well:
What was confusing:

## JTBD Analysis

### Main Job
When [situation], I want to [motivation], so I can [outcome].

### Emotional Job
Feel [desired feeling], not [feared feeling].

### Social Job
Appear [desired perception].

### Constraints
- [Constraint 1]
- [Constraint 2]

### Forces
- **Push** (what was broken): 
- **Pull** (what attracted):
- **Anxiety** (what caused hesitation):
- **Habit** (what kept them from switching):

## Insights

Key takeaways:
1.
2.
3.

Opportunities:
1.
2.

How to Apply JTBD to Your Product

Step 1: Map Your Users' Jobs

Do this:

Interview 10-15 users about their switch
Map out main, emotional, and social jobs
Identify common patterns

Create job map:

Job: [Job statement]

Who has this job: [Segment]
When: [Situation]
Constraints: [Context]

Current solutions:
- [Solution 1]: Pros/Cons
- [Solution 2]: Pros/Cons

Gaps in solutions:
- [Gap 1]
- [Gap 2]

Opportunity: [What you could build]

Step 2: Prioritize Jobs

Not all jobs are equal.

Evaluate on:

Frequency: How often does this job arise?
Importance: How critical is success?
Satisfaction: How well are current solutions working?

Formula:

Opportunity Score = Importance + (Importance - Satisfaction)

Focus on: High importance, low satisfaction jobs.

Step 3: Design Solutions

For each priority job:

Brainstorm multiple solutions (not just one)
Consider functional, emotional, and social aspects
Test against constraints

Example:

Job: "Get confident in decisions quickly"

Solutions:

Automated insights (fast, low skill)
Expert recommendations (confident, trusted)
Comparative benchmarks (context, confidence)
Decision frameworks (structured, thorough)

Test against constraints:

Time: Solution 1 wins
Confidence: Solution 2 wins
Independence: Solution 3 wins

Step 4: Validate

Before building:

Show concepts to users
Ask: "Would this help you [make desired progress]?"
Watch for: Do they get excited about the outcome, not just the feature?

JTBD in Practice: A Week-by-Week Plan

Week 1: Set Up

Define user segment to study
Recruit 10 interviewees
Prepare interview guide

Week 2-3: Interview

Conduct 10 switch interviews
Record and transcribe
Take detailed notes

Week 4: Analysis

Map out jobs from interviews
Identify patterns
Create job statements

Week 5: Prioritization

Score jobs by opportunity
Map current solutions
Identify gaps

Week 6: Solution Design

Brainstorm solutions for top jobs
Create concepts
Get team input

Week 7: Validation

Test concepts with users
Iterate based on feedback
Select solutions to build

Final Thought

Jobs-to-be-Done isn't about asking "What job are you hiring this for?"

It's about understanding the progress users are trying to make.

The job isn't "use a todo app."

It's "feel in control of my workload."

The job isn't "collaborate on documents."

It's "work together without chaos."

When you understand the job — the real outcome users want — you can design better solutions than if you just asked for features.

Stop asking what users want.

Start understanding what progress they're trying to make.

That's Jobs-to-be-Done.