Summary

Inspired is a comprehensive overview of how to build product teams and the systems and mindsets that make for the most innovative cultures of shipping great products. For years, author Marty Cagan has written on these topics on the Silicon Valley Product Group blog — sharp and insightful essays on topics ranging from how to conduct discovery interviews, the role of design, the lines between product management and engineering, go-to-market testing, and tons more. This book is largely an assembled collection of those essays.

While there’s a ton of substance here in terms of tactical systems, my favorite parts cover the systems-level root causes of common problems that anyone working in product very long has certainly encountered. If you’ve read any of the other common works in the startup canon, like The Lean Startup, Zero to One, or even Shape Up, much of the material will be familiar. But unlike those, Inspired looks at product building through the lens of the ground level product manager or tech lead, rather than a company founder level. There’s plenty of higher level material here, but it’s unique in bringing so many specific tools that product managers can deploy to get faster validation, time to market, and more satisfied teams.

Key Takeaways

• Products are all about outcome — if you’re measuring output, you’re doing a series of projects, not product
• The “holistic view of product” is much wider than mosts teams appreciate or account for, covering the following factors (not just “features”)
  • Functionality: features
  • Technology: enables functionality
  • UX Design: presents functionality
  • Monetization: making money from functionality
  • How we acquire users and customers to monetize
  • Can include offline experiences (things that happen outside of your technology, e.g. product refund experience)”
• While not explicitly mentioned by name, Cagan refers heavily to the concept of Jobs Theory in his idealized process for discovery and “falling in love with problems, not solutions”
• Agile methodologies have spread through the tech universe, but most teams aren’t truly agile from a holistic level on product
• Risks should be addressed and understood up front, which means the smaller the iterative bite can be, the sooner you can have these questions answered; large “Big Bang” efforts shove lots of risk pretty far down in the cycle
  • Value risk — whether customers will buy
  • Usability risk — whether users can figure out how to use
  • Feasibility risk — whether our engineers can build what we need with the time, skills, tech available
  • Viability risk — whether solution also works for business; sales, marketing, finance, legal
• Functions like design and engineering should be involved much earlier in the product development process, even all the way back in the discovery stage as you’re talking with customers to map out the problems you’re looking to solve