There is a version of product development that most organisations practice: stakeholders submit requests, prioritisation happens, a roadmap is assembled, engineers deliver, and the result is whatever falls out of that process. And then there is the version that the companies who consistently produce products people love practice. The gap between the two is what Inspired is about.
Marty Cagan spent decades at the best technology companies in the world - eBay, HP, Netscape - and then studied dozens more as a partner at Silicon Valley Product Group. Inspired is the synthesis of that experience: a ground-level account of how the best product organisations actually work, why most product organisations are structurally incapable of replicating them, and what it takes to close the gap.
This is the book that shaped a generation of product managers - and it is equally important for engineering leaders, because the product team model it describes only works when engineering is a genuine partner in discovery, not just a delivery function.
The vast majority of ideas built by technology teams fail. Not because the teams are bad at building - but because the ideas were not validated before significant investment was made. Inspired exists to address this problem at its root: not by improving delivery, but by improving discovery.
Cagan's thesis is that the best product teams solve the four risks - value risk, usability risk, feasibility risk, and viability risk - before committing to build. They work continuously with customers and data to understand what is worth building, test it quickly and cheaply before investing in production code, and move into delivery with genuine confidence that they are building something that will work. The contrast with organisations that define requirements upfront, build for months, and discover at launch that they were wrong is the central narrative of the book.
The most damaging structural mistake in product organisations is treating discovery as something that happens before delivery - a requirements phase, a design phase, a research phase - after which the team transitions into execution mode. Cagan's model treats discovery as continuous and parallel to delivery.
Discovery is the ongoing work of answering the question: what should we build? Delivery is the ongoing work of building it well. Both are always happening. The teams that separate them - finishing discovery before starting delivery - are introducing a lag between learning and action that compounds into waste. The teams that run them in parallel can incorporate what they learn into what they build on a much shorter cycle.
One of Cagan's strongest arguments - and one that requires the most change in most organisations - is that engineers need to be actively involved in the discovery process, not just handed the results of it.
Engineers who participate in customer research develop product intuition. They understand the customer context behind the technical decisions they make. They can contribute insights about technical feasibility that change the direction of discovery. And they develop genuine ownership of the product outcomes - because they have been involved in the thinking, not just the building.
Organisations that treat engineers as a delivery resource - handed designs and requirements, measured on output - are wasting the most valuable thinking in the room. The best product teams are not product-led or engineering-led. They are genuinely collaborative at the level of problem definition.
Before committing to build anything, a product team needs to be confident they have addressed four questions. Is this something customers actually want and will use? (Value risk.) Can the customer figure out how to use it? (Usability risk.) Can we actually build it with current technology and skills? (Feasibility risk.) Does it work for the business - commercially, legally, operationally? (Viability risk.)
Most organisations address only one of these risks systematically - feasibility, because engineers are part of the process and technical constraints surface naturally. The other three are addressed, if at all, through intuition and experience. The teams that address all four explicitly, through prototyping, research, and business analysis, produce dramatically lower rates of product failure.
A prototype is not a design mockup waiting for approval. It is a hypothesis made testable. The goal of a prototype is to answer a specific question about value, usability, or feasibility - as cheaply and quickly as possible. The best prototypes are the ones that answer the question without building anything that needs to be maintained.
Cagan describes a range of prototyping approaches - from paper sketches to interactive mocks to live-data prototypes - and the appropriate context for each. The discipline is choosing the right fidelity for the question being asked, and resisting the temptation to build a complete prototype when a cheaper one would answer the question just as well.
The final argument in Inspired is that all the process and practice in the world cannot compensate for the absence of a compelling product vision and the trust necessary for product teams to take real responsibility for outcomes.
A compelling product vision is not a statement of aspiration. It is a vivid, concrete picture of the future state the product is working toward - specific enough that a team can evaluate any individual decision against it. And trust is the organisational condition that allows product teams to make decisions in service of that vision without requiring approval at every turn. Both require active, deliberate investment from product and engineering leadership.
If your product managers spend most of their time managing the backlog and writing requirements, they are not doing product management - they are doing project management in a different role. The distinction matters for what kind of talent you attract and retain.
The most expensive decision your product organisation makes is committing to build something before validating that it is worth building. How much of your current backlog has been genuinely validated against the four risks?
Engineers who are involved in customer discovery make better technical decisions. Not occasionally, and not marginally - systematically and significantly. The cost of including engineers in research is small. The cost of excluding them accumulates in every design decision made without their context.
Feature roadmaps are contracts that commit to solutions rather than problems. A team given a feature to build cannot discover that the feature is the wrong solution. Only a team given a problem to solve can make that discovery.
The best product teams are not defined by their methodology. They are defined by a deep commitment to understanding the customer, a willingness to be wrong, and the discipline to test before they build.
Audit your last quarter's shipped features against the four risks. For each, ask: how did we validate that customers would use it, could use it, that we could build it, and that it worked for the business? Where are the gaps?
Get your engineers into a customer conversation this month. Even one session. Ask them afterwards what they learned that changed their understanding of the problem. The answer will make the case for doing it more often.
Identify your most impactful feature currently in discovery. Run a structured test against value and usability risk before committing to build. Prototype, test, learn. Then decide.
Write your product vision. Not the mission statement - the specific, vivid picture of the future state your product is trying to create for customers. Make it concrete enough to evaluate decisions against it.
Measure your discovery failure rate. Of the features shipped in the last year, how many achieved their intended outcome? If you cannot answer this question, you have a measurement gap - and without measurement, discovery cannot improve.
"The best teams I've ever observed have one thing in common: they are trying to discover the right product to build, not just how to build the product they were told to build."
- Marty Cagan