Jobs To Be Done
What progress is someone trying to make, and where does friction stop them?
You don't need another framework. You need to know: does anyone actually have this problem badly enough to pay for a solution?
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
- Agency — Demand validation discovers what agents (human and phygital) struggle to do
- Ventures — Validated demand becomes a venture experiment
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)?