Feature roadmap
- Q3 ships: A, B, C, D
- Owner: engineering velocity
- Success = shipped on time
- PM = backlog manager
- Customer contact: ad-hoc
Pain · also: Product
Inspired
by Marty Cagan
Source book · ~5h read
“If you don't know how to discover, you're going to discover with your customers — and that's expensive.”
Pairing
Why this book, in this stage
Inspired is paired with the Pain stage — fall in love with the problem, not the solution. It also speaks to Product.
The argument
Central thesis
Marty Cagan argues that most products fail not because they're badly built, but because nobody figured out whether they should be built. The job of a product team isn't to ship features from a roadmap. It's to discover what's actually valuable, usable, feasible, and viable — then build that. Discovery and delivery are two different disciplines; treating them as one is the root cause of most product failure.
At a glance
Two ways to plan a quarter
Outcome roadmap
- Q3 outcome: activation +20%
- Owner: product team
- Success = outcome moved
- PM = problem owner
- Customer contact: 2–3/week
The hook
The founder problem this book solves
Most product roadmaps are wishlists pretending to be plans.
Founders default to delivery. There's a backlog, you ship it, the business grows. Cagan's insight is that delivery without discovery is a guessing game with expensive consequences. The cost of building the wrong thing isn't the time you spent building it — it's the time you didn't spend building the right thing.
For first-time founders, this book is a vaccine. Without it, you'll spend year one shipping features that don't move metrics, then convince yourself the problem is execution. With it, you'll spend two weeks of every cycle in discovery — talking to customers, prototyping, killing bad ideas before they cost anything — and the rest in confident delivery. The shape of your roadmap changes; the shape of your runway changes.
5 takeaways
What to remember
01 / 05 — Discovery ≠ delivery
Discovery answers: should we build this? Delivery answers: how do we build it well? Most teams skip the first one and pay for it forever.
Use ← → keys, or swipe on mobile
Practice CardOne-screen exercise
The Four-Risk Test
Pick the next feature on your roadmap. Now answer four questions in writing — not in a meeting, on paper:
1. Valuable — who specifically wants this enough to pay for it or change behavior for it? Name them. If you can't name three, you don't know.
2. Usable — can they figure it out without explanation? When did you last watch one try?
3. Feasible — can your engineers build it in the time you've estimated? Have they actually estimated it?
4. Viable — does this make business sense (pricing, distribution, support, legal) for your model and stage?
If any answer is hand-wavy, that's the riskiest assumption, and you need a discovery experiment for it before you write a line of code. The cost of a one-week discovery experiment is always less than the cost of building the wrong thing for six weeks.
Read
Get the book
Share