More on this book
Community
Kindle Notes & Highlights
by
Marty Cagan
Read between
December 3, 2020 - January 7, 2021
People Skills and Responsibilities
Team collaboration skills—How effectively does the product manager work with her engineers and product designer? Is it a collaborative relationship? Is there mutual respect? Is the product manager involving the engineers and designer early enough and providing them direct access to customers? Is the product manager fully leveraging her team's skills and minds?
Stakeholder collaboration skills—How good is the product manager at collaborating with her stakeholders across the company? Do they feel like they have a true partner in product that is genuinely committed to their business success? Has she established mutual respect and mutual tr...
This highlight has been truncated due to consecutive passage length restrictions.
Evangelism skills—Is the product manager able to effectively share the product's vision and product strategy, and motivate and inspire her product team as well as the various stakeholders and others in the company...
This highlight has been truncated due to consecutive passage length restrictions.
Leadership skills—While the product manager does not actually manage anyone, she does need to influence and inspire people, so leadership skills are important. Is she an effective communicator and motivator? Do her team and stakeholders ...
This highlight has been truncated due to consecutive passage length restrictions.
your company has a user research team, that's my favorite place to start, and it is a valuable relationship for the product manager to establish. User researchers are there to educate you—they know if you don't truly grok the issues, then you won't fix them.
Next, if you have a customer success or customer service team, that is a terrific resource. You want to learn who their favorite customers are, and their least favorite, and why. You will also want to spend quality time with this team to understand more about how customers perceive your product. But for now, you want to learn what they can teach you about your users and customers.
You're not only looking for happy customers, just as you're not only looking for unhappy customers. You're after as many perspectives as you can get.
With every interaction, at the very least, you're looking to learn: Are the customers who you think they are? Do they have the problems you think they have? How do they solve that problem today? What would it take to get them to switch?
When I coach product managers on competitive analysis, I like to ask the PM to evaluate the top three to five players in the space and to write up a narrative comparing and contrasting the strengths and weaknesses of each player—highlighting opportunities.
One way I like to get started on this is to have the new product manager fill out a business model canvas (any of the variants are fine for this) for their product. It is a quick and easy way to help the product manager quickly realize the areas she may not yet understand.
product manager must be an expert user of her own product in order to be trusted.
Coming up to speed on this typically involves reading whatever user or customer documentation exists, taking whatever training classes may exist, spending time with customer service staff, and if at all possible, using your own products on a daily basis (this is known as dogfooding).
At a minimum, the new PM must understand the four different types of product risk (value, usability, feasibility, and viability), the different forms of prototypes to tackle these risks, and how to test those risks qualitatively and quantitatively.
For products that are in production and have significant traffic, there are important techniques referred to as product optimization techniques that the product manager needs to understand and know how to effectively utilize. This typically involves learning one of the commercial tools and then running an ongoing series of A/B tests—mostly to optimize the product funnel, but it could be used for other purposes as well.
the CSPO responsibilities, while important, are just a very small subset of the responsibilities of the product manager of an empowered product team.
the difference between being just a competent PM, and a truly effective PM, is often their skills with people.
Modern product management is all about true collaboration between product, design, and engineering. This begins with ensuring the product manager is knowledgeable about the real contribution of product design and engineering.
A one‐hour meeting discussing a problem or objective will usually yield many good examples I can use as a coaching opportunity for the PM. How engaged is the rest of the team? Are they acting like they are empowered to solve the problem, or are they acting like order takers? Is the designer and engineer bringing potential solutions to the table or just pointing out issues with whatever the PM proposed? Are they spending too much time talking (e.g., planning) and not enough time trying (e.g., prototyping)? How are they resolving differences of opinion?
There are additional dynamics at play with stakeholders. First of all, while most PMs are individual contributors, most stakeholders are company executives. They are often very knowledgeable about their part of the business, and they are often used to giving orders. The key to successful working relationships with stakeholders is establishing mutual trust. For the PM, that starts with putting in the time and effort to understand what each of the stakeholder's constraints are.
Especially in medium to large‐sized companies, so much of product involves persuasion. This involves convincing your team and your stakeholders that you understand what you need to do, and you've got a solid plan to deliver. My favorite technique for developing a strong and compelling argument is the written narrative, which is discussed in Chapter 11, The Written Narrative. I also encourage PMs to take a presentation skills class where your presentations are video recorded and you are provided professional critiques. I've personally taken this class twice over my career and consider it
...more
A tech lead is essentially a senior‐level engineer who has taken on the additional responsibility of participating in the ongoing product discovery work. The tech lead is the key partner to the product manager and product designer. They are asked to care not just about building and delivering reliable products, but also to care about what gets built. Tech leads bring deep knowledge of the enabling technologies, and when that knowledge is combined with a direct understanding of the customer's pain and problems, magic can result. If you've spent any real time with engineers, you know that not
...more
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.
Every person is different, bringing different experience and knowledge to the job. In Chapter 8, The Assessment, I discussed a tool I use to quickly assess a new product person to determine which areas to focus on. But, until the product person is strong enough to be considered competent, it is your responsibility to ensure the person is not doing harm to her team and is making reasonable decisions.
This is one of those areas where there's a range of opinions out there, but I feel strongly that the 1:1 should be no less than 30 minutes, once per week, and that this session is sacred and not to be another one of those “You okay with skipping this week?” kind of meetings. You may need to occasionally reschedule, but don't cancel. Please consider the message this sends.
If you are to empower your product person to solve problems in the best way her team sees fit, as a leader and manager you must provide her with the strategic context.
This means making sure she understands the company's mission and objectives for the year, the product vision, the product strategy for the broader product, and the team objectives for her particular product team.
What does homework really mean? For a product manager, it means learning the product inside and out. Learning about the users and customers. Learning the data. Learning the capabilities of the enabling technologies. Learning the industry. Learning the various dimensions of the business, especially financial, sales, go‐to‐market, service, and legal.
What does it mean to think like a product person? It means focusing on outcome. Considering all of the risks—value, usability, feasibility, and business viability. Thinking holistically about all dimensions of the business and the product. Anticipating ethical considerations or impacts. Creative problem solving. Persistence in the face of obstacles. Leveraging engineering and the art of the possible. Leveraging design and the power of user experience. Leveraging data to learn and to make a compelling argument.
What does it mean to act like a product person? Listening. Collaborating. Shared learning. Evangelizing. Inspiring. Giving credit and accepting blame. Taking responsibility. Knowing what you can't know and admitting what you don't know. Demonstrating humility. Building relationships across the company. Getting to know customers on a personal level. Leading.
The best product leaders measure their success in how many people they've helped earn promotions, or have moved on to serve on increasingly impactful products, or to become leaders of the company, or even to start their own companies.
The performance review is discussed in an upcoming chapter, as it's the source of lots of grief and angst for all parties. But, for now, the important thing to keep in mind is that it is never the key tool for developing people—the weekly 1:1 is.
in a two‐sided job marketplace, we would have at least two funnels—one to bring in job seekers and one to bring in employers—and we'd closely watch the key metrics for each funnel.
The company scorecard captures these business dynamics. It does not focus on every metric, but it focuses on the most important and informative metrics. It is how the leaders of the company judge the overall health and performance of the company.
Ultimately, the way we deliver on a company's mission is to develop products and services for our customers. The product vision is how we hope to do that.
The mission may provide the purpose, but it's the vision that begins to make this tangible. It's worth noting that the product vision is also our single best tool for recruiting strong product people.
Why? Because teams do much better work when given the context and a problem to solve, rather than describing to them the so‐called requirements of a solution.
was told that, in order to do this, I'd need to “do my homework”—customers, data, business, and industry (a phrase I've repeated literally thousands of times). Why? Because the designer and engineers need someone on the team with this knowledge and context and this would be my direct contribution to solving the problems the team has been assigned.
I was told I had to commit to figuring out a way over whatever obstacles would arise, and to expect that many would indeed arise. Why? Because technology products are never easy. I remember the actual phrase: “There will always be many good reasons not to ship, and it's your r...
This highlight has been truncated due to consecutive passage length restrictions.
I was told that my performance would be measured by results (a phrase popular again today, but that was literally the tagline for HP in the 1980s). Why? Because we need to be careful never to confuse output with outcome...
This highlight has been truncated due to consecutive passage length restrictions.
I was told that to succeed meant that I'd have to work hard to establish and maintain relationships with people from all across the company whom I'd need to depend on—and who would depend on me. Why? Because in a company, especially a large company, there are many people there to ensure that the assets are protected—the sales force, the revenue, the customers, the reputation—and getting things done in a company ...
This highlight has been truncated due to consecutive passage length restrictions.
was told that the leaders of the company would be continuously judging me to decide if they felt I had done my homework, if I was thinking and acting like an owner, and if the product team was in good hands. Why? Because executives of companies with the empowered te...
This highlight has been truncated due to consecutive passage length restrictions.
I was also told I'd have to take responsibility when things didn't go well, yet give credit to the team when things did go well. Why? Because that'...
This highlight has been truncated due to consecutive passage length restrictions.
I was told that it was my responsibility to motivate and evangelize my team. Why? Because we want a team o...
This highlight has been truncated due to consecutive passage length restrictions.
Finally, as most product people have heard many times before, I was told that I'd have the responsibility to ensure success but not the authority to direct people. Why? Because innovation depends on true collaboration with design and engineering, which is a peer relationship and not a reporting r...
This highlight has been truncated due to consecutive passage length restrictions.
If I had to boil it all down, I'd say that thinking like an owner versus thinking like an employee is primarily about taking responsibility for the outcome rather than just the activities.
Your highest‐order contribution and responsibility as product manager is to make sure that what the engineers are asked to build will be worth building. That it will deliver the necessary results. This means working with designers and engineers to come up with solutions that are valuable, usable, feasible, and viable. That is product discovery, and that is what takes on the order of four solid hours a day. I encourage product managers to block off this time for the week, and protect that time, and then you still have half a day for other stuff.
If the product manager thinks like an owner and not like an employee, and commits to an outcome rather than just a list of activities, then this is really about delivering results.
Second, we also need to recognize that acquiring knowledge and applying knowledge are two different things.
