Systems Playbook

Inspired: How to Create Tech Products Customers Love (Marty Cagan)

Main Argument

Great products come from empowered, cross-functional teams that are given problems to solve rather than features to build, and that run continuous product discovery to decide what is worth building before engineering builds it. The core distinction is discovery versus delivery: delivery makes sure you build the thing well, but discovery makes sure you build the right thing at all, by cheaply testing the risks that actually sink products. For the playbook, Inspired is the product-domain statement of the thesis: when execution is cheap, the scarce work is figuring out what to build and establishing that it will work.

Key Takeaways

  • Discovery and delivery are parallel tracks, not phases: discovery answers "is this worth building?" while delivery answers "can we build it well?", and the two run continuously.
  • Every idea faces four risks that discovery must retire: value (will they use or buy it?), usability (can they use it?), feasibility (can we build it?), and business viability (does it work for the business?). Teams over-focus on feasibility and get blindsided by value and viability.
  • Empowered teams are given outcomes and the autonomy to find solutions, not feature roadmaps to deliver; Cagan frames them as missionaries, who believe in the goal, rather than mercenaries.
  • Measure outcomes, not output: success is the business and customer result, not the number of features shipped.
  • Prototypes are the engine of discovery: build something deliberately cheap and disposable to test a specific risk before committing real engineering, choosing the lowest fidelity that answers the question.
  • A strong product vision is the north star that aligns empowered teams without dictating their moves and sustains them through setbacks.
  • The riskiest, most valuable work is deciding what to build; building it well is necessary but no longer where products are won or lost.

Concepts Extracted

Enriched