jobs-to-be-done

What this skill does

<objective>
Analyze markets, products, and prospects through the Jobs To Be Done lens — the innovation framework developed by Clayton Christensen (Competing Against Luck) and operationalized by Tony Ulwick (Outcome-Driven Innovation).

**Core insight:** Customers don't buy products. They hire them to make progress in specific circumstances. Understanding the job — not the customer demographics or product features — is what predicts success.

**Dual-use skill:**
- **Sales/BDR Mode:** Use Forces of Progress and Switch Interviews to understand why prospects switch, structure discovery calls around the job map, and frame value propositions as outcome statements
- **Strategy Mode:** Use the full ODI methodology to score outcome importance vs satisfaction, identify underserved opportunities, and analyze competitive hiring/firing dynamics

When to activate: user asks about jobs to be done, JTBD analysis, customer jobs, outcome-driven innovation, forces of progress, switch interviews, or why customers switch solutions.
</objective>

<quick_start>
# Quick Start

**Trigger:** `analyze [company/product/market] using JTBD`

**Sales Mode** (discovery calls, prospect research):
1. Define the core functional job the prospect is hiring for
2. Map Forces of Progress (what's pushing them to switch?)
3. Generate Switch Interview questions for discovery calls
4. Frame your value prop as outcome statements

**Strategy Mode** (market analysis, product innovation):
1. Write the Job Statement
2. Build the Job Map (8 steps)
3. Generate 15-30 Outcome Statements
4. Score Importance vs Satisfaction (ODI algorithm)
5. Identify top underserved outcomes
6. Analyze Hiring/Firing competitive landscape

**Example:** `Analyze video conferencing for hybrid enterprise teams using JTBD`
</quick_start>

<core_concepts>
# Core Concepts

## What Is a Job?

A job is the progress a person is trying to make in a particular circumstance. Jobs are:
- **Stable over time** — the job of "getting informed about breaking news" hasn't changed in 200 years; only solutions change
- **Solution-agnostic** — no technologies, products, or methods in the job statement
- **Functional + emotional + social** — every job has all three dimensions

## The 3 Types of Jobs

| Type | Definition | Example |
|------|-----------|---------|
| **Functional** | The practical task to accomplish | "Reduce downtime during live broadcasts" |
| **Emotional** | How the person wants to feel | "Feel confident the stream won't fail mid-event" |
| **Social** | How the person wants to be perceived | "Be seen as a technically competent production team" |

## Critical Distinctions

| Concept | Definition | Example | Problem If Confused |
|---------|-----------|---------|-------------------|
| **Job** | Progress in a circumstance | "Monitor remote classroom quality" | — |
| **Need** | Contextual desire | "I need a faster encoder" | Embeds solution bias |
| **User Story** | Dev requirement | "As a user, I want alerts" | Specifies implementation |
| **Feature** | Product capability | "4K encoding at 60fps" | Describes your product, not their progress |

**The test:** If it mentions your product, a technology, or a specific method, it's NOT a job — it's a solution. Rewrite until it's solution-agnostic.
</core_concepts>

<job_statement>
# Job Statement

## Formula

```
[When ___], [I want to ___], [so I can ___]
```

- **When:** The triggering circumstance (not a persona)
- **I want to:** The functional job (solution-agnostic verb + object)
- **So I can:** The higher purpose / desired outcome

## Rules for Good Job Statements

1. No technologies, products, or brand names
2. Stable for 10+ years (if the job existed in 2010, it should read the same)
3. One core job per statement (decompose complex jobs)
4. Use active verbs: capture, deliver, ensure, coordinate, monitor

## Examples

| Domain | Job Statement |
|--------|--------------|
| Video production | When producing a live event with remote participants, I want to ensure consistent video/audio quality across all sources, so I can deliver a professional broadcast without technical disruptions |
| Sales enablement | When preparing for a discovery call with a new prospect, I want to quickly understand their current situation and pain points, so I can ask relevant questions that uncover their real needs |
| IT operations | When a critical system shows degraded performance, I want to identify the root cause and affected scope, so I can restore service before users are significantly impacted |
</job_statement>

<job_map>
# Job Map — 8 Universal Steps

Every job follows these 8 steps. Use them to structure discovery calls and identify outcome opportunities at each stage.

| Step | Definition | Discovery Question |
|------|-----------|-------------------|
| **1. Define** | Determine goals, plan approach, assess resources | "How do you decide what success looks like for [job]?" |
| **2. Locate** | Find the inputs and information needed | "Where do you go to find the [information/materials] you need?" |
| **3. Prepare** | Set up the environment, organize inputs | "What setup or preparation do you do before [executing the job]?" |
| **4. Confirm** | Verify readiness before execution | "How do you confirm everything is ready before you begin?" |
| **5. Execute** | Perform the core job activity | "Walk me through how you actually do [the job] today." |
| **6. Monitor** | Track whether the job is going well | "How do you know if things are going well or going wrong during [the job]?" |
| **7. Modify** | Make adjustments when things change | "When something goes wrong mid-[job], what do you do to correct it?" |
| **8. Conclude** | Finish, clean up, evaluate results | "How do you wrap up? How do you know if [the job] was done well?" |

**Sales application:** Walk prospects through steps 1-8 during discovery. Each step where they describe friction, workarounds, or pain is an opportunity signal.

**Strategy application:** Generate 2-4 outcome statements per step to build a comprehensive outcome set (15-30 total outcomes).
</job_map>

<outcome_statements>
# Outcome Statements

## Formula

```
[Direction] + [metric] + [object of control]
```

**Directions:** Minimize, Reduce, Increase, Maximize, Decrease, Eliminate

## Rules
- Must be measurable (contains a metric: time, likelihood, number, amount)
- Must be controllable (something the user can influence)
- Must be solution-agnostic (no product references)

## Examples

| Job Map Step | Outcome Statement | Imp | Sat |
|-------------|-------------------|-----|-----|
| Locate | Minimize the time it takes to identify the right input sources | 9 | 4 |
| Prepare | Reduce the likelihood of missing a required setup step | 8 | 5 |
| Execute | Minimize the number of manual adjustments needed during execution | 9 | 3 |
| Monitor | Increase the ability to detect problems before they affect output | 10 | 4 |
| Conclude | Minimize the time it takes to verify the job was completed correctly | 7 | 6 |

**Imp** = Importance (1-10), **Sat** = Satisfaction with current solution (1-10)

## Common Mistakes

| Mistake | Bad Example | Fixed |
|---------|------------|-------|
| Too vague | "Make it easier" | "Minimize the number of steps to configure input sources" |
| Solution-embedded | "Reduce time switching between Zoom and OBS" | "Minimize the time switching between source views" |
| Not measurable | "Improve the monitoring experience" | "Increase the likelihood of detecting quality drops within 5 seconds" |
</outcome_statements>

<forces_of_progress>
# Forces of Progress

When a customer switches solutions, four forces are at play. Two drive change, two resist it.

```
  DRIVING CHANGE                    RESISTING CHANGE
  ─────────────                     ────────────────
  ┌─────────────────┐               ┌─────────────────┐
  │  PUSH            │               │  ANXIETY          │
  │  Current pain    │──────────────▶│  Fear of new      │
  │  "This is broken"│