Inspired by Marty Cagan

How strongly I recommend this book: 8 / 10

Date read: July 21, 2021

Get this book on Amazon

Summary - A classic book on Product Management

Marty Cagan’s Inspired will be my first recommendation to anyone who wants to understand what Product Management is all about. He talks about the impact good product managers can make (primarily in tech companies), and how many companies get this role wrong. How it’s important for you as a product manager to be the evangelist of the product for the team. And how to work across the many stakeholders PMs have to worth with. Big takeaways for me 1) Be the expert on the users, business, and market/industry. 2) Evangalize the team forward by sharing key learnings with broader teams. 3) Learn to love problems. Measure success through outcomes instead of feature launches. I also recommend watching the Steve Jobs Lost Interview that Marty mentions in a podcast.

Favorite Quotes and Chapter Notes

I went through my notes and progressively capture key quotes from all chapters below.

P.S. – Highly recommend Readwise if you want to get the most out of your reading.

Lessons from Top Tech Companies

Good product team’s assume that at least three quarters of the ideas won’t perform and iteration is key
The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process.
To set your expectations, strong teams normally test many product ideas each week—on the order of 10 to 20 or more per week.

The Right People

Building a Team of Missionaries

Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers. In a dedicated product team, the team acts and feels a lot like a startup within the larger company, and that’s very much the intention. We need teams of missionaries, not teams of mercenaries.

Product Manager and Key Responsiblities

He or she is responsible for evaluating opportunities and determining what gets built and delivered to customers.
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.
But if you want to know why the product manager role is considered so important today by CEOs and venture capitalists (VCs), it’s this: Every business depends on customers. And what customers buy—or choose to use—is your product. The product is the result of what the product team builds, and the product manager is responsible for what the product team will build. So, this is why the product manager is the person we hold responsible and accountable for the success of the product.
Four key responsibilities
- Deep Knowledge of the Customer
- Deep Knowledge of the Data
- Deep Knowledge of Your Business
- Deep Knowledge of Your Market and Industry

Bring Smart, Creative, and Persistent

Being intellectually curious, quickly learning and applying new technologies to solve problems for customers, to reach new audiences, or to enable new business models.
Pushing companies way beyond their comfort zone with compelling evidence, constant communication, and building bridges across functions in the face of stubborn resistance.
Start by becoming an expert in your users and customers. Share very openly what you learn, both the good and the bad. Become your team’s and your company’s go-to person for understanding anything about your customer—quantitative and qualitative.
Work to establish a strong relationship with your key stakeholders and business partners. Convince them of two things: (1) You understand the constraints they operate under. (2) You will only bring to them solutions that you believe will work within those constraints.
Become an undisputed expert on your product and your industry. Again, share your knowledge openly and generously.

Working with Product Designers

In strong teams today, the design informs the functionality at least as much as the functionality drives the design. This is a hugely important concept.

Working with Engineers

There’s probably no more important relationship for a successful product manager than the one with your engineers.
It’s also critical that you share very openly what you know about your customers—especially their pain—the data, and your business constraints. Your job is to bring this information to your team and then to discuss the various potential solutions to these problems.
There is nothing wrong with you bringing a strong point of view, but you must constantly demonstrate to your team that you’re open minded, you know how to listen, and you want and need their help in coming up with the right product.
One last thing to keep in mind: the morale of the engineers is very much a function of you as the product manager. It is your job to make sure they feel like missionaries and not mercenaries.
You do this by involving them deeply in the customer pain you are trying to solve and in the business problems you face. Don’t try to shelter them from this—instead, share these problems and challenges very openly with them. They will respect you more for it, and, in most cases, the developers will rise to the challenge.

Building The Right Product

