I heard about INSPIRED from a former colleague. He said that his Product Team was using it as a guide to help them correct some of their bad practices.
To that end, this book was a good choice. It is the second edition to Marty Cagan’s first book with nearly the same title published 10 years earlier. The second edition is a complete rewrite of the first, with an additional section about “Product @ Scale.”
The book covers a lot of material. It is broken up into 5 parts and 67 chapters over 349 pages. That is to say that Mr. Cagan does not get into a lot of detail. The book is a survey of what great product teams do right, what many teams do wrong and layouts out a blueprint for being more efficient and creating better products.
Images: Table of Contents from INSPIRED: How to Create Tech Products Customers Love, by Marty Cagan, 2nd Edition
The book starts at a basic level, defining company growth stages (Startups, Growth Stage, and Enterprise), the root causes of failed products, and which roles should be represented in a well-functioning product team.
The real meat of the book comes after the first 100 pages in parts III and IV.
In Part III, Marty tackles the pitfalls of product roadmaps. In that section, Marty lays out that roadmaps traditionally serve two functions:
- They convey to management that the product team is “working on the highest-value things first.” (page 109)
- They help management plan related activities like marketing campaigns, hiring, partner enablement, etc.
But roadmaps often fail to serve their function because they ignore two “inconvenient truths.”
- “at least half of our product ideas are just not going to work.” (page 111)
- “even with the ideas that do prove to be valuable, usable, feasible, and viable, it typically takes several iterations to get the execution of this idea to the point where it delivers the expected business value that management was hoping for.” (page 112)
INSPIRED does a great job exploring the tension between roadmaps and product delivery. It also proposes an alternative called an “outcome-based roadmaps.”
Outcome-based roadmaps are predicated on delivering business results instead of product ideas. To do this, product teams need two inputs: product vision and strategy, and a full understanding of the key business objectives at hand.
The product team is then responsible for obtaining the business objectives within the scope of the vision and strategy.
I agree with the idea of outcome-based roadmaps. I definitely see the benefits. And to Marty’s credit he acknowledges the undeniable need for some date-based commitments. He refers to these as “High-Integrity Commitments,” and he discusses at relative length how to properly handle them.
“Part IV: The Right Process” is the other major section of this book. I would argue it is also the most important section, yet most difficult to understand.
That said, Marty is onto something. Over 31 chapters, he outlines a process and set of techniques for everything from discovery and planning to prototyping and testing. He covers a lot of material, and in some cases provides book recommendations in case the reader wants to learn more on a given subject.
I do have a word of caution about this book. In general, Marty’s writing style does the book a disservice. This is no more apparent than in Part IV. I often found myself agreeing with Marty’s points, yet still unable to remember what it was that I reading.
It is a combination of wordiness and chapter organization that caused my confusion. This problem comes to a head in Part IV. While the 31 chapters are interrelated, they do not build upon each other in a way that is helpful to the reader.
Midway through Part IV, I felt my frustration building. I decided to skim the chapters for salient points and write my own chapter summaries to ensure I understood the points being made and how the chapters related to each other.
Perhaps that is my most damning critique and highest praise. The content is valuable enough to warrant extra care to read and understand, but so poorly conveyed that I had to rewrite it in order to remember it.
That is not to say that I did not like the book. In fact, I did. And I would recommend it for anyone new to product management or is looking for new ideas to improve their own product development processes. It will not be a reference book with answers to your endless questions, but it will serve as a good jumping off point and send you in the right direction.
If you are interested in purchasing INSPIRED, by Marty Cagan, it is widely available in brick and mortar bookstores. Your local library is a good option too! If you are averse to both of those options, below are some links: (I do not receive any money when you click on the links or buy the book.)
Bonus Section: Marty Cagan did an interview on the podcast, “This is Product Management.” It is worth listening too.
If you found this book review helpful, please share it with a friend or colleague.