Review
I came to this after Ulwick, and it answers the complaint I had about him. Ulwick makes the theoretical case for jobs to be done at length; Kalbach assumes you're already convinced and shows you how to run it on a Tuesday.
The book is organised as a set of exercises rather than an argument, which makes it a poor read and an excellent reference. I've used the job map structure directly, and it does what good frameworks do: it makes the gaps in your understanding visible without requiring you to already know the answer.
The forces of progress model is the other part that earned its place. Understanding that a customer is pushed by their situation and pulled by a new option, while simultaneously held back by anxiety and inertia, explains more failed launches than any amount of feature comparison.
Read it if you're running discovery and want templates you can put in front of a team tomorrow. If you want to be persuaded that jobs to be done is worth adopting at all, this is the wrong book and Ulwick is the right one.
Key Takeaways
The parts worth keeping:
Define the job before anything else
- A job is the progress someone is trying to make in a situation, stated without reference to your product. If your solution appears in the job statement, you've written a feature request.
- The right level of abstraction is the hard part. Too narrow and you've described your current product; too broad and it applies to everything and guides nothing.
- Jobs are stable over time. Solutions aren't. That's what makes the job a safer thing to organise around.
The job map
Breaking a job into stages exposes where the pain actually sits, which is frequently nowhere near the step your product addresses.
| Stage | What the person is doing |
|---|---|
| Define | Working out what they need and what success looks like |
| Locate | Gathering the inputs, information or people required |
| Prepare | Setting things up so the work can happen |
| Confirm | Checking they're ready and have made the right choice |
| Execute | Doing the thing itself |
| Monitor | Watching whether it's going as expected |
| Conclude | Finishing, tidying up, and deciding whether it worked |
- Map the whole job even where you have no product. The unserved stages are the opportunity.
The forces that decide whether anyone switches
- Push: the current situation is bad enough to create pressure to change.
- Pull: the new option looks like it would be better.
- Anxiety: worry about whether the new thing will actually work.
- Habit: the pure inertia of what's already in place.
- Most teams work exclusively on pull, making the new thing more attractive, and ignore the two forces holding people still. Reducing anxiety usually moves more people than adding another feature.
Turning jobs into decisions
- Rate each step of the job by how important it is and how badly it's served today. The gap between those two is where to work.
- A job that's important and already well served isn't an opportunity, however central it looks on the map.