Inspired by Marty Cagan
Key takeaways from the industry's primary book on creating products customers love.
👋 Hi! Sean here, and welcome to my weekly newsletter on product management, thank you for being here! Each week, I read a book about (or related to) product management, and share its main learnings. This week, we are kicking things off with one of my favourites; Inspired by Marty Cagan! It is a must-read for every (aspiring) product manager, so if you don’t own the book yet, you can get your copy over here: Inspired by Marty Cagan.
Let’s dive right in!
“It does not matter how good your engineering team is if they are not given something worthwhile to build.”
You can often catch me saying that if you’re going to read exactly one book about product management, it has to be Inspired — How to Create Tech Products Customers Love by Marty Cagan. Earlier this year, I re-read the book for the fourth time, and even upon the fourth iteration, new details stood out to me. The book was originally published in 2008, and even though the technology sector has rapidly evolved ever since, the book has truly stood the test of time. Let’s dive in to the industry’s most inspiring book on product management!
TL;DR for the Time Pressured Product Manager
Only got a couple of minutes? This section provides the key takeaways from the book.
The main reason that product efforts fail is that it takes a very long time to make it from idea to putting a product in the hands of the customer.
Product roadmaps are one of the root causes of failed product efforts. The reason for this is that half of our ideas is just not going to work, and for the ones that do work, there is a significant time-to-money. Furthermore, they will cause you to commit to building features that end up not being valuable to your customers.
Strong product teams are teams of missionaries, that are committed to solving problems for their customers. They are empowered to discover the path towards achieving their objectives collaboratively.
Strong product organisations employ OKRs, a product strategy, and a set of product principles to work towards achieving their (leap-of-faith) product vision.
Never shelter the engineers from the pain of the customer and the business, but discuss them openly with them: They will respect you for it, and often they will rise to the challenge.
During product discovery you’ll need to get your ideas in front of real customers early and often. During product delivery you’ll want to use best practices for engineering and try not to override the engineers’ concerns.
The most important thing is to establish compelling value. We can survive with usability or performance issues, but without value, we have nothing.
About the Author: Marty Cagan
Marty Cagan is often recognised as the primary thought leader in the field of product management. During his long career, Marty was responsible for the product management departments in several of the most successful companies of their time, including HP, Netscape, and eBay. These days, Marty is a well known public speaker at product and technology conferences around the world, and a coach for companies that want to get better at product management. He provides these services with his company, the Silicon Valley Product Group: svpg.com.
The Root Causes of Failed Product Efforts
The first couple of chapters of the book are the most eye-opening chapters a beginning product manager could ever read. Marty sets the stage brilliantly by sharing how he worked with a team of excellent engineers at HP for a period of over a year, to build a product that nobody ended up buying. (An experience that most of us end up going through early in our careers.) This frustrating experience made Marty commit to never again build a product without validating its potential value—a skill that would prove to be a cornerstone to his product approach. Over the years, more and more companies started to reach out to Marty to learn how to improve their process for producing products. This allowed him to uncover another interesting learning:
“There is a tremendous difference between how the best companies produce products, and how the most companies produce products. There is a tremendous difference between the state of the art and the state of the practice.”
The book proceeds to uncover the root causes of failed product efforts. I remember that this section sent chills down my spine when I read it for the first time, as most root causes are very prevalent in the industry. I dare say some of them are even considered good practices by some companies, and are endorsed by them.
The main reason that product efforts fail is that it takes a very long time to make it from idea to putting a product in the hands of the customer. Essentially, while most companies claim to be agile, most companies are still working with a waterfall process, with the development team desperately trying to utilise some form of agile. Some of the root causes that the book mentions include:
The source of ideas is wrong, and engineers are brought in way too late. (Stakeholder- or Sales-driven development.)
Stakeholders want to know how much something will cost, and how much money they’ll make beforehand: You can’t actually know this upfront in product development.
Product roadmaps are seen as a commitment and a planning tool, even though most of the items on the roadmap might turn out not to be valuable to customers. (This turns product managers into project managers.)
Customer validation happens way too late.
This chapter alone is a reason to own a physical copy of the book. I often re-read it to remind myself of what bad product development looks like.
The Principles of Strong Product Teams
Fortunately for us, there is a better way to create products. The following characteristics create the foundation of a great product team:
Risks are tackled upfront, rather than at the end.
Products are defined and designed collaboratively, rather than sequentially.
It is all about solving problems, not about building features.
Essentially, we’re trying to create a team of missionaries that are true believers in the product vision, and are committed to solving problems for their customers. We achieve this by giving the team clear objectives, and empowering them to figure out the best way to meet these objectives. By working this way, the team fully understands the business objectives and context, and they feel full ownership and responsibility for the outcome.
The next section of the book describes the different members of a product team, and their respective roles in the team. Especially the relationship with the engineers is of extreme importance. It is essential that you’re sharing very openly what you know and are learning about the customers, their pains, and the business constraints:
“Involve the engineers deeply in the pain of the customer and the business problems you face. Don’t try to shelter them from this, but discuss them openly with them. They will respect you more for it, and most of the time, they will rise to the challenge.”
This makes them feel and act like missionaries, not mercenaries.
The Problems with Product Roadmaps
Product roadmaps typically lead to very poor business results. This is a counterintuitive statement for the first time reader, as product roadmaps are anchored deeply into the way of working of most companies. The reasons for this are what Marty refers to as the two inconvenient truths about product:
At least half of our ideas are just not going to work.
Even the ideas that prove to be valuable, usable, feasible, and viable, typically take several iterations to get the execution of the idea to the point where it delivers business value. (Time-to-money)
The issue with a product roadmap is that as soon as you put your ideas on a document titled ‘roadmap’, no matter how many disclaimers you put on it, people will interpret it as a commitment. This means that sooner or later, you’ll end up building features because ‘you said so’, not because they are of some sort of value to the customer.
In order to move away from roadmaps and their problems, organisations must start prioritising business results. Naturally, roadmaps do serve a purpose, as the company uses them to assess whether the team are working on most important items, and to make date based commitments when they need to do so. (Even though most of the time, we won’t make these dates in the roadmap anyway.) These needs don’t go away, so a middle-ground approach that teams often take, is to create an outcome-based roadmap. The outcome based roadmap takes a regular roadmap, and replaces the features on it with the business problems that they intent to solve. This approach gives two advantages:
You are committing to solving a problem, not to a specific feature.
You are giving yourself the opportunity to course-correct as soon as you find out that a feature doesn’t solve the problem it is intended to solve.
This flexibility will help you to create better products for your customers and business.
The Alternative: Vision, Strategy, Principles, and OKRs
As stated before, we’re trying to create teams of missionaries, that are empowered to solve problems for our customers. How can we enable them to work in this way? Essentially, we’ll have to make it crystal clear to them what we’re trying to achieve.
At the heart of every product team, is an inspiring product vision, describing the future we’re trying to create. (Typically somewhere between two and five years out.) Such a product vision is a leap of faith: You can’t always know if you’re going to be able to deliver on the vision. The product vision is then often combined with a product strategy, which describes the sequence of product/market fits that we’re attempting to realise on our way towards achieving the vision. Finally, it is often good to complement the product vision and strategy with a set of product principles. Product principles speak to the nature of the products that you’re trying to create, and they can act as valuable ‘guardrails’ for the product decisions that the teams are making.
After creating the vision, strategy, and principles, it is important to focus and align our different product teams around them. This can be done by utilising a framework called Objectives and Key Results, or OKRs. OKRs are based on two fundamental principles:
Never tell people how to do things. Tell them what to achieve, and they will surprise you with their ingenuity.
You can release all the features you want, but if it doesn’t solve the underlying business problem, you haven’t really solved anything.
I could write a full-length article on OKRs, and I will! I’m currently reading “Measure What Matters” by John Doerr (Measure What Matters - John Doerr), which covers OKRs in great detail. Expect to see my notes on the book in a future post.
In essence, our goal is to assign business objectives to our product teams, and define which key results will allow them achieve on their objectives. It is important that the team feels accountable for these objectives (again, to create teams of missionaries), and so they’re often created in a bottom-up fashion. Over time, the team measures their progress towards achieving their objectives, to ensure they stay on the right track.
Inspired provides a great starting point for applying OKRs in your organisation, and for exact details, I’d recommend you buy the book, as it does a great job explaining them.
Product Discovery
At this point, we have established that it is the goal of the product team to deliver outcomes that advance a product towards its vision. We do this by implementing possible solutions, and we course-correct as soon as we see that our solutions are not solving the problems we’re intending to solve. (Or, we double down in case they do!) This creates an interesting dynamic: It implies that the best product team is no longer the team that can create the most beautiful software, but it is the team that can evaluate if something is valuable to their customers the quickest! We enable our product teams to learn quickly by using a framework called product discovery.
“The purpose of product discovery is to make sure we have some evidence that when we ask the engineers to build a production-quality product, it won’t be a wasted effort.”
During product discovery, we evaluate the following risks:
Value risk: Will the customer buy it, or choose to use it?
Usability risk: Can the user figure out how to use it?
Feasibility risk: Can our engineers build it?
Business viability risk: Does the solution work for our business?
Again, opinions are not enough here, we need to collect evidence. Furthermore, out of all these risks, the most important thing is to establish compelling value. We can survive for a while with usability or performance issues, but without value, we have nothing. During product discovery, we optimise for quick learning: Every bit of time spent on an idea that isn’t valuable is wasteful. Therefore, we employ several different techniques during discovery, most of which do not require us to write any code. All of these techniques are detailed in the second half of the book, and are a useful guide into the world of product discovery.
It is important that we share our learnings broadly. Within the product teams, as this creates teams of missionaries, but also outside the product teams. The big learning should be shared through the entire business, especially if things didn’t work out as hoped. Otherwise, the business will continue to operate on false assumptions.
Finally, it is important to never let the lines between discovery and delivery blur too much, as they require a radically different mindset. Product discovery is about rapid learning: Coming up with a valuable solution for our customers. Product delivery is about execution: Creating a productised, shippable version for our customers.
“If you want to discover great products, it is essential that you get your ideas in front of real customers early and often. If you want to deliver great products, you want to use best practices for engineering and try not to override the engineers’ concerns.”
Closing Remarks
If you ever decide that you will read exactly one book about product management, this has to be the book. It provides every product manager with the foundational mental model of how to create products that customers love. By following the principles outlined in this book, you are miles ahead of the competition that doesn’t follow a similar approach, and on your way towards a great product.
That being said, implementing the principles of Inspired isn’t necessarily easy. As the art of product management is very counterintuitive, it will require an organisational shift, and it might take time before your convince your colleagues (or boss) that this is the way to go. Several books have been written on how to achieve a successful implementation, and you can be sure that they will be covered in a future post. (Marty even wrote a follow-up book on the topic with fellow SVPG partner Chris Jones: Empowered by Marty Cagan and Chris Jones)
On a more personal note, I would like to thank Marty Cagan for writing this book. This book send me down the rabbit hole on effective product management, and it has helped me grow as a product manager at a pace that I couldn’t have imagined upfront.
Hopefully, this post convinced you that you need to read Inspired for yourself! If you decide to buy the book, please consider using my affiliate link below. (This will not cost you anything extra.)