Jobs To Be Done
What progress is someone trying to make, and where does friction stop them?
You don't invent demand. You discover it by watching what people do, not what they say. The gap between their current situation and their desired outcome — that's the job. The friction in that gap — that's your opportunity.
The Framework
| Question | What It Reveals |
|---|---|
| What are they struggling with? | The job |
| What are they using now instead? | The competition (always something) |
| What would make them switch? | The trigger |
| What almost stops them? | The hidden objection |
| What does progress look like to them? | The outcome you're selling |
People don't buy products. They hire solutions to make progress. Understand the job, and the product designs itself.
Dig Deeper
- Validate Demand — Step 1: prove people have this pain before writing a single spec. Awareness levels, intent signals, interview method
- Create PRD Stories — Step 2: spec the capability with Intent + Story + Build contracts. Stories are test contracts, not documentation
- Prioritize PRDs — Step 3: score with the 5P algorithm, sort the build queue. Table order = build order
The Pattern
Jobs x Attributes. One row per job. Columns are what you need to know.
This pattern applies everywhere:
- Marketing Protocols — 25 marketing jobs mapped
- Work Charts — Human/AI capability per job
- Business Development — From job discovery to venture creation
The Pipeline
Five steps from friction to proven capability. Each step's output is the next step's input. Steps 1-3 are Dream Team's domain — defining what creates value. Step 4 is engineering's domain — deciding how to build it. Step 5 is Dream Team again — verifying engineering delivered what was specified. The commissioner is never the builder.
| Step | Page | Input | Output | Shared Artifact |
|---|---|---|---|---|
| 1. Discover | Validate Demand | Observed friction | Demand Evidence Card | — |
| 2. Spec | Create PRD Stories | Demand Evidence Card | Intent Contract + Story Contract + Build Contract | — |
| 3. Rank | Prioritize PRDs | Scored PRDs | Sorted build order | — |
| 3→4. Handoff | PRD Handoff | Story Contract rows | SPEC-MAP columns 1-2 (Dream fills Story #, WHEN/THEN) | SPEC-MAP |
| 4. Build | Dev Workflow | SPEC-MAP + Story Contract | Deployed capabilities + SPEC-MAP columns 3-4 (Engineering fills Test File, Test Status) | SPEC-MAP |
| 5. Commission | Validate Outcomes | Deployed capabilities + SPEC-MAP | L0-L4 evidence + SPEC-MAP columns 5-6 (Dream fills L-Level, Last Verified) | SPEC-MAP |
Stories are the atomic unit. The SPEC-MAP traces each story from spec through test to commissioning — both sides write to it, neither side can claim done with empty cells. The flow engineering bridge turns stories into maps, maps into types, types into code.
Context
- Validate Demand — Awareness levels, intent signals, interview method
- Create PRD Stories — Spec capabilities with Feature/Function/Outcome tables
- Prioritize PRDs — Scoring algorithm, rubrics, gates, build order
- Validate Outcomes — L0-L4 commissioning, validate standards and results
- Behavioural Economics — Why people do what they do
- Advertising Industry — JTBD applied to SME vs enterprise buyer jobs
- Flow Engineering — Stories become maps become code
- Validate a Great Idea — Demand validation thesis applied to ventures
Questions
What progress is someone trying to make — and where in the pipeline does your understanding of it break down?
- At which step does the signal from the original pain get lost — discovery, spec, ranking, or commissioning?
- When a PRD story (Feature/Function/Outcome) doesn't map cleanly to a commissioning check, is the story wrong or the check?
- What's the cost of skipping step 1 (validate demand) and jumping straight to step 2 (create stories)?