Five Unusual Things Marty Cagan Said About Product Management That I Can’t Stop Thinking About
It was over a week ago that I chatted with Marty and a small group of product managers. As someone who has read a few product management books over the years, Marty still surprised me with his fresh perspective and somewhat contrarian opinions (see: OKRs aren’t for everyone below). I caught myself ruminating about our conversation at random moments even several days later, so I figured I’d share them here.
From Netscape to eBay, Marty Cagan has coached some of the best product managers from the most influential companies in the world. I consider his two books, Inspired: How to Create Products Customers Love and Empowered: Ordinary People, Extraordinary Products, foundational readings for any product manager in the 21st century.
Read on for the five things that I can’t stop thinking about:
1. Most teams don’t have a BAD product strategy. They simply DON’T HAVE a product strategy
The smaller the number of employees in a company, the more important strategy is for the survival of the company. Why? If you are an entrenched business with, say, 200 engineers, you can get away with having no strategy for a few years because any mistake won’t hurt as much (until it’s too late, that is). For startups, you must make sure the strategy is there, as every move is critical to the survival of the company.
Solution: First, consult the data. Understand the direction of your product and how your customers are reacting to it. Then, use this data to assign customer problems for teams to solve.
2. OKRs only work for empowered teams
Although it’s become a highly common practice, OKRs have had a disappointing track record of delivering good products and results. The truth is, not every company should be using OKRs.
OKRs only work when assigned to an empowered team. If you assigned OKRs to a feature team, there is significant dissonance. Assigning OKRs to feature teams is like saying, ‘here’s the problem, oh, and also, here are all the features you need to build’. It defeats the purpose of OKRs.
Solution: The failure of OKRs is ultimately leadership’s fault —before they an introduce OKRS, a company first needs to change their culture to produce empowered teams.
3. Having a team set aside as the ‘innovation team’ is a bad idea
Many large companies have a dedicated group of people whose job it is to ‘innovate’. However, there is a lot of good evidence that these do NOT work.
Why? Imagine this: the innovation team comes up with an idea, hands it over to a product team, and they receive pushback. We don’t believe you and your data, the product team says, nor do we think you understand the product. At best, the innovation team becomes somewhat of an in-house consulting team. Further, having a separate innovation team implies that all other teams don’t need to innovate. Clearly, the goal is for every team to be innovative.
Solution: Risk delegation. It is perfectly reasonable to ask certain product teams within the company to take more risk while others focus on stability. This kind of ‘innovation delegation’ is more of a risk management technique and works better than having an innovation team.
4. To help engineers care about the product, show them how customers react to their product
Some engineers will insist that they don’t want to be involved with the product strategy, and that they only want to code. This is not a good sign — engineers are a key source of good product ideas, so smart companies typically screen for engineers can do more than just code. How can you get your engineers to care more?
Solution: Understand that no engineer wants to see their products being disliked by the user. After repeated exposure of customer feedback, it is only human for the engineer to start caring. Note that you don’t need every engineer on your team to care — a handful should suffice. It is the PMs job to to help empower their engineers.
Note: If truly no one cares, go to the tech manager. Often, when engineers are not empowered, it is because the CTO isn’t really a CTO — they are a CIO. These two roles are very different!
5. Business strategy should not be the same as product strategy
The business strategy provides a budget and business metrics, and the product organization works within the confines of that budget and pursues those business metrics as aggressively as possible.
Business strategy typically comes from the board and executives. A product manager’s role is to come up with critical customer insights and figure out which products to build. Senior executives should not be making decisions at a level far below what they’re comfortable with (or usually even interested), like which specific features to build and what tests to run. On the other hand, product managers should not feel confused about the decisions that impact their product and should feel empowered to do their jobs.
Solution: Keep these two concepts well-defined and responsibilities clear. The business owners and senior executives are responsible for the business strategy, and the product team is responsible for the product strategy.
Note: one person to follow that can speak about product v. business strategy at length is Ben Thompson, the founder of Stratechery.
Bonus Cartoon
Because you made it all the way to the end 👏
Thanks for reading!
Want to learn more about Marty Cagan? Check out his company, Silicon Valley Product Group: https://svpg.com/
Louise Lai is a product manager at Walmart Labs working on the future of retail. LinkedIn: https://www.linkedin.com/in/louiseylai/
