[Book Review] Inspired by Marty Cagan

Before I find a new favorite, I want to write about the book I loved most about product management. As a short start, I can say that Inspired by Marty Cagan has a good story line and touches every corner where I want to improve myself as a Product Manager. The book explains different techniques for each process you can implement into your product. Honestly, I am so “INSPIRED” about personal stories of successful Product Managers who are working at Google, Apple, Netflix etc. That’s why It is hard to summarize every point the book explains, so I will skip some of the parts and share the good points that I highlighted. Here is my first highlight I catch that Product Managers should remind themselves frequently;

“Good teams get their inspiration and product ideas from their vision and objectives, from observing customers’ struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.”

The writer supports the same idea in the book with different quotes like: “We need teams of missionaries, not teams of mercenaries.” Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. Why did I select this part first? Because in daily life we sometimes forget what our main goal is and jump into requests people are asking for. Our end goal is to please stakeholders and it is the easy way. But the product mostly ends up with more problems and requests.

In the other parts the book mainly focused on explaining best product team approaches. Finding good people who fit the role and product idea is supported with real-life experiences. Marty highlights good product managers work side by side with the design and engineering team to create better user experience with enabling the technology. Also indicates that the product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team.

The writer believes that the product manager should have strong capabilities like technology sophistication, business and customer knowledge, communication and passion for the product. He basically explains product managers’ role as evaluating opportunities and determining what gets built and delivered to customers. Managing backlog is the challenging part, we should decide what is worth building for our product. We should be able to explain why we are building this backlog with data to the engineering team. Because we are the responsible person of the product. He also says that:

“When a product succeeds, it’s because everyone on the team did what they needed to do. But when a product fails, it’s the product manager’s fault.”

Product Managers ensure a business outcome with the features they define. This can bring success or failure. To be able to guarantee success, PMs should have a good understanding of all the related parts of the business: financial, marketing, sales, legal, partnership, service, the customer environment, the technical capabilities, the user’s experience. The writer indicates that there’s probably no more important relationship for a successful product manager than the one with our engineers and I totally agree with this statement. I think the stronger the internal team relationship, the more success we will achieve.

In the right product part the writer points out the roadmap problems and asks about what the product team should work on.

“Typical roadmaps are the root cause of most waste and failed efforts in product organizations.”

There are different types of roadmap such as stakeholder–driven and product-driven. I worked for both types of backlog and the problem is not the type of roadmap. I think it is trying to develop everything we promised even if the features value is no longer valid. Most of the companies prepare annual roadmaps and try to deliver every line of the features. Even with the best effort of the team, product roadmaps can lead to very poor business results. We should be aware about whether these ideas in the roadmap are not necessarily a commitment. Features can lose their value along the way. Because we have a long way to go like in the product vision which mostly describes between two and five years. The writer believes that the product vision is the most effective recruiting tool because it helps us to show our dream and motivate the team. For releasing the product vision we should have a product strategy that is suitable for our product targeted market. The strategies should be focused on a single target market at a time. We can structure our strategy according to geography, user persona, key milestones. There’s no single approach to product strategy that is ideal for everyone. The best product vision should be inspiring and the product strategy should be focused.

“The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there.”

I really liked the part the writer explains about the product objectives with the summary of telling people what to do, and letting them surprise you with their ingenuity. Firstly we should empower and motivate the team to do their best work and then we should be able to meaningfully measure the process. Companies like Google, Intel are using different frameworks and tools for goal-setting. The Objectives and Key Results (OKR) is one of them. Objectives should be qualitative and inspiring. Key results should be quantitative and measure business success and results. Measuring should be based on business results not output or tasks.

The fourth part is for how product teams do their job. The writer explains the right processes, techniques, activities and best practices. Product discovery principles are for answering critical risks and purposes like financial, business development, marketing, legal and ethical risks. We should work with the team, stakeholders, and customers to be sure the final solution works for all the market/customers. Additionally we need to ensure the team is all on the same page in terms of clarity of purpose and alignment. After we all are on the same page we need to test the ideas to differentiate good and bad ones. Marty explains usability, value, qualitative value and quantitative value testing. With testing we can avoid the risk of wasted engineering efforts and release with confidence. Marty listed the questions for minimizing the critical risks as below:

• Will the customer buy this, or choose to use it? (Value risk)
• Can the user figure out how to use it? (Usability risk)
• Can we build it? (Feasibility risk)
• Does this solution work for our business? (Business viability risk)

This part also has important tips I want to mention about product discovery as a short list.

• Customers don’t know what’s possible, and with technology products, none of us know what we really want until we actually see it.
• The hardest part is creating the necessary value so that customers ultimately choose to buy or to use.
• We need to be open to solving the underlying problem in different ways if necessary.
• We must validate our ideas on real users and customers.
• Our goal in discovery is to validate our ideas the fastest, cheapest way possible.
• We need to validate the feasibility of our ideas during discovery, not after.
• We need to validate the business viability of our ideas during discovery, not after.
• Last and most important part is “SHARING LEARNING”! As a team we should share our learning to have the same knowledge.

The discovery framing techniques part is helpful for identifying user problems, business objectives and solving it for customers. For features defining he explains “Opportunity assessment”, for larger projects he explains “Customer letter” techniques and lastly for new products he explains “Startup canvas” method. After framing is done, the discovery mapping part starts. The story map technique is one I frequently use for ideation. It is a typical flat backlog of user stories. We are starting to add major user activities on a horizontal axis by time from left to right. We continue to add details (stories) from critical to minor to the vertical dimension. With the combination of the two dimensions we can see the big picture of the problem. The customer discovery program technique indicates reference customers. The customer should be a real customer who is running your product in production who has paid real money for the product who is willing to tell others how much they love your product. He believes that there are few things more powerful to a product organization than reference customers. He also taught we should have at least 6 reference customers to collect feedback for developing our product vision and strategy.

“How do we generate the types of ideas that are likely to truly help us solve the hard business problems that our leaders have asked us to focus on right now?”

The writer lists the ideation techniques to focus for solving problems:

• Customer interview is the basic one. After I read this book, we prepared a customer interview list and it really helped us to understand our product’s usage problem. You can check my previous story about customer interviews.
• Concierge test is an old but effective technique. You can do the customer’s job for them(manually and personally). Just go and try out the ideas.
• Customer Misbehavior is to find miss usage of the product. Monitoring the customers with tools (Google Analytics etc.) will help you point out the bigger problems.
• Hack days have two types: directed and undirected. You can give goals or problems and ask people to explore their ideas.
• Prototyping is a “learn at minimum cost and time” technique. We should be able to address what needs to be built so shared understanding is also important for this technique. You can find good tips about prototyping in the book.

Before explaining the right culture the writer also mentions how we can scale the process with stakeholder management and shared product learnings. Product team has the responsibility to collect all the required knowledge and bring it into the team. In the last part we are starting to define what is a good product team and how we can get the right culture. We can find a list of good characteristics of a product team in the book as i mentioned above “Good teams have a compelling product vision that they pursue with a missionary-like passion. Bad teams are mercenaries.” I like the part which explains how good teams celebrate business outcomes while bad teams are celebrating features.

The book overall explains product culture and how great product companies think, organize and operate. We can understand the characteristics of a strong innovation culture versus those of a strong execution culture. The key point is trying to be good with both innovation and execution. As the writer I can say, I hope you and your team consider doing these steps and ask yourselves where you would like to be as a team or company. Wish you luck on your journey!