Inspired - critical summary review

Widely considered one of the best books on product management ever written, “Inspired” by Marty Cagan, the founder of the Silicon Valley Product Group, was first published long before Agile was well established in product companies and even longer before Customer Development and Lean Startup nomenclature became popularized. Since most teams nowadays use these techniques, Cagan decided to update the first edition of “Inspired” in 2017 to reflect the changes in the tech world. 

Even though he had planned to modify no more than 20% of the original content, he ended up rewriting the entire book – in his words, not because he regretted what he had written in 2007, but because he felt that there were much better ways of explaining the topics originally covered by the book. Indeed, the second edition of “Inspired” reads a lot better than the first one and – partly due to Cagan’s more in-depth familiarity with his subject and partly due to improved techniques – it feels like it covers a lot more substantial ground. 

Allow us to focus on just a few essentials from the first part and get ready to learn some of the key lessons from top tech companies while discovering the main concepts that form the foundation of modern product work!

The root causes of failed product efforts

Nine out of 10 product releases fail. The reasons are many, but if they can be summed up in two words, “waterfall processes” should do just fine. Namely, according to Cagan, the old waterfall model – in which there is no overlapping of phases, as each phase must be completed before the next phase can begin – is outdated and, moreover, incompatible with the modern tech industry. In fact, he implies, when it was first adopted for software development decades ago, it was merely in the absence of alternatives, not because people believed it worked. 

In the waterfall model, everything starts with ideas, which can come from inside or outside, that is to say, either from executives, owners and stakeholders or from prospective customers. Then, these ideas are prioritized in a roadmap with the help of relevant business cases which eventually help product teams to narrow down the list. Once an idea makes it to the top, a product manager talks to the stakeholders and the two come up with a set of “requirements,” which are usually functional specifications, but can also be user stories. Next, the user experience design team provides the visual design or, in cases of physical devices, the industrial design. That’s the model engineers work with to build the test product. After a few iterations – or “sprints” as they are usually called – the QA team gives a green light and the new idea is finally deployed to actual customers.

There are problems with this way of working at almost any stage. First of all, the waterfall model leads to “sales‐driven specials and stakeholder‐driven products.” Moreover, it disempowers the team that actually makes the product: rather than missionaries, its members become mercenaries. Roadmaps are an even bigger issue because even the most carefully planned among them fail to take into consideration the two inconvenient truths about products. Namely, that half of our ideas don’t actually work and that the ones that do take several iterations to be refined to the point of delivering the necessary business value.

Unfortunately, the waterfall model makes product managers merely project managers because, by the time they enter the story, the product is already out of their hands and they can only gather the requirements and document them for the engineers. The same holds true for designers whose contribution to the creation of a product in the waterfall model can be likened to putting “lipstick on the pig.” However, the biggest missed opportunity in the model – at least according to Cagan – is the fact that engineers are brought in way too late. “The little secret in product is that engineers are typically the best single source of innovation,” he writes. “Yet, they are not even invited to the party in this process.”

Lean, Agile and beyond 

By its very design, the waterfall model is “project-centric.” Unfortunately, writes Cagan, “projects are output and product is all about outcome.” By putting customer validation at the very end, the waterfall model sets companies up for predictable failure. After all, there’s no bigger waste of resources than to ideate, design, build, test and deploy a feature or product only to find that your customers don’t like it or that it was not what they needed in the first place. 

Fortunately, that’s the key principle in Lean and Agile – to reduce waste. Both of these methods encourage teams to deliver fast by managing flow and by including most members of the team – as well as the customers – at all stages of product development. Unsurprisingly, most top companies today use Lean and Agile. In Cagan’s experience, however, the best among them go even beyond these two methods, showing religious devotion to the following three overarching principles:

1. Risks are dealt with upfront, rather than at the end. In modern teams, explains Cagan, the four most important risks are tackled prior to deciding to build anything, not afterward. The risks he has in mind are: 1) the value risk, or whether customers will buy the product; 2) the usability risk, or whether users can figure out how to use it); 3) the feasibility risk, or whether engineers can build what the company wants to with the time, skills, and technology it has at the moment; and 4) the business viability risk, or whether the particular solution works for other aspects of the business, such as sales, marketing, finance, legal, etc.
2. Products are defined and designed collaboratively, rather than sequentially. The main problem with the old waterfall model is that the further down the development process a product is, the less contribution one can make. Engineers, in other words, can only build what designers have only polished what product managers have only defined in line with the ideas and requirements casually set by stakeholders or business owners. In today’s strong teams, explains Cagan, “product, design, and engineering work side by side, in a give‐and‐take way, to come up with technology‐powered solutions” that will be loved by customers and will additionally work for business. 
3. It’s all about solving problems, not implementing features. As we already noted, traditional roadmaps are more interested in outputs than in outcomes. Strong teams, however, know that the outcome is all that matters. In other words, they know that adding features for their sake is an exercise in vanity and that, conversely, solving the underlying problem of a customer is the only win-win scenario there is in business and what actually brings results – for everybody. 

The foundation of modern product work: key concepts

According to Cagan, no more than a few key concepts form the foundation of modern product work. Here they are:

1. Holistic product. For Cagan, there is only one way to understand a product: holistically. In other words, if you want to create a good product, you must go beyond its functionality (that is, its features), and also take into consideration the technology that allows this functionality as well as the user experience design that presents it. Moreover, a holistic product includes the ways it can be monetized and acquire users and customers. It can also include offline experiences essential to delivering its value. All in all, the product is not just the product – it’s everything around it as well.
2. Continuous discovery and delivery. There are two essential high-level activities in all product teams: discovering the product to be built and delivering it to the market. Whereas in the past, these activities were detached and disconnected, today they must be practiced concurrently, that is to say, a product team must simultaneously discover what to build, while delivering the product to the market. It’s mostly the product manager and the designer that work on discovering and the engineers on delivering, but in strong teams either side is more involved in all processes.
3. Product discovery. In modern product management, discovery is all about tackling the most common risks before deciding to build anything. “The purpose of product discovery,” writes Cagan, “is to quickly separate the good ideas from the bad.” This is done through four critical questions, concerning the product’s value (“Will the user buy this?”), usability (“Can the user figure out how to use this?”), feasibility (“Can our engineers build this?”) and viability (“Can our stakeholders support this?”).
4. Prototypes. They don’t say “prototype is king” for no reason. Just as humans learn through trial-and-error, products should too. On any given week, a strong product team should be prepared to test between 10 and 20 ideas. Producing prototypes should be cheap and easy. In fact, as Cagan says, regardless of the type of prototype, they all must require “at least an order of magnitude of less time and effort than building a product.”
5. Product delivery. The purpose of prototypes is coming up, quickly and cheaply, with evidence in favor or against an existing idea. The final product must not only be based on the winning idea, but also be fault-tolerant, secure, reliable and, above all, work as advertised. Just as importantly, it must be something that can be sold and something that can sustain a business in the long run.
6. Products and product/market fit. A concept popularized by venture capitalist Marc Andreessen, product/market fit means “being in a good market with a product that can satisfy that market.” In other words, even if you have the best product but the market for it is small or shrinking, you will have only a good product, but not a viable business model. Just like not all products are created equal, not all markets are created equal either. You must target a good market by creating a minimum viable product (or MVP) that solves a small, cheap need that exists for many or a big, expensive need that exists for a few.
7. Product vision. The final critical concept of modern product work. If product delivery is mostly about the present, product vision is all about the future, that is to say, about the longer-term objective of a product, normally two to 10 years out. It is basically about how a product relates to a company’s mission and how it delivers with regard to its values and plans.

So, to sum up using the words of Cagan, “We use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company's product vision.” Skip any of the steps, and you risk dealing with a lot of waste, and even devastating failures.

Final notes

The first edition of “Inspired” was exceptional in itself; the second is even better. Both function simultaneously as an introduction to the process of modern product development, and a product management reference guide. Filled with personal stories and numerous relevant tips and tricks, “Inspired” is certainly one of the best-loved books by technology product managers today. 

To quote Chad Dickerson, the former CEO of Etsy, “If you only have one book on product management, this is the one.”

12min tip

If your company tackles product risks at the end of the production process, then it’s not following Lean and Agile principles, but the old waterfall model – whatever you might think. Define and design products collaboratively and include as many members of the team as possible at every stage of development.