My Takeaways from Inspired by Marty Cagan
A summary of my key learnings after reading Inspired: How to Create Tech Product Customers Love by Marty Cagan
1/22/20245 min read
The Great Gatsby by F. Scott Fitzgerald, How to Kill a Mockingbird by Harper Lee, and Inspired: How to Create Tech Products Customers Love by Marty Cagan. Every 9th-grade English class throughout the US should be taught these literary classics.
Ok… maybe every 9th grader doesn’t need to learn how to build successful tech products. However, if you're a current product manager, someone aspiring to break into product management (like myself), or a business leader in a product organization, I think this book is a must-read.
Inspired delves into the strategies employed by today’s tech giants and sheds light on how they define, design, and develop products cherished by billions worldwide. It essentially serves as a master class on how to build “empowered” product organizations, and how to discover and deliver technology products that not only resonate with customers but also align with the success of your business.
While the book is best suited for individuals with a few years of experience working in product, it offers a treasure trove of advice that even newcomers like myself can learn from.
Below are a few of my key takeaways. I plan on revisiting this post once I have a few years of experience to reflect on, and perhaps these learnings will take on a new meaning.
#1: PMs need to foster collaboration to build better products
The PM is not the boss of anyone on the product team. Engineers and designers don’t exist to enact the PM’s product vision. Rather, the best product teams have a horizontal structure where everyone contributes to the direction of the product and embraces the give-and-take of building technology-powered solutions. It is the PM's job to cultivate relationships and create this collaborative dynamic in their team.
“We need teams of missionaries, not teams of mercenaries”
Throughout the book, Cagan emphasizes the importance of having a team of missionaries instead of mercenaries. Mercenaries build whatever they are told to build, while Missionaries believe in the product vision and are committed to solving any problems to realize that vision.
PMs should want missionary teams that work harder, ship faster, and ultimately deliver better products. Fostering missionary-like passion is the crux. It takes having a compelling product vision and allowing team members to have control over the direction of the product.
This means everyone on the team should be involved in product discovery, ideation, and strategy. Engineers, designers, and other team members should be routinely asked to provide their input at all stages of the product cycle. Given the substantial time engineers spend immersed in the product, they often emerge as valuable resources for generating innovative product ideas.
By relinquishing some control, the PM can create a collaborative environment where the team shares responsibility and ownership over the product outcome.
#2: Outcome is more important than output
Who is the better PM? Is it PM Alpha, who leads their team in implementing 20 features that have a negligible impact on revenue, or PM Beta, whose team releases one feature that results in a 50% increase in conversion rates?
It seems obvious that achieving business results should matter more than output, but according to Cagan, many organizations are not optimized this way. Instead, they follow the old project-oriented model that focuses on following a product roadmap and pushing features out the door.
“...projects are output and product is all about outcome”
It turns out that it’s easy to fall into the trap of believing your team is being productive because it’s constantly shipping. Company management likes product roadmaps because they provide tracking and make sure teams are working on “highest-business-value” items first. Here lies the crux of the problem because whatever items are put on the roadmap are interpreted as commitments for the product team. The PM’s team is thus expected to build and deliver the requested feature, even when it doesn’t solve any underlying problem.
Therefore, for PMs, simply getting to launch is not the goal. A PM’s job is to achieve business outcomes through developing products that customers love. Yes, sometimes deadlines are important, but a PM needs to make sure any idea their team commits to is a high-integrity commitment that the team is confident will solve a business problem.
#3: PMs need to address all risks before building anything
Product discovery is the first and most crucial step in ensuring the team is building towards a positive outcome. In this phase, a PM collects evidence to gain insights into customers' problems and eventually formulate the most optimal solution.
“Risks are tackled up front, rather than at the end”
Since the majority of ideas fail, the PM needs to address any risks before having engineers write production software. If a PM is not confident that they can deliver a solution that customers will love, then an enormous waste of resources is almost inevitable. Through product discovery, PMs can minimize risk before deciding to build anything. In his book, Cagan divides product risk into four categories and describes the purpose of product discovery as answering these questions:
Value Risk - Will the user buy this? (or choose to use it)?
Usability Risk - Can the user figure out how to use this?
Feasibility Risk - Can our engineers build this?
Viability Risk - Can our stakeholders support this?
Again, most ideas will fail, so the goal is to answer these questions and validate ideas in the fastest and cheapest way possible. Cagan insists that strong teams can test 10 to 20 or more ideas per week. This number is staggering but can be achieved through quick prototypes and an effective team. Given the availability of no-code and AI tools that exist today, it should be even easier to run experiments to validate ideas.
Conclusion
There are a lot of other lessons to be learned from Inspired, and I plan on continually referring back to this book throughout my career. I’ve seen several people on Twitter refer to it as the bible for product managers, and I now see why. There is a wealth of advice that I didn’t even scratch the surface of in this post.
It’s clear to me that being a product manager is no easy task, but I already knew this. It’s the fact this job is equally challenging and rewarding that attracts me and others to this role. Not only do you have to have a wide berth of deep knowledge and skills, but even more importantly, you must know how to work with and get the best out of your colleagues. Now that I have finished the book, I feel even more Inspired to become a PM…
Thank you for reading to the end. As a reward, I will leave you with two additional quotes that stood out to me.
