Inspired by Marty Cagan: five key points from this must-read book

Sometimes you come across a book at just the right time. The content immediately makes sense and you cannot stop reading. This happened to me when I recently read Inspired by Marty Cagan. Almost everything in it resonated with me at once. Inspired spelled out what I had felt but hadn’t been able to formulate, confirmed some of my standing convictions, and also brought tons of new stuff.

The book is densely packed with actionable advice and techniques one can immediately apply, too much for a small blog post. Nevertheless, I want to share the core learnings I took from Inspired. I will summarize my understanding of the main concepts and share the five takeaways that resonated most with me. 

   


The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 


The main concepts behind Inspired

Inspired by Marty Cagan is a book for product managers responsible for tech products. The book essentially outlines the mindset, principles, and best practices used in product development by the very best companies that are able to continuously innovate. Inspired shares common antipatterns within product development and gives actionable advice on how to deal with them in developing digital products. 

First and foremost, it stresses the (undervalued) importance of the product manager role. It’s the product manager’s responsibility to lead a team that uniquely combines technology and design in solving the problems of users while meeting the needs of the company. Every successful product is backed by a product manager who does just that.  

Similar to the Product Owner (PO) in Scrum (I would argue that it is essentially the same role), this is the person that has the responsibility of determining what the team builds. As such the leverage in influencing the success of the product (or lack thereof) is incredibly high. 

You can have the best engineers, if the team places the wrong focus and builds something that no one buys, you’re going to have a problem. It’s the product manager’s responsibility to ensure this doesn’t happen, to ensure effective product development. 

At the heart of the best development efforts is a cross functional product team. The team consists of engineers, a designer, and the aforementioned product manager. This product team has minimal dependencies to others and has a long-term business outcome to achieve.

Instead of the typical roadmap where management prescribes features that need to be delivered at a specific point in time, the team itself should be empowered to decide how to solve these business problems. Guiding the developmental efforts are the product vision, the strategy, and the outcome based roadmap. 

At its core the best product teams build products according to three principles.

  • Address risks as early as possible
  • Build products collaboratively
  • Focus on problems instead of features

If I would point to one thing to remember from this book, it’s these principles. I am fully convinced that following these is 80% of product success, regardless of what framework or methods you use.

Address risks as early as possible

There are four different types of risks that need to be addressed in product development:

  • Value risk: Is there a demand for the product?
  • Usability risk: Can users figure out how to use our product?
  • Feasibility risk: Are we able to build our product?
  • Business viability risk: Does our product work for all aspects of our company?

These risks need to be addressed with minimal effort and as early as possible in the process. We need to do this so as not to waste precious time and resources building something that has no chance of success.

We can best do this using product discovery techniques, where we run low effort but high impact experiments to validate our hypotheses about our product ideas. These techniques range from the well known, e.g. usability tests, to the lesser famous, e.g. concierge tests.

Build products collaboratively

Instead of building products sequentially, the product team leverages all of its capabilities to jointly build valuable products. This is done incrementally in a give and take manner.

Focus on problems instead of features

Instead of focusing on outputs, the best product teams focus on business problems they want to solve and outcomes they are attempting to achieve. As such, the product team needs to understand the issues our users are facing. 

The team must, as much as possible, forget about preconceived features when trying to solve these problems, so that it doesn’t artificially limit the solution space.

Five personal takeaways from Inspired 

There is so much more to the book than I can mention here. It includes a long section about product discovery, probably the hardest part of product development. Cagan shares techniques over techniques on how to address risks. 

Instead of sharing all of these, I will expand on five topics that resonated most with me. 

  • We need a team of missionaries, not mercenaries
  • The power of outcomes
  • The importance of discovery work
  • Get the engineers talking to users and customers 
  • Don’t focus too much on competition

Arguably the most important concept is having an empowered product team of missionaries.

We need a team of missionaries, not mercenaries

Unfortunately, many companies use their product teams as mercenaries that are paid money to produce outputs dictated by others. Instead, our product team needs to be a group of missionaries for the product they are responsible for. They need to feel Inspired, when thinking or talking about our product. 

It’s critical to foster a sense of ownership. The team needs to be enabled to solve user problems how it sees fit. This way, it learns to truly care about our users and customers, the issues they face, and feels responsible for the solutions it comes up with (instead of mindlessly developing features someone else came up with).

