More on this book
Community
Kindle Notes & Highlights
by
Marty Cagan
Read between
March 20 - April 24, 2021
The most striking thing we learned was that in so many companies—even companies trying to do true, technology‐powered products and services—product teams were too often not allowed to work the way they needed to.
The technology people are divided up into teams where they feel like they aren't responsible for anything meaningful, they can't do much without depending on changes from several other teams, and that they're just a small cog in a giant wheel.
Leadership is about recognizing that there's a greatness in everyone, and your job is to create an environment where that greatness can emerge.
At the core, I see three critically important differences between the strongest product companies and the rest: The first is how the company views the role of technology. The second is the role their product leaders play. The third is how the company views the purpose of the product teams—the product managers, product designers, and engineers.
in strong product companies, technology is not an expense, it is the business. Technology enables and powers the products and services we provide to our customers. Technology allows us to solve problems for our customers in ways that are just now possible.
in strong product companies, the purpose of the product team is to serve customers by creating products customers love, yet work for the business.
the “product strategy,” if you could even call it that, is really about trying to please as much of the business as possible.
while moving to truly empowered teams does require moving away from the old command‐and‐control model of management, it does not mean you need fewer leaders and managers. It means you need better leaders and managers.
It's not hard to assign a team a list of activities, or a list of features to build, and just tell them to do the work as fast as they can.
a focused and compelling product strategy—based on quantitative and qualitative insights—is among the most important contributions of product leadership.
in strong product companies, teams are instead given problems to solve, rather than features to build, and most important, they are empowered to solve those problems in the best way they see fit. And they are then held accountable to the results.
In the empowered product team model, the product manager has a clear responsibility, which is to ensure that the solutions are valuable (our customers will buy the product and/or choose to use it), and viable (it will meet the needs of the business).
Together with a product designer who is responsible for ensuring the solution is usable, and a tech lead who is responsible for ensuring the solution is feasible, the team is able to collaborate to address this full range of risks (value, viability, usability, and feasibility). Together...
This highlight has been truncated due to consecutive passage length restrictions.
There are two fundamental reasons why our customers and stakeholders aren't able to tell us what to build:
the customers and stakeholders don't know what is just now possible—they are not experts in the enabling technologies, so they can't be expected to know the best way to solve the problems we're focused on, or even if the problem is possible to solve.
with technology products, it's very hard to predict in advance what solutions will work. There are many reasons why product ideas don't deliver the results we hoped. All too often we are excited about some idea, but our customers are not, so they don't buy what we thought they would. Or, we discover the idea has major privacy or security issues. Or we find out the idea will take much longer to build than anyone expected.
We refer to this as product discovery to acknowledge that we understand what we can't know in advance, and to emphasize that our task is to discover a solution that is valuable, usable, feasible, and viable.
It's not that these CEOs don't admire what companies like Amazon and Netflix and others have done—they generally do. It's that they don't see how these lessons apply to them.
many leaders are also managers, and many managers are also leaders, but even if both roles are covered by the same person, there are different responsibilities.
we look to leadership for inspiration and we look to management for execution.
If product teams are to be empowered to make good decisions, they need to have the strategic context necessary to make those decisions.
product leadership has four major explicit responsibilities:
Some companies refer to the product vision as their “North Star”—in the sense that no matter what product team you're on, and whatever specific problem you're trying to solve, you can all see and follow the North Star. You always know how your piece contributes to the more meaningful whole.
principles reflect the values of the organization, and also some strategic decisions that help the teams make the right decisions when faced with difficult trade‐offs.
The larger the organization, the more essential it is to be very good at evangelism, and it's important for the leaders to understand that evangelism is something that is never “done.” It needs to be a constant.
If you want to have truly empowered product teams, then your success depends very directly on these first‐level people managers.
even if that designer is exceptionally skilled, how can she be expected to keep track of what is going on with all the other product teams? What if the design she is working on right now for her situation is in some way inconsistent or incompatible with solutions underway with other teams? The design manager is expected to flag these conflicts and get the relevant designers together to consider the bigger picture and the impact of the different solutions on the user.
It takes strong managers to be self‐confident and secure enough to truly empower the people that work for them, and to stand back and let the team take credit for their successes.
While quite a few these books are inspiring and well worth reading, most companies have not been convinced to empower their teams in any meaningful sense.
When I ask this question of CEOs and other key leaders of these organizations, the answer typically boils down to one word: trust. The leaders don't trust the teams. Specifically, they don't believe they have the level of people on their teams they need to truly empower them. So, along with the other key business leaders from across the company, they believe they need to very explicitly direct the teams themselves. This is also known as the “command‐and‐control” model of management.
Coaching is no longer a specialty; you cannot be a good manager without being a good coach.
Coaching is what turns ordinary people into extraordinary product teams.
Nurturing a team that allows for diverse points of view begins with the hiring process where you consider your team as a portfolio of strengths and backgrounds.
I'm not suggesting you encourage consensus of opinion within your team. Rather, as a manager, you are helping your team learn how to make good decisions collaboratively—leveraging the skills and expertise of each person.
I've always found that trust grows whenever a working relationship is humanized.
In this chapter, I will describe a coaching tool for helping managers of product people raise the level of performance of the people that report to them.
the taxonomy I like to use when talking about product is the three pillars: people, process, and product.
strong product managers are always developing their skills and learning new and more‐advanced techniques. Much like a good surgeon is constantly following the latest learnings on surgical skills and techniques, a strong product manager always has more to learn in terms of skills and techniques.
People skills are similar to product knowledge in that if you don't have a solid foundation, it is very hard to do the PM job at all. Yet, as with process skills, strong product managers constantly work to improve and develop their people skills.
a product manager that does not have this level of knowledge has no business serving as product manager for her team. And the responsibility for ensuring this level of competence is squarely on her manager.
unless you have a full‐time data analyst or data scientists embedded in your product team, they are not there for you to delegate work to them. They are there to educate and empower you to answer questions with data.
The PM is not expected to become as knowledgeable about the domain as these experts, but she does need to learn enough to engage and collaborate effectively.
The go‐to‐market strategy is an essential aspect of every product. This describes how our product makes it into the hands of users and customers.
This topic really should be obvious, but I can't tell you how often I meet a product manager who doesn't actually know their own product beyond how to give a basic demo. But hopefully it's clear that a product manager must be an expert user of her own product in order to be trusted.
the difference between being just a competent PM, and a truly effective PM, is often their skills with people.
for most but not all people, you can significantly improve and develop their people skills. But they do have to want to improve.
Leadership skills are especially important for the PM because the product team and the stakeholders don't report to you, so you must depend on persuasion and leadership.
I encourage all product managers to become lifelong students of leadership. Most of us know people we consider terrible leaders. Some of us are lucky enough to know people we consider exceptionally strong leaders. Discussing the defining characteristics of each makes for excellent coaching discussions.
I always encourage tech leads to visit as many customers as they can. But I also try to make a point—after visiting an interesting customer myself—to stop by and chat with the tech leads about what I saw and learned, and what they might think about that.
Design managers ensure a holistic view by reviewing designs at the weekly one‐on‐ones and by holding design sessions with the broader group of product designers, especially to discuss difficult design problems.

