Review
Most lean books tell you to talk to customers and iterate, which is true and completely unactionable. Olsen is the one who bothered to write down the steps.
The spine of the book is a layered model of product-market fit. You start with who you're for, then what they need that nobody serves well, then what you'll promise, then what you'll build, and only then how it looks and feels. Each layer rests on the one below it. The value is that when something isn't working, the model tells you which layer to go back to instead of leaving you to redesign the interface and hope.
It's the least inspiring of the lean books and the most useful. Ries makes you want to change how you work; Olsen tells you what to do on Tuesday. I've used the importance-versus-satisfaction framing more than anything else in it, because it kills the argument that every request is equally urgent.
The writing is functional rather than good, and the case study running through it goes on longer than it needs to. Read it if you've absorbed the lean philosophy and want the method underneath.
Key Takeaways
The parts worth keeping:
Product-market fit is a stack, not a feeling
- The layers run from the customer outward: who you serve, which of their needs are underserved, what you promise, what you build, and how it feels to use. Problems at a lower layer cannot be fixed at a higher one.
- Most teams work top-down, starting from the interface, because it's the only layer they can see. That's why redesigns so often change nothing.
- When a product stalls, the useful question is which layer is wrong, not which feature is missing.
Importance versus satisfaction
The single most practical idea in the book: score needs on two axes rather than one.
| Importance | Satisfaction | What it means for you |
|---|---|---|
| High | Low | The opportunity. Underserved and it matters. |
| High | High | Table stakes. You must be good, but it wins nothing. |
| Low | Low | Ignore it, whatever the request volume says. |
| Low | High | Over-served. You are probably spending too much here. |
- A backlog sorted by request count is sorted by who complains loudest. This is the correction.
Not all satisfaction is linear
- Some features earn goodwill in proportion to how well you do them. Some are pure hygiene, invisible when present and fatal when absent. A few delight precisely because nobody expected them.
- Delighters decay. What thrills users this year becomes an expectation the next, so a product that stops adding them slowly slides back to merely adequate.
Testing before building
- Define the smallest thing that tests the hypothesis, not the smallest thing you could ship. Those are different, and the second one is how MVPs get bloated.
- Watch people use it rather than asking whether they like it. The gap between the two is where most false positives live.
- Iterate on the layer that failed. If the value proposition is wrong, another round of usability testing will produce a beautifully usable product nobody wants.