Review
Inspired is the Product Management bible for a reason. Cagan lays out the role, the common techniques, and just as importantly, what a strong product culture actually looks like day to day. His preferred move is to contrast a good team against a bad one, which teaches the lesson clearly but can tip into pessimism if you read too much of it in one sitting.
Published in 2008, it should feel dated by now. It doesn't. What's actually surprising is how many companies are still running into the exact problems this book diagnosed over fifteen years ago.
One caution: reading this book is the start of the job, not the end of it. Understanding the theory is not the same as being able to run a discovery process. That comes from practice.
Key Takeaways
The parts worth keeping:
- Most failed products trace back to a waterfall process bolted onto agile delivery: idea, business case, roadmap, requirements, design, build, test, deploy. Customer validation happens too late to matter, and the roadmap that results is a list of outputs, not outcomes.
- Two inconvenient truths about product work: at least half of your ideas will not work, and the ones that do will take several iterations to get right. Plan for both.
- Three principles that move you past lean and agile: tackle risk up front rather than at the end, design product collaboratively rather than sequentially, and organize around problems and outcomes rather than features.
- Discovery and delivery run in parallel. Discovery (product plus design) tackles risk before code gets written and produces a validated backlog. Delivery (engineering plus product plus design) turns validated ideas into something you can actually run a business on.
- Four questions every idea has to answer: will the customer use it, can they figure out how, can engineering build it, and will the business support it? That is value, usability, feasibility, and viability risk.
- Strong product teams are missionaries, not mercenaries. Ten principles worth remembering: 8-12 engineers plus product and design, empowered with objectives rather than told what to build, no dedicated managers inside the team, co-located, durable rather than reformed per project, and given real autonomy over how they solve the problem.
- A product manager needs deep knowledge in four areas: the customer, the data, the business, and the market. When the product fails, it is the product manager's fault. When it succeeds, the whole team did it.
- Roadmaps built around dates and features run straight into the two inconvenient truths above. Replace them with outcome-based roadmaps: business objectives the team owns, plus the occasional high-integrity commitment made only after discovery has actually de-risked it.
- Product vision is a two-to-five-year narrative, not a spec. Its job is to inspire the team, not describe the solution. Product strategy is what makes the vision concrete: a sequence of product or market fits, usually one target market or persona at a time.
- OKRs connect the two: qualitative objectives, quantitative key results, cadenced annually for the company and quarterly for teams, kept few enough that people can actually track them.
- Ten core discovery principles boil down to one idea: customers cannot tell you what to build, so validate with real users, as fast and cheaply as possible, and check feasibility and business viability during discovery, not after.
- Prototypes exist to learn with a tenth of the effort of building the real thing. Match the fidelity to the question you are actually trying to answer, not to how finished it looks.
- Stakeholders are whoever can veto your launch. Win them over by understanding their constraints before you show them a solution, sharing what you learn generously, and bringing evidence instead of opinions when you disagree.
- Product culture shows up in the details: engineers involved in discovery, teams that stay together long enough to build trust, continuous release cycles, and celebrating outcomes achieved rather than features shipped.
Ten principles of a good product vision
- Start with why: articulate the purpose, everything else follows from it
- Fall in love with the problem, not the solution
- Think big
- Disrupt yourself before somebody else does
- Make it exciting and inspirational, not a spec
- Embrace the trends that are actually relevant to your business
- Skate to where the puck is heading, not where it is
- Be stubborn on the vision, flexible on the details
- Know it is a leap of faith, not a guarantee
- Evangelize it continuously and relentlessly
Four kinds of prototype
| Type | What it tests |
| Feasibility prototype | Can engineering actually build this, and roughly how |
| User prototype | Can a real user understand and use it (the classic clickable mockup) |
| Live-data prototype | Does it hold up against real production data, not sample data |
| Hybrid prototype | A combination, used when a single type of risk isn't the only one in question |
Cagan's line on why prototypes matter at all is worth keeping: they let you learn with roughly a tenth of the time and effort of building the finished product, and Fred Brooks' old warning still applies, plan to throw one away, you will anyhow.
What separates strong product culture from a stalled one
| Innovation multipliers | Velocity sappers |
| Customer-centric culture | Technical debt left unaddressed |
| Compelling, focused product vision and strategy | No product vision or strategy at all |
| Strong, empowered product managers | Weak product management, no real ownership |
| Stable, co-located, durable teams | Teams reformed project to project |
| Engineers involved early in discovery | Engineers only brought in at delivery |
| Corporate courage to make hard calls | Consensus culture that avoids them |