There are a few product teams out there that have modified their product roadmaps so that each item is stated as a business problem to solve rather than the feature or project that may or may not solve it. These are called outcome-based roadmaps.
Outcome-based roadmaps are essentially equivalent to using a business objective–based system such as the OKR system. It’s the format that’s different more than the content.
Don’t be afraid to disrupt yourselves because, if you don’t, someone else will.
Obsess over customers, not over competitors. We can’t ignore the market, but remember that customers rarely leave us for our competitors. They leave us because we stop taking care of them.
Where the product vision describes the future you want to create, and the product strategy describes your path to achieving that vision, the product principles speak to the nature of the products you want to create.
Objectives should be qualitative; key results need to be quantitative/measurable. Key results should be a measure of business results, not output or tasks.
If you’re a product manager—especially at a large company—and you’re not good at evangelism, there’s a very strong chance that your product efforts will get derailed before they see the light of day.
How to evangalize the product -
- Use a prototype. For many people, it’s way too hard to see the forest through the trees. When all you have is a bunch of user stories, it can be difficult to see the big picture and how things hang together (or even if they hang together). A prototype lets them clearly see the forest and the trees.
- Share the pain. Show the team the customer pain you are addressing.
- Share the vision. Make sure you have a very clear understanding of your product vision, product strategy, and product principles.
- Share learnings generously.
- Share credit generously.
- Learn how to give a great demo. This is an especially important skill to use with customers and key execs.
- Do your homework. Your team and your stakeholders will all be much more likely to follow you if they believe you know what you’re talking about. And be the undisputed expert on your market, including your competitors and the relevant trends.
- Be genuinely excited.
- Learn to show some enthusiasm.
- Spend time with your team.

Product Discovery

But here’s the key. If you want to discover great products, it really is essential that you get your ideas in front of real users and customers early and often.
The purpose of product discovery is to address these critical risks: 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)
Our goal in discovery is to validate our ideas the fastest, cheapest way possible.
It’s about shared learning. One of the keys to having a team of missionaries rather than a team of mercenaries is that the team has learned together. They have seen the customer’s pain together, they have watched together as some ideas failed and others worked, and they all understand the context for why this is important and what needs to be done.
The very act of creating a prototype often exposes problems that cause you to change your mind.
There are a few techniques that are central to how Amazon builds product, and one of them is referred to as the working backward process, where you start the effort with a pretend press release.
Rather than delegating or deferring figuring out the solution, we need to embrace product discovery as the most important core competency of the startup.
A concierge test is one of my favorite techniques for quickly generating high-quality product ideas. It requires going out to the actual users and customers and asking them to show you how they work so that you can learn how to do their job, and so that you can work on providing them a much better solution.
Every time you reference a product roadmap item, or discuss it in a presentation or meeting, be sure to include a reminder of the actual business outcome that feature is intended to help. The goal is that over time, the organization moves its focus from specific features launching on specific dates to business results.
One of the most common mistakes product managers make with stakeholders is that they show them their solution after they have already built it.
In discovery, you are not only making sure that your solutions are valuable and usable (with customers), and feasible (with engineers), but you are also making sure your stakeholders will support the proposed solution.
The other big mistake I often see being made is when situations boil down to the product manager’s opinion versus the stakeholder’s opinion. In this case, the stakeholder usually wins because he or she is usually more senior. However, as we’ve already discussed many times before, the key is to change the game by quickly running a test and collecting some evidence.
The big learnings are important to share broadly, especially when things don’t go as hoped. As a side benefit, sometimes someone in the audience has an insight about what might explain the results. This is a useful and easy way for the various product teams to keep apprised of what other teams are learning, as well as ensuring that useful learnings make it to the leaders. This technique encourages the product teams to keep their focus on big learnings and not on minor experimentation that doesn’t have a real customer or business impact one way or the other.

Top Reasons for Loss of Innovation

Organizations that lose the ability to innovate at scale are inevitably missing one or more of the following attributes:

Customer-centric culture.
Compelling product vision. By the time many companies reach scale, their original product vision is now largely realized, and the team is struggling to understand what’s next. This is often compounded because the original founders may have moved on, and they were likely the keepers of the vision. In this case, someone else—usually either the CEO or the VP product—needs to step up and fill this void.
Time to innovate. At scale, it’s very possible that your product teams are entirely consumed just doing what we call keep the lights on activities. Fixing bugs, implementing capabilities for different parts of the business, addressing technical debt, and more. If this is your situation, you shouldn’t be surprised at the lack of innovation. Some of this is normal and healthy, but be sure that your teams have the room to also pursue harder and more impactful problems.