The Product Book: How to Become a Great Product Manager¶
Metadata¶
| Syntax | Description |
|---|---|
| Title | The Product Book: How to Become a Great Product Manager |
| Author | Product School, Carlos González de Villaumbrosia, and Josh Anon |
| Book on Kindle | Open in Kindle |
| Tags | #Kindle #books |
Highlight¶
“Nobody ^ref-9357 - Location: 66
Highlight¶
Put simply, a product manager (PM) represents the customer. No one buys a product because they want to give the company money. Customers buy and use products because the products address their needs. Done properly, the products let the customers be awesome. The end result of representing the customer is that a PM helps the customer be awesome. ^ref-55428 - Location: 76
Highlight¶
Day to day, PMs must understand both business strategy and execution. They must first figure out who the customers are and what problems the customers have. They must know how to set a vision, finding the right opportunities in a sea of possibilities, by using both data and intuition. They must know how to define success, for the customer and the product, by prioritizing doing what is right over doing what is easy. ^ref-15506 - Location: 82
Highlight¶
PMs manage products, not people, so they must achieve everything using soft influence, effective communication, leadership, and trust—not orders. ^ref-54322 - Location: 88
Highlight¶
Project managers are masters of schedules and Gantt charts, not of representing customers. ^ref-57604 - Location: 106
Highlight¶
Program managers tend to be masters of execution, sort of like a “super” project manager. ^ref-11554 - Location: 110
Highlight¶
Product managers are like the conductor in an orchestra. The conductor never makes a sound but is responsible for making the orchestra as a whole sound awesome to deliver a great performance to the audience. Great conductors understand and engage with everyone in the orchestra, using the right vocabulary with each section, diplomatically moving everyone together toward the shared goal of a great performance. ^ref-38212 - Location: 115
Highlight¶
The most common approach you’ll encounter is a hybrid of waterfall and lean where the PM will plan a bit upfront to find the right opportunity, but then the teams will implement the product in an iterative way. This is nice because it lets you keep a big-picture goal in mind, but change course if needed such as if you find a significant technical obstacle or find that customers don’t want the product you’re building. We’ll mainly focus on a hybrid approach in this book. ^ref-40729 - Location: 194
Highlight¶
Every product goes through five key conceptual stages: 1. Finding and planning the right opportunity 2. Designing the solution 3. Building the solution 4. Sharing the solution 5. Assessing the solution Put another way, this process involves figuring out what problem to work on, figuring out how to solve it, building the solution, getting it in customers’ hands, and seeing if it worked for them. ^ref-23718 - Location: 205
Highlight¶
The very first phase of the product-development life cycle is to find and clearly define the next opportunity to pursue. The world’s a sea of possibilities! What should you build next? Usually, it’s up to the product manager to create and sort through all the possibilities, picking the right one to focus on next. ^ref-24636 - Location: 216
Highlight¶
At a high level, company goals fall into three categories: growth, revenue, and customer satisfaction. Specifically, does the company want to get more users for the product, increase its revenue from the current customers, or make its current customers happier? If the goal is revenue, how does the company currently monetize their product, and how can you increase the value for customers to make them more willing to pay for the product? If the goal is growth, what’s stopping new customers from using the product? If the goal is to delight their customers, what can you deliver that they would love, but wouldn’t expect? By understanding the current goals you can think strategically, and make sure the products you’re building align with those goals, helping the company be successful. ^ref-28939 - Location: 230
Highlight¶
Scoping means clearly defining the opportunity and the customers you want to target, along with the requirements for the solution. ^ref-62545 - Location: 256
Highlight¶
Most companies using a hybrid model never build a true MVP, but rather an MVP with some extra key features they believe will make the product more enticing. If you know for certain customers will want those key features, incorporating them from the start will help shorten the iteration cycle. ^ref-33775 - Location: 287
Highlight¶
Product managers create a document that encompasses the entire planning phase, called a product requirements document (PRD), collecting all this planning information in one spot. A PRD contains the explanation for why you’re pursuing this opportunity, the scoped problem definition, the success metrics, and more. But you don’t create the PRD in isolation—you’ll work with your team, your boss, and other product stakeholders to make sure the opportunity and requirements are clear and the goals are achievable. ^ref-2122 - Location: 304
Highlight¶
In the hybrid model, the PRD is treated as a great communications tool to get everyone on the same page and as a living—not dictating—document. Over the product-development life cycle, the PRD will expand to contain more information, but it starts by clearly stating the problem and why we’re working on it. When the product’s built, the PRD provides a great reference for the sales and support teams to understand what’s in the product and why. ^ref-40696 - Location: 312
Highlight¶
Contrary to popular belief, design doesn’t just mean what the solution looks like. Design involves aspects like information architecture (In what order are things presented to the user?), wireframes (Where should the information live on the screen?), and pixels (How does it look?). ^ref-44881 - Location: 331
Highlight¶
Engineers hate taking on technical debt—they want to write a complete answer from the outset. If you come from an engineering background, taking on technical debt can be hard. As a PM, you’ll often have to make hard tradeoff decisions, accepting short-term debt to provide customer value faster. The opposite is true as well, which is hard for PMs from a non-technical background. You’ll have to pay off that debt later—cleaning up the code—otherwise the code can get unwieldy, and it can become very hard to iterate on the project. ^ref-26689 - Location: 357
Highlight¶
while Design will have figured out the most common use cases in the prototyping stage, there are likely many edge cases that will come up while Engineering’s building the product. Product, Design, and Engineering will work together to address these needs and questions that arise while working on the product. ^ref-51567 - Location: 363
Highlight¶
In the product marketing phase of the product-development life cycle, you figure out how to succinctly and effectively communicate how the product solves that problem and makes the customer awesome. It’s essentially storytelling, and we call it “messaging.” ^ref-2660 - Location: 390
Highlight¶
As a product manager, keeping the company’s core value proposition in mind will help you understand the company’s vision. Understanding the vision will let you understand the company’s goals, which lets you understand its product roadmap. We’re getting ahead of ourselves here! Suffice it to say, your first task when looking at a company from a product point of view needs to be understanding its “why.” ^ref-26367 - Location: 486
Highlight¶
A common question PMs deal with is, how do we pick the right goals and supporting success metrics to focus on? In general, it depends on your company. But Sarah Tavel, who was Pinterest’s founding PM for search and discovery and is now a partner at Greylock, noticed a trend in the success metrics of successful consumer-focused internet startups, and she wrote up her findings in a blog post entitled “The Hierarchy of Engagement.” Tavel noted that there are three distinct strategy phases startups, and by extension new products, go through: engagement, retention, and self-perpetuating. Startups that go through all three tend to turn into multibillion-dollar companies, whereas startups that get stuck in one phase commonly fail. ^ref-44708 - Location: 725
Highlight¶
Vanity metrics are those that sound useful, and might be great for some other business need, but don’t help us measure product performance. Actionable metrics are real data we can use to make decisions. ^ref-42226 - Location: 766
Highlight¶
NPS is measured by asking customers, “On a scale of 1–10, how likely is it that you would recommend [brand] to a friend or colleague?” Promoters rank your brand 9 or 10 and are “loyal enthusiasts who will keep buying and refer others, fueling growth.” These are the people you want! Passives will rank you 7 or 8 and are “satisfied but unenthusiastic customers who are vulnerable to competitive offerings.” Detractors score you from 0 to 6 and “are unhappy customers who can damage your brand and impede growth through negative word-of-mouth.” ^ref-31931 - Location: 793
Note¶
I've analyzed this type of feedback in previous roles.
Over time, this type of data can be really useful. However, as customers accounts grow, this can get difficult to measure, with so many customers having different needs and expectations. Some customers may use the survey to voice unrelated concerns, which may skew the results.
Therefore, using NPS method should be well monitored and worded to encourage customers to guide them in providing well-thought-out, actionable feedback that can help shape a product.
Highlight¶
Measuring NPS over time is a way to see how customers are reacting to the product changes you make (or don’t make). If your company’s goal is customer satisfaction, with NPS as your success metric, and your NPS is lower than you’d like, then your immediate product goals will be around improving your customers’ happiness. ^ref-7857 - Location: 801
Note¶
Feedback is vital in documentation. We need to know what isn't working well so that we can improve. The tricky part is, when people find issues, they tend to not report them for a variety of reasons, with the main one being they don't know where or how to report the issue. Instead, they drop off from the product and you lose someone who could have been a promoter.
Highlight¶
The key definition of an iterative change is that you’re taking an existing product and making it better. Iteration is incredibly important, as the first version of a product is never perfect for all customers, and it’s through iteration that a product evolves to become something customers love. If you don’t have product/market fit yet, we’d recommend focusing on achieving it before trying to focus on revenue or growth goals. What is also nice about iteration is that you already have information about how the customers are using the product, and your hypothesis about what to do next might come from quantitative sources (like how many users complain about a bug), or qualitative sources (like ideas the support team has). ^ref-2908 - Location: 990
Highlight¶
The downside to iteration is that you can get stuck finding the “local maxima.” This means that you’ve optimized something really well, but you focused so much on optimization that you missed a bigger shift that happened. ^ref-5894 - Location: 997
Highlight¶
Identify the key success metric supporting your goal and the metrics that support that goal. If your success metric is how engaged your customers are, you should track how often they complete the core “success” action and the steps that lead to it. If the right metrics aren’t there, then your first task for this iteration of the product-development life cycle is to implement analytics for those metrics. ^ref-10207 - Location: 1115
Highlight¶
Nearly any sequentialaction group of metrics (workflow) can form a funnel, and your goal is always to look at how a user goes from initiating to completing an action. Not every customer enters your product the same way (e.g., tapping an app on the home screen to open it the first time, opening the app for the tenth time with a restored state, tapping a link that opens the app, etc.). Your analytics tool likely has a behavior flow report to see how users enter the funnel and where they go. Any place there’s a substantial undesired falloff is a potential opportunity, and you should flag that particular metric. ^ref-46652 - Location: 1145
Highlight¶
In a feature audit, you start by creating a graph of how many people use a feature on the x-axis vs. how often they use it (See Table 3-1). When doing this, make sure to exclude “administrative” features such as password recovery, as they’ll skew the result. The core value of your product, the reason it exists and people buy it, should be at the top right (Feature C) because everyone should use it all the time. Table 3-1. A sample Intercom feature audit table. ^ref-1268 - Location: 1238
Highlight¶
Seen in Figure 3-2, the Hook Canvas has four elements. First is the trigger—what happens to get the user to the product? Second—what’s the absolute simplest thing you can get a customer to do that will give them the reward? Third—what reward can you provide that’s fulfilling and makes the user want more and invest in the product? Last, what tiny bit of action can you get the customer to invest in doing that will lead to more triggers and get them to return? Figure 3-2. Nir Eyal’s Hook Canvas and its four phases. ^ref-63410 - Location: 1265
Highlight¶
As a PM, you’re in a unique position to know what the major pain points for customers are, how they’re reacting to your product, what the technical issues are with your product, and what technical innovations have occurred within your engineering team. ^ref-12783 - Location: 1356
Highlight¶
A great PM will also be paying attention to the broader tech world, thinking about how innovations elsewhere might apply to his product and customers. ^ref-11773 - Location: 1358
Highlight¶
Stravinsky, Faulkner, Picasso…regardless of who said it, you might have heard the quote, “Good artists copy. Great artists steal.” Sometimes your competition has a great idea, and stealing it—and making it better—is your opportunity. Be careful with this source. “Because the other guy did it” is never a valid reason alone to create a feature—that’s just copying. ^ref-44354 - Location: 1409
Highlight¶
The Kano model defines three principles that a product needs to achieve to be successful over time: Value attracts customers. Quality keeps customers and builds loyalty. Innovation differentiates your product from others and keeps you competitive. ^ref-5768 - Location: 1533
Highlight¶
A SWOT analysis is a common method for looking at how an opportunity hypothesis fits in. SWOT stands for strengths, weaknesses, opportunities, and threats. This framework helps you identify the most important internal and external elements of achieving your goals. ^ref-8852 - Location: 1637
Highlight¶
To do a SWOT analysis, first identify your key goals and success metrics. Then create a two-by-two table like Table 4-1. The top row will be your internal elements—the strengths and weaknesses for the product/ company around achieving your goals. The bottom row will look at external elements—the opportunities and threats, including things like cultural, governmental, and technological trends. ^ref-5913 - Location: 1640
Highlight¶
Here’s a checklist of questions that will help you start validating an opportunity. If the answer to any of these is negative, then you should most likely not pursue this opportunity. Is this opportunity in line with our vision? Does it support the product’s vision and core function? Can we do it well with our capabilities (or is it feasible and desirable to expand our capabilities to meet the opportunity)? How does it contribute to our key metrics? Do we have any data, be it from analytics, surveys, or bug reports, to support this opportunity? Is it required to meet a critical business initiative? How does it contribute to our users’ winning? Is it on our roadmap for this year, even indirectly as part of something else? Will it matter in two years? (It’s OK if the feature is to address an immediate need, but you’ll want to limit those, as you want to prioritize things that have a higher value over time.) Will everyone benefit? If it only helps a niche set of customers, is it worth the cost? If it succeeds, can we support it? ^ref-47085 - Location: 1658
Highlight¶
So what is customer development? It’s a way to validate if the people you think are your customers truly are the right customers and confirming you’re on the right path. This includes finding out what problems customers are seeking to solve, what they’re doing right now that either creates those problems and tries to solve them, what they’re able to do (technically, financially, socially, etc.), and how they find out about and decide if a new product/feature is worth it. Fundamentally, it’s a conversation and an exchange of information. It’s also useful to know what customer development is not. It’s not a way for people to give you a wish list. It’s not a focus group to only see how people respond to ideas. It’s not a place to observe how customers use your prototype. It’s also not a replacement for product vision. Customers will give you a huge wish list, but they’ll often ask for more than they actually need, end up not using features, and —in really bad cases—might get confused by all the extra features. This is a big part of why we recommend having some opportunity hypotheses in mind first. ^ref-47639 - Location: 1774
Highlight¶
It can be helpful to explicitly write your opportunity hypothesis in terms of these canvases: “I believe that
Highlight¶
Think about the Henry Ford’s “faster horse” example here: The feature request is a faster horse. The underlying desire is the desire to get to a destination faster. Restating someone’s feature request to make sure you understand it and asking what she thinks it’d let her do or how she envisions using that feature is an easy way to start to get to the underlying desire. ^ref-62742 - Location: 1857
Highlight¶
It usually takes 5 to 10 interviews to fully get into the zone, and unless you’re changing your questions, 15 to 20 interviews is usually when you stop hearing new things. ^ref-48061 - Location: 1964
Note¶
I've heard 15 people are enough for a study/interview group, but I've also heard 5 people are enough.
With sufficient knowledge and research, I'd lean towards 5-10 people as sufficient. By interviewing fewer people, we can reduce the cost of the study, in terms of pre-interview preparation, the actual interview, and post-interview content review.
Highlight¶
The last type is a fake door MVP. If you’re thinking about building a new feature into your product, add the UX elements you’d use to trigger the interaction, but rather than actually delivering the feature, provide a notification that the feature’s coming soon. See how many people use your “fake door.” For example, if your hypothesis is that people would find a live group chat feature useful on your online education site, add a “Chat” button and see how many people click it. If only a tiny percentage do, reconsider if it’s worth pursuing this opportunity, depending on the value of those customers vs. the cost of implementing the feature. ^ref-6838 - Location: 2151
Highlight¶
A simple way to compare priorities is to come up with a value vs. cost number. Work with an engineering lead to put difficulty values on different opportunities. From your customer-development work and other internal analysis, create business-value numbers for each opportunity. Use higher numbers to indicate more expensive cost, or more valuable. Because it’s tough to estimate value and difficulty precisely, use an exponential series rather than a linear one—i.e., use 1, 2, 4, 8, and 16 rather than 1 through 5. This way, it’s very clear when one opportunity is harder or more valuable than another. Next, for each opportunity, figure out a score using score = value÷cost. Focus on the highest-scoring opportunities first, as they provide the most value for the lowest cost. ^ref-60278 - Location: 2173
Highlight¶
Before we go further, let’s clear up a big misconception about MVPs. Minimum doesn’t mean bad. Your product is still going to be designed and engineered well, tested thoroughly, and, most importantly, it will deliver value to the user. It should be a product that people are willing to buy and use. Even if it’s not fully featured, it should work well enough that it becomes your customers’ go-to solution. ^ref-64825 - Location: 2346
Highlight¶
We love MVPs because they let you focus on delivering a product your customers want and will use. But remember, minimum doesn’t mean bad. You need to be continuously seeking ways to make sure what you’re doing is great. In Chapter 3 we talked about the Kano model, and we introduced the idea of delighter features, features that customers don’t ask for but that deliver a huge return in customer satisfaction. ^ref-59464 - Location: 2384
Highlight¶
Disney historian Les Perkins tells a story from the early days of Disneyland. Walt was holding a Christmas parade, which cost $350,000. His accountants begged him not to spend that money, because people would already be in the park. Walt’s reply was, “That’s just the point. We should do the parade precisely because no one’s expecting it. Our goal at Disneyland is to always give the people more than they expect. As long as we keep surprising them, they’ll keep coming back. But if they ever stop coming, it’ll cost us ten times that much to get them to come back.” ^ref-10020 - Location: 2392
Note¶
Intriguing and possibly even conservative in the part "it will cost is ten times that much to get them to come back."
Highlight¶
The PRD is a tool for everyone involved in the product. At first you’ll use it to get all the key stakeholders on the same page and help the team understand the project. Having an initial PRD can be reassuring and inspire confidence in your project, as it’s clear to others in the company that you have an idea for where to take the project. We believe that, throughout the project, the PRD should be the project’s home page—or at least the very first link on the project’s homepage. As you near release, your support and sales teams will use it to find out everything they need to know about the product. And when you’re done, it’s a historical reference for why you made certain decisions. ^ref-64939 - Location: 2422
Highlight¶
Breaking Down a PRD ^ref-27145 - Location: 2433
Note¶
Thos section is helpful and may be useful for myself or others to refer to in the future when writing a PRD.
Highlight¶
The design process generally breaks down into six primary phases: User research Information architecture Interaction design Prototyping Visual design Content strategy ^ref-60247 - Location: 2934
Highlight¶
So how do you build a constructive relationship with the design team? A simple but important step is to get to know the team. Building individual relationships with the people you work with will help you respect each other as people and deal with conflict more productively. ^ref-36370 - Location: 3116
Note¶
I wholeheartedly agree with this statement. However, relationships with co-workers is incredibly difficult to do in a remote workplace or within a remote team. There really is no substitute for in-person relationship building and communication.
Highlight¶
You might have everyone work individually to generate ideas using “Crazy Eights,” where you fold a piece of paper in half three times, to create a page with eight segments, and take five minutes to draw eight ideas, one per segment. ^ref-30433 - Location: 3229
Note¶
I like this idea. It’s engaging and eventually builds trust amongst a team to be vulnerable and show designs that may not fit with the solution that the team needs to make.
However, I think this really mostly works in an in-person environment. I think doing this remotely might be a little awkward and not build the repertoire necessary for a project to succeed.
Highlight¶
Despite the various criticisms, the Standish Group, an IT advisory center, tracked 50,000 projects from 2011 through 2015 and found that the success rate (shipping a working product) of agile products was 39% vs. 11% with waterfall. That’s a huge difference, but note that even with agile 61% of projects don’t have a working product by the end. ^ref-19860 - Location: 3447
Highlight¶
Furthermore, we like writing backlog tasks as user stories because that format helps explain why something is an issue so that Design and Engineering can determine the best approach to address the issue. ^ref-43957 - Location: 3470
Highlight¶
Finally, remember that your message is not about what the product does, it’s about what the product lets the customer do. Customers buy your product to make their lives better. Make sure your message clearly highlights how your product will help your customers improve their lives. ^ref-19193 - Location: 3856
Highlight¶
If a launch wasn’t well received, you should still recognize the effort that went into it, as you want the team to have a positive attitude when working on the next iteration of the product. ^ref-31626 - Location: 4248
Highlight¶
Assessing how things went ensures that you gather feedback, letting people feel their concerns are heard, and think about how to do better in the next cycle. ^ref-9923 - Location: 4258
Highlight¶
For some people, assessing how things went during the development cycle is very difficult, personally. This is when you explicitly put yourself out there and ask for feedback, and you will get feedback, both positive and negative. ^ref-47433 - Location: 4260