The reason for preferring missionaries to mercenaries is simple: motivation and all of its positive side effects. A team of missionaries understands why they are building what they are building. They have a purpose. This keeps motivation high leading to less fluctuation, more productivity and creative solutions, as well as an overall happier team.

The power of outcomes

In empowering a team, focusing on outcomes instead of outputs is probably the single most powerful leverage point. It’s also one of the hardest to achieve as it often requires a change in mindset of our leaders. The effort spent in convincing them is worth it, though.

The vast majority of teams use a typical roadmap where senior leadership prescribes a timeline of features or outputs that need to be implemented. This is problematic for many reasons. Instead, we need to focus on business problems and define the outcomes that will solve the business problems.

Ideally, the outcomes are derived from a clearly articulated product vision and strategy that the team understands and has bought into. The vision is the future state we want to achieve. The strategy consists of the high-level steps we want to take to achieve our vision. The roadmap are the outcomes we want to attain in executing our strategy. Only then does the team come up with feature ideas – outputs – that it thinks will help achieve those outcomes. 

Once this chain is in place, you have a great framework for the team to understand why we are doing what we are doing. This is great for creating an empowered team with a true sense of ownership for the product. 

The importance of discovery work

Product development consists of two phases. In product discovery we address risks upfront to make sure what we build is viable for our business. In product delivery we build solutions. Many teams tend to focus on delivery. Scrum, for example, is often used exclusively for delivery work.  

The reason for this is probably because it’s very unintuitive (for leaders) to allow for teams to try out things that they know they will throw away later. However, we need to be aware that we don’t initially know what our customers truly need. 

In fact, our users often can’t even tell us what they want. They don’t know what is technologically possible. For this reason, we need to always attempt to understand the issues our users are facing and then conduct experiments to test different ideas on how to solve those issues. 

With these low effort and high impact experiments we attempt to address four different types of risks mentioned above (value, usability, feasibility, business viability). Countless techniques exist to do so, many involving prototypes. Competent teams are able to test 10-20 (!) ideas per week.

Get the engineers talking to users and customers 

I could have added this to the last section about discovery. I think it’s so important, though, that it warrants a separate paragraph. It is certainly the thing that changed most about my thinking.

In the past, I have always wanted to protect the engineers from too much direct interaction with customers or the sales organization. I did this to make sure the engineers are not constantly bombarded by requests that they feel powerless to say no to. This was how it often was when I joined new teams. Overall, I think everyone was satisfied once I stepped in and channeled everything through me as the PO. 

It was certainly a more structured approach to work. However, I think I took it one step too far in the past and should have struck a better balance. 

This line stuck with me most from the book: If the engineers are just coding you only get half of their power. Oftentimes it’s exactly from the engineers that the best ideas for solutions come. For this reason, they need to frequently be in contact with users and customers to truly understand their problems.

At the very least, they should regularly watch customer interviews or be an observer in a usability test. 

Don’t focus too much on competition

Bad teams obsess over their competitors. Good teams obsess over their reference customers. 

Obviously, the product team and the product manager in particular need to be aware of the market, the trends, and the competition. However, many companies place far too much emphasis on that competition. (This reminded me very much about the example of Apple vs. Microsoft (under Steve Balmer) in Start With Why.)

Instead, we need to focus on reference customers and help them solve problems. We need to focus on several – the exact number depends on the type of product – customers per market segment with whom we build a very close relationship. We then optimize the product for those customers.

A happy reference customer is evidence that our product works. It is also one of the best tools a product manager can give the sales team, as they can be used in negotiations with other clients.

As always, it comes down to principles

Inspired by Marty Cagan is a book that anybody working in product development can benefit from.

Cagan sets a very high bar. To me, it’s clear that the book explains an ideal state of product development that is hard to achieve in practice. I certainly haven’t been part of a company where I’ve seen all of the best practices implemented. 

However, as it so often is, it comes down to the underlying principles. If you let those guide your thinking, I strongly believe you’re already halfway there. If you take one thing from this text, then it’s the principles- take care of risks as early as possible, jointly build products, and focus on outcomes instead of features. 

Do this and you should be good to go.