Cagan on product discovery
📚SOURCE
💎PERMANENT NOTES
🧵SYNTHESIS
Paraphrase, not quotation: the sections of 📕 Inspired on process and discovery, second edition.
Cagan's starting fact is that most product ideas do not work: about half fail outright, and the ones that succeed take several attempts to get right. The usual way of working hides this until the end. A roadmap of features is agreed, built in order, and tested against customers only once it has shipped, when being wrong is as expensive as it can be.
His alternative is to split the work. Discovery finds out, quickly and cheaply, whether something is worth building. Delivery builds it properly. Discovery has to settle four risks before delivery starts: value (will customers choose it), usability (can they work out how to use it), feasibility (can we build it with what we have), and viability (does it work for the rest of the business: sales, support, legal, money).
The instrument is the prototype, which is anything that answers one of those questions for a fraction of the cost of the product.
✨KEY IDEAS
Roughly half of the ideas on any roadmap will not deliver what was hoped, and the rest need iteration.
The four risks are value, usability, feasibility and business viability, and all four are discovery's job.
Engineers should be in discovery from the start, because they know what has recently become possible.
A prototype exists to learn something specific, and should cost a small fraction of building the real thing.
For a business product, win a small set of reference customers who are truly using and paying before calling it launched.
📝READING NOTES
Why I re-read it now
The launch project closed on Friday. I first read Inspired in 2020, underlined it heavily, and built the Exceptions Inbox more or less the way it says not to. So this is an audit. For each of his four risks: did I address it before building, and with what?
The audit
| Risk | His question | What I did | Honest verdict |
|---|---|---|---|
| Value | Will they choose to use it? | Kestrel pilot from October | Partly. One customer, and Rafael told me in January the list was too long to be useful. I logged it as feedback. |
| Usability | Can they figure it out? | Tomasz's designs, tried on the pilot | Mostly. This is the one we did best. |
| Feasibility | Can we build and run it? | A load test, seven days before the date | No. It failed at a third of expected volume. |
| Viability | Does it work for the business? | Sales had sold the date | Assumed. Support training came late. |
One and a half out of four. See 📂 Exceptions Inbox general availability for what that cost.
What he says, underneath the audit
- Discovery and delivery are different work with different standards. Discovery wants speed and tolerates rubbish. Delivery wants reliability.
- The team owns a problem, not a list. He wants product, design and engineering deciding together what to build, and being held to an outcome.
- Test the riskiest thing first. Not the thing that is easiest to test.
The skill note is ♦️ Product discovery. On this evidence the score there is generous.
Where the book and my job part ways
Cagan's examples come from the best product companies he has known, told from the inside by the people who won. There is no chapter on what to do when the date was sold before the discovery started, which is a normal Tuesday in business software. He would say that is the organisation's failure and he would be right, and I would still have a date. The book is a description of good conditions more than a method for bad ones.
It is also thin on evidence. About half of ideas fail is his experience, stated as a rate. I believe it. Hale would ask for the denominator.
What I am keeping
- Feasibility is a discovery risk. A load test in week one, at a volume Nadia chooses.
- One pilot customer is an anecdote. I need more than one before I call anything proven.
- Small and finished. The pilot taught us more in a month than the specification had in six. The 400-word issue after launch night was short, finished and sent, which is more than the long draft it replaced.
What it produced
- 💎 A finished small thing teaches more than an unfinished large one
- 💎 Discovery is cheaper than delivery so do more of it
Both written today, between sets of revision at the library with Rasmus.
Added 8 September: Carrier Scorecards starts today as discovery, with no delivery date attached. First time I have been allowed to do it in the right order. Torres next.
Related notes
- ♦️ Product discovery
- 📂 Exceptions Inbox general availability
- 📖 Torres on opportunity trees
Reading record
- Times read: twice
🗣️IN SHORT
- In : Inspired (second edition), the parts on product process and discovery
- Cagan argues that : because most ideas fail, a team should find out cheaply whether an idea is worth building before it commits to building it well
- by stating that : value, usability, feasibility and business viability can each be tested with prototypes at a fraction of delivery cost, by a team that includes engineering and design from the start