The Product Book: How to Become a Great Product Manager

Book by Josh anon and Carlos Gonzales De Villaumbrosia

Those are my notes from the book, highlighted from the book while reading it.

School, Product; González de Villaumbrosia, Carlos; Anon, Josh; School, Product. The Product Book: How to Become a Great Product Manager Product School. Kindle Edition.

Introduction

One of the most important parts of being a product manager is knowing who your customers are and what they need. p1

Chapter 1: What is product Management?

What do product managers do ?

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. p4

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. p4

PMs manage products, not people, so they must achieve everything using soft influence, effective communication, leadership, and trust—not orders. p4

Project managers are masters of schedules and Gantt charts, not of representing customers. p6

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. p6

Becoming a PM

the role often comes down to “doing whatever it takes to ship a product that customers will love and that achieves business goals,” p7

The product triangle p8

PMs frequently rely on a way of thinking common to coding—top-down design and bottom-up implementation. This means that you think about the big picture, break it down into small pieces, and then build those small pieces first. p9

They should understand the industry of the company they’re interested in and be able to answer the following questions: Who are the customers? Who are the major players? What differentiates one company from another? How do the businesses make money? PMs should also understand basic financial concepts p9

The lean methodology focuses on very fast, iterative cycles where your goal is to make something small, release it, learn from it, and use that knowledge to figure out what to do next. Lean cycles might happen in just a few days. p11

The Product-Development Life

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

p12

Finding and Planning the Right Opportunity

Clearly identifying the company’s goals, another strategic element, will help you narrow down and prioritize the possibilities. 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? p14

In addition to these, there are some other strategic company context questions you should know the answer to: What is the company building now? What does it excel at compared to its competitors? Who are the key customers you aim to solve a problem for? What’s the company’s vision, and—more fundamentally—why does the company exist? p14

These opportunity hypotheses come from many different places. Looking at how existing customers use your product is a common source of new opportunities, allowing you to find ways to better serve your customers—and your company’s goals. p14

Scoping means clearly defining the opportunity and the customers you want to target, along with the requirements for the solution. p14

Identifying the MVP is a key part of scoping a product because it helps you identify the most important thing to build first— p14

an MVP doesn’t mean the product is bad or poorly built. In fact, quite the opposite—it should be very good at what it does, but it should focus on doing only a few key tasks. p16

Just as important as scoping the problem is defining your success metrics. What are your goals with the product, and how do you keep score to see if you’re achieving them? p18

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. p18

the lean model largely doesn’t use PRDs. 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. p19

Designing the Solution

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?). p20

Suffice it to say the PM will stay involved throughout development, helping to prioritize bugs (backlog grooming), test software, and do whatever’s needed to help the product ship. p21

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.” p24

Chapter 2: Strategically understanding a company

Analyzing a company breaks down into three main categories: What product are we building? How do we know if our product’s good? What else has been, is being, and will be built? p27

What Product Are We Building?

Why does the company exist?

The most fundamental thing to understand about a company is why it exists. What’s its mission statement or, even more importantly, its core belief: the value it adds to the world that differentiates it from other companies? p27

Put another way, the products you build are a means to an end. That “end” is the bigger picture and what customers buy into/want to achieve when they buy your products. Think about storytelling—the “why” is the theme. What’s this story about? What specific viewpoint does the writer want to share with the world that led to her writing the story? p28

Simon Sinek golden circle p29

“Why” is at the core of the Golden Circle because it’s the most fundamental thing you need to understand about a company. Everything a company does, from the products it builds to the feature decisions it makes for those products, should emerge from that value. p30

Google writes its mission statement as, “To organize the world’s information and make it universally accessible and useful.” There’s an implicit value proposition of driving the human race forward, which Google does, primarily with data. p30

Customers will pay for your product because it makes their lives better, not because they want to give you money. p30

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. p31

Customers and Personas

The most fundamental part of a company, after why it exists, is who it’s solving problems for. Essentially, who are the customers for your product, and why are they buying your product? You will optimize your products for these people. p31

persona is a fictional, typical customer, and defining key personas lets you segment your customers by highlighting the things your customers care about that are relevant to your product. Personas are tools to help you understand your customers, they are not actual end customers. p32

Good personas will have a picture and a fictional name. They will include any relevant details about the person’s life such as demographics, outside activities, and common tasks, as well as what problems the person is looking to solve. Think of a full persona as a way to bring a typical customer to life— p32

Roman Pichler’s persona-building template p33

Keep them as sparse as possible overall, but with enough detail that they’re believable and represent a real target market. If you’re wondering how to do this, write a detailed persona, and for every statement you make about the person, if it’s not relevant to your product, delete it. p34

What extreme pain points does he have and what pain points are insignificant? What are the things he must have from any solution you create? p34

A way to envision these customer’s priorities is to imagine the customer’s journey. What problem is a given persona trying to solve, what does he do when he tries to solve it, and what happens as a result? Tell us a story about the customer. p34

product theory and practice have shown that focusing on a common problem, pain, or desire yields better segmentation than demographics. p35

Sometimes the customer and the buyer—the person using the product and the person actually purchasing it—aren’t the same, such as parents buying a swing set for their kids. p36

Whenever you start working on a new product or at a new company, find out as soon as possible who the relevant personas are. Make sure they’re clearly written down in the Name/Picture/Details/Goals format. p36

Market adoption curve p39

Whenever you think about how to make a product better, your first thoughts should be about who the target personas are and what needs they have that aren’t currently being met by the product. p39

Chapter 2 tips

Great product managers can put themselves into the mindset of the persona, and really get into his/her skin to understand the wants and needs and, most importantly, the emotional triggers of their users. And truly great product managers will cycle through many different personas as they consider the product’s core needs. This process determines the subtle differences that can take good products and transform them into exceptional ones. p41

Use case

Use cases are simply how a company expects each persona to use the company’s product to achieve a goal. They provide the context to let you understand the link between your personas and your products. p43

For example, a key use case for an iPhone is checking your email on the go. Apple will make product decisions for the iPhone that help you know when you have new mail, and let you reply to mail, compose new mail, etc. p43

By focusing on specific use cases for specific personas, you can ensure that your product addresses the needs of those personas effectively, which makes your end customers happy. p44

Enterprise vs. Consumer Companies

B2B involves more decision makers, and the people who decide to buy the product are often not the ones using it— p44

B2B software also historically emphasized utility over usability: that is, as long as it solved your problem, it’s OK if it’s really painful to use. However, B2B technology has shifted to focus more on the end customer rather than just the decision maker. As we’ve seen with Slack, Gusto, and more, B2B companies are acting more like B2C companies, creating software with intuitive design that you can use out of the box with little training, just like you don’t need training to use Facebook. p45

How Do We Know If Our Product’s Good?

a big part of product management is knowing how we keep score. Metrics, in particular success metrics, are how we measure that score. p45

While product management sometimes feels like more of an art than a science, metrics provide the data-driven, scientific backbone to product management. Your success metrics are defined by your current strategy and goals. Overall company success metrics come from the company’s short-and long-term strategy goals, with long-term metrics being defined by the company’s core values—the “why” p46

it’s common to see companies switching their short-term goal from growth (people are using our product) to revenue (people like our product enough to pay for it). p46

Maybe your current company success metric is brand awareness, a common initial success metric for startups. p46

Later on, your strategy might shift to making your app part of people’s lives, in which case your success metrics will focus on engagement: p46

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. p47

The goal of the first phase is to get customers using your product and completing the core action, like posting a photo to Instagram. This is a sign they’re engaged with your product, p47

After companies saw good engagement—what “good” means varies—they’d shift towards retaining users with success metrics around how frequently those customers use the product in a given time period. p48

Vanity vs. Actionable Metrics

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. Let’s look at an example, using Tavel’s first phase, engagement. When you’re launching a new product, say an app, as a product manager your goal is to have people completing the core task. Maybe 1 million people downloaded your app on the first day—congrats! That sounds awesome, right? While getting someone to be aware of and download your app is the first step, it doesn’t mean they actually opened and used your app—things look very different if only 10 people actually completed your app’s core task. Numbers like page views and downloads are vanity metrics because they sound useful. They might be useful in investor pitch decks, negotiating display-ad prices, 1 million people look at our pages each day!, and for other company needs. But from a product management point of view, they don’t help us measure if our product is successful. p51

How to Measure Metrics

Early on when planning a product, you’ll want to think about what metrics you want to capture and work with your development team to capture those metrics p52

Net Promoter Score

The Net Promoter Score (NPS) is a metric developed by Satmetrix, Bain & Co., and Fred Reichheld. It’s a high-level way to gauge overall customer satisfaction with your product by seeing how likely customers are to recommend it to others, on a scale from –100 to 100. p52

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, Detractors score you from 0 to 6, the NPS is the percentage of promoters minus the percentage of detractors, giving you a score from –100 to 100. p53

What Else Has Been, Is Being, And Will Be Built?

roadmap. A roadmap is a document that shows what the company/product is doing now, what the company/product plans to do over the next N months, what the company/product plans to do later, roughly how much effort each high-level task will take, what products the company will create, and what features they will have, etc. p54

Roadmaps are often fairly detailed in the short term—short term being 3 to 6 months for most software, 6 to 12 months for large software projects, and 12 to 18 months for hardware—and become more vague over the long term. p54

Competition and Climate

The last element to think about when trying to understand a company is what’s going on around that company: What are other people building? Who are the company’s main competitors? How are their target use cases, personas, and end customers different? How are their products different? How are they winning or losing compared to another company? Are you aware of who’s out there? p56

what’s going on in the industry in general? Has some broader invention or change caused every company to drastically alter its plans? p56

A 5C Analysis

There’s a framework called 5C that’s similar to the areas we just covered.

• Company: This refers to the company’s experience, technology, culture, goals, and more. It’s similar to the material we covered in the “Why Does the Company Exist?,” “How Do We Know If Our Product’s Good?,” and “What Else Has Been, Is Being, and Will Be Built?” sections.
• Customers: Who are the people buying this product? What are the market segments? How big are they? What are people’s goals with buying this product? How do they make buying decisions? Where do they buy this type or product? This is similar to what we covered in the “Customers and Personas” and “Use Cases” sections.
• Collaborators: Who are the external people who make the product possible, including distributors, suppliers, logistical operators, groundwork support personnel, and so on?
• Competitors: Who is competing for your customers’ money? This includes actual and potential competitors. You should look at how they position their product, the market size they address, their strengths and weaknesses, and more.

• Climate: These are the macro-environmental factors, like cultural, regulatory, or technological trends and innovations.

p57

Chapter 3: Creating an Opportunity Hypothesis

A key part of your role as a product manager is understanding your customers and their problems and needs, and making sure what you’re building next is right for them, p61

It’s OK to be wrong, but we want to figure out if we’re wrong as soon as possible and course-correct before we put lots of resources into our incorrect opinions. p62

Lean Startup is focused on helping companies be successful by quickly and iteratively determining what customers want, building something that fills only that need, validating the solution, and repeating. p64

What’s Your Goal and How Do you Want to Achieve it?

Your main priority is to pick a specific goal. What you pick to work on next will be in service of this goal, and this is the core of how PMs strategically choose what to work on next. Next, you need to think about how to achieve that high-level goal with an actual product. How do you want to achieve that goal at a high level? Do you want to iterate on an existing product, finding ways to improve it? Do you want to build something completely new—a blue-sky opportunity, also sometimes called blue water or ocean? p65

Let’s look at iteration first. Start by translating your higher-level business goal into a product goal, then focus on what changes we can make to a product to help meet that goal. p65

A blue-sky opportunity is something totally new. The biggest blue-sky examples occur when you believe the market/world is changing in a certain way, p66

Sometimes, new technology and rends, like cloud computing, change how we solve problems, creating new opportunities. p67

The downside to blue-sky thinking is the potential risk. p68

Thus far, you should have established a high-level company goal, translated that goal to a product goal with key success metrics (why you’re making this change), and thought about if you want to accomplish your goal by changing your existing product or building something new (how you’re going to accomplish your goal). p69

Quantitatively Finding An Opportunity

Quantitative sources are important because they allow us to collect data on how people actually use our product, to use that data to find insights, and then to apply those insights to determine what to do next. p70

Metrics and Analytics

Workflows are often called funnels, and are great sources of opportunity hypotheses— p71

Analytics and metrics are useful for several reasons. The first is that people often aren’t aware of exactly what they do, and numerous studies have shown that self-reporting usage is unreliable. Automatically recording their actions lets us see what people are really doing with our product and how they got there. p72

There are many analytics tools, with Google Analytics (Figure 3-1) and Mixpanel being two of the most popular for web and mobile apps. p73

Breaking Down Analytics

The next part is how we group metrics together so that we can spot trends and opportunities. There are three key ways: segmentation, cohort analysis, and funnels. p74

Analytics tools often provide multiple ways to segment data. Common choices range from technical grouping (OS, browser, etc.) to behavioral (new/returning user) to demographics (country/language are common). After segmenting data, we can look at each metric, focusing on our key success metric and the supporting metrics, and see if it’s in line with our baseline expectation. p75

Another way of grouping data is cohort analysis. This is very similar to segmentation, but it uses a point in time as a key characteristic of the group and is often used to look at behavior over time. p75

The last common method of grouping data is a funnel. This is when you measure key steps along a user’s journey towards some task and group them together, in journey order. p75

Dave McClure, the well-known venture capitalist who founded 500 Startups, put together a talk called “Startup Metrics for Pirates,” where he came up with a general approach to metrics for an entire product, called AARRR metrics— p76

• Acquisition: How the user comes to your product.
• Activation: The user’s first visit to your product and her first happy experience.
• Retention: The user liked your product enough to use it again (and hopefully again and again…).
• Referral: The user likes it enough to tell someone about it.
• Revenue: The user finds your product valuable enough that she pays for it.

McClure suggests breaking down the key behavioral steps for your product into these buckets (each bucket might have more than one metric within it) and using this funnel to see how users go from discovering your product to being willing to pay. p77

Ultimately, no matter how you look at your analytics, your goal is to find a metric you believe is worth improving in order to achieve your product and company goals. p77

Chapter 3 Tips

Here are a few ideas to help you. First, many people only focus on the end result of the funnel. They might say, “Not enough customers complete a purchase.” If this is the case, ask yourself why. Look back up through the funnel and see where the leakage occurs. Then, ask why it’s occurring there. You might need to go to that particular part of the product to see what might be blocking a user. p80

Segmenting your audience and focusing in on how each segment behaves can lead to a better hypothesis. p80

One of the techniques Intercom shares is a way to look at your metrics and spot opportunities, called a feature audit. 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 p81

To motivate users to use it more, you can use the Hook Canvas, by Nir Eyal, author of Hooked, to help create habits in your software.

Surveys

It’s good to dive in beyond a general NPS and ask how satisfied customers are with specific parts of your product. p85

tools like Intercom (http://intercom.io), Delighted (http://delighted.com), and UserVoice (http://uservoice.com) can be easily integrated and allow customers to provide feedback continuously. p85

Internally, you should have a sense of how important each feature is to the product. The features that are core to the product and used most often are likely the most important. p85

Generally, you’ll trade off importance vs. how unsatisfied customers are, so you might work on something that’s fairly important with very low satisfaction (Feature A in Figure 3-4) before focusing on a feature that’s very important with moderate satisfaction (Feature B). p86

What About Customer Interviews?

we believe that customer interviews should not be the source of your first opportunity hypothesis. If you start customer interviews without even a vague sense of what you’re looking to learn, the interviews will be unfocused and not useful, and you’re unlikely to find a good hypothesis. p87

Qualitativily Finding an Educated Opportunity Hypothesis

weigh the overall value of fixing a bug against that of not fixing the bug and doing something else instead. Quality’s always important, but not every bug is a high enough priority to go fix immediately. p88

Known Bugs and Sugs

To validate this opportunity, you’ll want to make sure that this is a good time to work on an internal cleanup rather than to deliver something new to customers, and that this internal cleanup will provide value to your team down the road, such as making it easier to implement another opportunity on the roadmap. p88

Intuition

The best way to come up with an idea on your own is not to think about what you the individual want but to really empathize with your target personas, combining your knowledge of your customers’ pain points with your knowledge of what you could build and the overall goals and success metrics that matter to the product and the company. p89

Vision

Team Ideas

A great place to include other teams is in this ideation step. There are likely other teams that work closely with the customers, such as Design, Customer Support, Business Development, and Sales. Reach out to people on those teams and see what thoughts they’ve had based on their experience with customers and the product. Support teams especially appreciate this, as they spend all day working with actual customers, and they have great visibility into what the customers are doing with the product and saying about it. They often can provide data like support tickets to back up their ideas. p92

As the group facilitator, you need to help get the creative juices flowing. One way to do that is to have everyone share the worst ideas they can think of, then figure out ways to make those ideas even worse. After you’ve done that, flip over and focus on how to make the product better. p92

R&D

sometimes there are new inventions that a brilliant engineer, or team of engineers, creates. What’s nice about these inventions is that there’s usually a prototype of some form so that you can see it in action. Adding these inventions to the product—called productizing— p92

The competition

Sometimes your competition has a great idea, and stealing it—and making it better—is your opportunity. p93

Business Model and Value Proposition Canvases

Business Model Canvas

The Business Model Canvas provides a way to look at all aspects of your company p94

• Key partners: Who are the people outside the company, from suppliers to contractors, who make the business model work? What key resources do we get from them and what key activities do they perform? Companies rarely do everything themselves, and working with partners lets you reduce risk and optimize your activities. There are generally three types of partnerships: alliances between non-competitors, strategic partner-ships between competitors, and joint ventures to build something new.
• Key activities: What are the tasks a company must do well to deliver on its value? For example, Apple owns a number of key activities: software development, supply-chain management, store management/ distribution, and more. Samsung’s phone unit is focused more on supply-chain management and software development.
• Key resources: What are the most important physical, financial, intellectual (patents, copyrights, etc.), or human resources the company needs to succeed? They can be owned or leased. For many companies making hardware, human and intellectual resources are key, whereas manufacturing is outsourced to an Asian partner.
• Value propositions: What’s the benefit/value that a certain group of your products or services provides for a given persona? What customer pain points are you solving? The Value Proposition Canvas will dig into this more, too.
• Customer relationships: What type of relationship, from personal to automated, do you want to establish with each persona? For example, a high-value customer might have a direct email for an account manager whereas the average customer might only have online support forums available. Also consider what each segment expects, what you have now, how costly each relationship is, and how you expect to maintain each relationship.
• Channels: How does the company reach each persona to deliver the value, including marketing, communication, distribution, sales, and support? How are you reaching them now? What works best? How are the channels integrated, for example, are sales only via your website?
• Customer segments: Who are the key personas the company/product will serve? These are the most important personas that you believe you’ll create the most value for, and they’re who you want to prioritize opportunities for. The Value Proposition Canvas will dive into this more.
• Cost structure: Where do your costs come from? This breaks down into fixed costs (salaries, rents, utilities) and variable costs (equipment purchases). For many companies, human resources are the greatest expense because people are needed to do key activities so that the businesses can deliver your value to their personas.
• Revenue streams: This represents the company’s incoming cash— revenue minus costs is the company’s earnings. A company might have multiple revenue streams, depending on its customer segments, and asking what value you deliver that each customer segment will pay for, what they currently pay, and how they’d prefer to pay—e.g., lower recurring fee vs. higher one-time fee—helps you determine how to monetize each segment. For example, some companies offer discounted “Home” editions of their products, which lack features that matter at work such as document collaboration that aren’t useful in an average household. The “Home” edition is one revenue stream and the regular version is another.

The Business Model Canvas is great because it lets us write down all of our hypotheses, from opportunity to distribution, in one place. Using the Business Model Canvas alone, it takes some deep thought to find a great opportunity hypothesis. Fortunately, the Canvas’s authors have developed a newer tool, the Value Proposition Canvas (Figure 3-6), also available at http://strategyzer.com, which drills down into the Value Propositions and Customer Segments blocks to really identify how the product is or isn’t providing value to the customers, and what the customers’ needs are.

p97

Value Proposition Canvas

The goal of the Value Proposition Canvas is to help you achieve product/ market fit. p97

Customer jobs are simply the things the customers are trying to get done, in their own words, be it a task they’re trying to perform, a problem they’re trying to solve, or a need they want to satisfy.p98

Gains are the outcomes the customer wants to achieve, in his own words. They might be expected, and either required or desired, or surprising, ideally in a positive way. p98

Last, we have pains. These describe the obstacles preventing the customer from completing the jobs, along with possible bad outcomes and risks. p98

Products and services are fairly straightforward: What are the products and services available for each persona/customer segment? p99

Gain creators refers to how your products and services create benefits and outcomes the customer wants, whether those are required, desired, or surprising. p99

Pain relievers are how your product addresses the customer’s top pains. p99

Pain relievers and gain creators are the parts of your product that create value for the customer segment. p99

note that some products, especially B2B products, might have multiple personas, so you will need multiple Value Proposition Canvases, one for each persona. p99

External Factors

force an opportunity. The simplest and most understandable one is when a good business opportunity arises. For example, maybe a partner offers a large contract if a certain feature is added to the product within a given timeframe. p100

Using the Kano Model to Find Opportunities

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.

Then it maps these principles into feature categories.

Basic features. These are the things customers expect in a product, usually mapping to the value principle, and customers will be very unhappy if they are poorly executed or missing.

Performance features (satisfiers). These are the things customers are often judging your app by and the things they look for before purchasing. Your customer’s satisfaction with these features will be proportional to how well you execute them. These are fairly easy to find information about by talking with customers,

p101

Excitement features (delighters). These are the unexpected “wow” features that become product differentiators, innovations, and unique selling points, such as the iPhone’s capacitive touch screen, Android’s notification panel, or Wi-Fi on an airplane midflight. p102

The Kano model p102

To find feature opportunities using the Kano model, map your product and its features against the model. What features are about meeting basic expectations? Are they meeting expectations? Have you covered all the basics? If so, move on to a satisfier or a delighter. p103

Chapter 4: Validating Your Hypothesis

The right way to validate your opportunity hypothesis depends on your specific situation. In general, for each new idea you’ll want to have objective data, anecdotal data, and cost/benefit data to be able to fully assess it. This means you’ll have to do multiple types of validation. p108

once you’ve found and validated an idea, you need to assess where it fits on the roadmap. Just because you’ve found a great opportunity doesn’t mean it’s the best thing for the company to work on next. p108

Swot Analysis

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. 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. p109

Internal Validation

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. p110

• 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?

at Intercom (introduced in Chapter 3) also suggest looking at your return on development investment to validate an opportunity. Create a two-by-two grid p111

sometimes we have to do high-effort things that users won’t value, like rebuilding a back end, but this grid will help you put things in context. Low-effort, highly valued features or products are nearly always worth pursuing. p111

Chapter 4 Tips

You Need Context To Make Good Product Decisions

Nik Laufer-Edel model

Current State

• What’s the users’ current perspective of the problem? How do they think and feel about it?
• Journey
• What are the current steps they take? This is often the flow of your application but might also include taking steps outside of using your app or competitors

Motivation

• What about the current solution are they not happy with?
• What about the new solution is uniquely appealing?
• Do they believe that following the journey will get them to the desired state?
• Do they believe they have the ability to do what will be asked of them at each step?
• Do they believe they will be supported if they run into problems?

Hinderences

• What about the current solution do they like?
• What about switching to the new solution worries them?
• Desired State How do they measure success?
• What is winning?
• How does getting to this state move them closer to other, larger goals?

p114

External Validation

Are there relevant research reports, whether it’s Mary Meeker’s Internet Trends report p116

watch out for confirmation bias. This is when we look for only evidence that confirms our hypothesis and ignore evidence that contradicts it. p116

Customer Development

Interviews

Customer development

Interviews

Page 117

watch out for confirmation bias . This is when we look for only evidence that confirms our hypothesis and ignore evidence that contradicts it .

Page 118

Cindy Alvarez’s excellent Lean Customer Development , that cover in detail how to prepare , do , and learn from customer interviews .

Preparing for Interviews

Page 119

To get started , write down a list of what you know factually and what you’re assuming about our customers , including their needs and how your product satisfies them .

Page 119

Use the Value Proposition Canvas to identify what you know for sure and what you’re assuming are your customers ’ existing pains and desired gains .

Page 120

write your opportunity hypothesis in terms of these canvases : “ I believe that < personas / segments > experience < this pain > when doing < task > because of < limitation > , and alleviating that pain would let the customer < achieve this gain > , although she’d have to < accept these limitations > . ”

Page 120

Also ask questions to exclude people , like , “ How often did you listen to music last week ? ” Braden Kowitz at Google Ventures created a useful template to help you screen for participants , available at https : / / goo.gl / uPBXD6 .

Page 121

let’s figure out what to ask them . The most important thing to know is that , whether they realize it or not , people are going to try to please you . The most valuable thing you can do is to get the customer to tell you about how they currently deal with whatever problem you’re thinking about solving .

Page 121

if you ask questions about what people currently do , you’ll see what actually happens in their lives , which is a much better predictor of what they’ll do in the future .

Page 122

it’s better to find out about how they deal with the fundamental problem you’re trying to solve . The simplest way to ask a question like this is , “ Tell me about how you do < topic > today . ”

Page 122

stories rather than giving simple yes / no answers . They’ll automatically provide you some background context , or you can politely interrupt and ask them to clarify any needed context .

Page 123

You could also use the “ magic wand ” question : If you could wave a magic wand and be able to do anything you can’t do today , what would it be ?

Page 124

If you have an existing product and a fairly detailed opportunity hypothesis , you can also use a hypothetical situation . Have part of the interview where you say something like , “ I want to tell you a story about how we imagine someone like you using the next version of our product based on what we’ve heard from other customers . Please interrupt me if you have questions , if you disagree with anything I’m saying , or if I’m just plain wrong ! ”

Page 124

“ Tell me about your primary computer ” is better because it doesn’t imply any judgment and lets customers respond with what they care about .

Page 124

Put together your first list of questions , but don’t worry about making it perfect . As you start to do real interviews , you’ll refine your questions based on if you’re getting the information you want

Page 125

you should always ask at the end of an interview : “ Is there anything else about < this topic > that I should’ve asked about ? ”

Page 125

What’s the last date where interviews can give you useful information ?

Page 125

What level of quality and confidence in the results do you need ? Do you have a bit of time to really do a thorough job , or do you have to work as fast as possible even if the results are imperfect ?

Page 125

What’s the right medium for the interviews : in person or on the phone ?

Drawing conclusions from interviews

Page 126

How much time will each interview take ?

Page 126

Should you pay your interviewees ?

Page 129

Make sure to note any non – verbals , and star any emotional utterances ( “ I hate / love this ” ) . One exception to the verbatim – recording goal is if they say “ maybe ” ; write it down as “ no . ”

Page 130

Take some time immediately after each interview to pull out 5 to 10 of the most interesting points .

Page 130

topic at hand . If they say , “ Here’s what I’ve tried and what I do , ” then they care . “ < This > would help me achieve < this goal > ” is meaningful , whereas , “ < This > would be interesting to have ” and “ I think I could figure out how to use it ” mean this person won’t use the product .

Page 130

Pull the data from all your interviews together into an overall summary that you update as you go . Categorize what the customers say as appropriate , including pain points , emotions , existing solutions , and so on .

Page 131

If only a few people see your opportunity as a pain point they care about , the potential market for your product might not be large enough to matter . You’ll want to do more ( like a survey , which we’ll cover next ) to try to gauge the market size , but this should be a warning sign .

Surveys

Page 131

“ The plural of ‘ anecdote ’ is not ‘ data . ’ ”

Page 131

In general , the data surveys provide isn’t as high quality as that from customer interviews , but it’s a low – cost way to see if our conclusions from customer interviews scale to a large number of people .

Creating Surveys

Page 132

keep surveys short ! They should take only a few minutes to fill out .

Page 134

segmentation around pain / needs / jobs being more effective than around demographics .

Executing Surveys

Analyzing data

Page 136

When you’re ready to start looking at results , the very first thing to do is validate the data .

Experiments

Page 137

An additional way to validate a hypothesis is to run an experiment where you build something to test your hypothesis .

A/B tests

Page 137

A / B test . The idea’s simple : if you make a change to your existing product and address the opportunity you’re focused on , what impact does it have on your key metric ? You’ll implement the change , randomly give some users the current “ A ” version and some users the new “ B ” version , and then see if the metric changes in a significant way .

Page 138

Optimizely is a very common tool for implementing A / B tests ,

Simple MVPs

Page 139

Create a fake marketing website for your product , describing it as if it already existed with the features you feel are important , and put a “ Buy ” button at the bottom of the site . Then , market this product like it actually exists , take out different display ads , and see how many people click “ Buy ” .

Page 139

Another type of MVP is a concierge MVP ( these names are from Eric Ries in The Lean Startup ) . In it , you’ll manually work with your customer just like a real concierge would to perform a task , where the task is the overall focus for your opportunity hypothesis .

Page 140

Wizard of Oz MVP is another simple type , sometimes the next step after the concierge MVP . Here , you’ll create a product that looks like it’s fully built to an end customer , but humans are doing the work behind the scenes .

Page 141

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 . ”

Page 141

The key to remember with every experiment is that you want to keep it simple and cheap .

Moving forward

Page 141

There’s one more step to think about , and that’s your opportunity’s priority on the roadmap .

Page 142

Every feature has an opportunity cost : working on one thing means you’re not working on something

Moover’s opportunity validation strategy

Page 143

Here’s the first version of our interview template : Have you moved before , without Moover ? If so , what was it like ? How did you hear about Moover ? What was your experience like using Moover ? Which moving company did you pick , and what made you pick them ? How did you communicate with the moving company outside of Moover ? ( If they say “ phone ” ) : How many times did you attempt to contact each other before you actually talked ? ( That is , you call them and get voicemail and you miss their return call . )

Page 144

How do you feel about talking with someone on the phone ? Could you tell me what your first and second preferred forms of communication are ( e.g . , phone calls , email , SMS , something else ) ? What additional information did the moving company need to give you a final estimate ? How long did it take to go from starting to communicate with the company to providing your information to getting a final bid ? Did that delay affect your planning ? Did you have any special items , like a piano ? If so , what was it like to arrange moving that ? ( If the move has happened already ) : How did things go the day of the move ? Was there any preparation with the movers that didn’t happen that would’ve made the actual move smoother ? Post – move , how did things go with the moving company ? ( If they’ve moved previously ) : What parts of Moover saved you time compared to when you moved before ? If I could wave a magic wand and change any part of the moving experience ( aside from packing and unpacking — say this with a laugh ) , what would you want me to change ? On a scale of 1 to 10 , with 10 being “ definitely ” and 1 being “ not at all , ” how likely are you to recommend Moover to a friend ? ( If you don’t think you’ve gotten answers that reflect this number , probe more and ask about the single biggest factor that led to their picking that number . ) Is there anything I didn’t ask you about communicating with the moving company that I should know ?

Chapter 5: From Idea To Action

Why new ideas struggle

Page 147

The biggest reason new products struggle isn’t a technical reason — it’s because customers don’t want or need the product you end up building .

Page 147

In other words , it happens because you don’t achieve product / market fit .

Page 149

there are steps you can take that will give your product the best chance of success possible . These steps start with writing a few key documents that will help you clearly establish your goals and desired outcomes , create empathy for your customers , and allow for clear communication with stakeholders .

Working backwards by imagining the future

Page 149

There are two great “ imagine the future ” documents to try writing before anyone’s written a line of code . These documents are a press release and a product review .

Page 150

When you start to build a new product , writing these documents forces you to take your product ideas out of your head and get them down on paper , making it much easier to share your ideas with other stakeholders .

Writing an internal future press release

Page 150

writing a press release before you start product development forces you to explicitly write down your target market , the problem you’re addressing , how you’re solving it , and the key features of the solution — succinctly , in less than a page .

Page 151

A basic product press release usually includes these elements : Headline : If you were to tell your friend about this product in a sentence , what would you say ? Included in that is the key target market , how it helps them win , and a tentative product name that the target market can understand . Sometimes you will need two sentences , in which case you should write a headline and a subheading .

Page 151

Summary paragraph : The first full paragraph in your press release should call out the most important aspects of the product and how it solves the customer’s problem . Imagine you’re reading this press release on Flipboard or Apple News — most people will read only this first paragraph , so it needs to be concise but complete .

Page 152

Problem and solution : The next section should elaborate on the problem and your solution in more detail . Spokesperson quote : Include a quote from you , the product manager , about how this product is great for your customers . It’s fine to include this in the solution text . Customer quote : Include a quote from a fictional customer about how the product fits into his life . Conclusion / how to get started : Explain how new customers can find / sign up / buy / use this product , and pull everything together with a call to action .

Writing a review

Page 152

a review forces you to think about what customers will hear and how they’ll experience the product .

Page 152

you need to be honest about what tradeoffs you’re willing to make with the product .

Page 153

Similarly , what parts of your product do you think a reviewer will focus on , and which will they ignore ?

Page 153

the review should have a conclusion about why a customer should buy your product , especially over a competitor’s or whatever the customer is doing now . This conclusion should reflect the unique , differentiating value your product offers .

Page 153

What are your company’s core competencies ? How do those connect to this opportunity ? For example , especially at first , Google Docs was much more limited than Microsoft Word . But it was cloud – based , collaborative , and platform – agnos –

Page 153

in addition to being free . Those three factors are how Google used its strengths to build a differentiated word processor .

Defining an MVP

Page 154

Clearly defining the MVP you want to ship and working backwards to determine how to achieve it is another way to help set your product up for success .

Page 154

Every button or feature you add increases the friction for customers — it makes them have to think more about what they’re doing .

Page 155

For the beyond – MVP features , rather than arbitrarily picking features to build , test your MVP with key customers before release .

Page 155

how do you come up with your MVP ?

Page 155

Write down the overall thing you’re doing and why you’re doing it .

Page 155

List the features you think you need to achieve that top – level goal , along with why that feature’s important .

Page 156

Now here’s the kicker : as you work on this step , you’re not allowed to add any new feature category not listed in the press release and product review .

Page 156

Go through your feature list and cross out whatever items customers don’t actually require to address their core need .

MVPs, plussing and the kano model

Page 157

Walt Disney . He came up with the idea of “ plussing , ” which is simply finding ways to make a good idea great and to deliver beyond what people expect .

Communication via a product requirement document

Page 158

One of the most importantly tools to help you communicate is a well – written product requirement document ( PRD ) . A PRD is an explanation of the specific product you’re building . It clearly explains why you’re building this product , both for your internal goals and for yourcustomers , along with the exact scope — the features and functionality — of the product .

Page 159

Unlike when product management first emerged and people created detailed PRDs before a project began , we believe that the PRD is finished only when the product’s released .

Page 159

the PRD should be the project’s home page — or at least the very first link on the project’s homepage .

Breaking down a PRD

Page 160

These are the key sections in a PRD :

Title : Give this project a distinct name .

Change history : Provide a description of each important change to the PRD , including who changed it , when , and in what specific way .

Overview : Briefly , what is this project about ? Why are you doing it ? Objectives : What will this let the customer do ? What are our high – level internal goals for doing this project ?

Success metrics : What are the success metrics that indicate you’re achieving your internal goals for the project ?

Messaging : What’s the product messaging marketing will use to describe this product to customers , both new and existing ?

Timeline / release planning : What’s the overall schedule you’re working towards ?

Personas : Who are the target personas for this product , and which is the key persona ?

User scenarios : These are full stories about how various personas will use the product in context .

Requirements / features in : These are the distinct , prioritized features along with a short explanation as to why the features are important .

Features out : What have you explicitly decided not to do and why ?

Designs : Include any needed early sketches , and link to the actual designs once they’re available .

Open issues : What factors do you still need to figure out ?

Q & A : What are common questions about the product , and answers to those questions ? This is a good place to note key decisions .

Other considerations : This is a catch – all for anything else , such as if you make a key decision to remove or add to the project’s scope .

Page 164

Writing stories to talk about the customer and the product you’re building is the most effective way to help your team empathize with the customer

Crafting great stories

Page 165

All stories have a similar structure . They first give you context : they set up the world .

Page 166

The transition from the setup to the next part of the story , action , is the “ inciting incident . ”

Page 166

Now is the action section . This is where “ stuff ” happens . When the persona is using the product , what’s he doing ?

Page 166

Finally , what’s the result ? Now that he’s addressed his need , how does his world change ?

Page 167

Keep using stories for your PRDs , presentations , and more , and you’ll become a better and better storyteller .

Writing user scenarios

Page 167

There are three key tips to keep in mind when writing user scenarios . First , remember that your goal is to make readers feel like they’re sitting next to each persona , using the product in each scenario .

Page 168

Second , you want these stories to be as truthful as you can imagine , as being authentic will help you get the best possible understanding of your customer so that you can make smart product decisions

Requirements Featurs in and features out

Page 169

Next up in the PRD structure is a feature list , which is sometimes also called a list of requirements or , more confusingly , user stories

Page 169

You already have the basis for this : your MVP definition list . Each of the items on your MVP list should be prioritized as essential .

Page 169

Your user scenarios will provide the rest of the list — go back through them and explicitly break down the prose into tasks .

Page 169

An easy way to do that is to write each item in this format : “ As a < persona > , I want < specific feature goal > so that < reason > . ” Some PMs prefer to use the Given – When – Then format : “ Given < some context > , when < some action is done > , then < a set of observable behaviors happens > . ”

Page 170

We’ve found it also useful to explicitly list “ features out ” — that is , what you’re not doing and why .

Using a PRD

Page 171

write the first draft of your PRD in a private format , such as a Word doc or a non – public Google Doc .

Page 171

After you’ve written it , you’ll start sharing it with others for feedback

Page 172

first people to share your PRD with are leads and fellow product managers .

Page 172

Once your team is on board , engage the other key stakeholders , such as the design and engineering leads .

Page 173

After discussing the PRD with this group , you should all be in agreement about what you’re trying to build and why , along with what your key success metrics are .

Page 173

Now is the time to start sharing the PRD more broadly . If you have an internal wiki , move the PRD to a wiki page and make that the product’s homepage ,

Chapter 5 Tips

Page 175

An experiential immersion is simply finding a real – world experience that your entire team can go through together that will allow you all to really live through the problem you’re solving for .

Page 176

Identify a customer persona that experiences this problem often . Create a scenario where your team can “ act ” and simulate actually being the customer experiencing the problem . Allow your team to live through this problem together for a while — at least a couple of hours . Discuss as a team what it felt like to live the problem and whether any of your core assumptions have been even further validated , or need to be readdressed .

Chapter 6: Working With Design

Page 187

So far , you’ve been responsible for each step in the product – design life cycle . You’ve found and validated an opportunity , communicated it to your stakeholders , and gotten everyone onboard . Now we’ll shift into the execution phase , which starts by figuring out the product’s user experience with the design team .

What is UX design

PM vs designers

Page 191

use an analogy , a PM is like the typical president of the United States and the lead designer is like the typical secretary of state .

Page 191

Guy Kawasaki’s claim that a product manager has “ all of the responsibility and none of the power . ”

The design process and key design skills

Page 192

The design process generally breaks down into six primary phases : User research Information architecture Interaction design Prototyping Visual design Content strategy

Page 193

to help keep things moving is by having a reoccurring Design / Engineering / Product meeting each week for the project ,

Usability testing with prototypes

Working with design

Judging and giving feedback about design

Page 201

we highly recommend you take the time to learn about design , reading books like Donald Norman’s seminal The Design of Everyday Things ,

Page 201

The most important criteria we’re going to set is “ Does this design let the customer achieve his goal with the least friction possible ? ”

Page 201

recommend using Dieter Rams’s 10 principles of “ good design . ”

Page 202

Good design is innovative . Technological innovation is constantly creating opportunities for new and innovative designs .

Page 202

Good design makes a product useful . We want our products to be used and loved , which means they need to be useful

Page 202

Good design is aesthetic .

Page 202

Good design makes a product understandable .

Page 203

Good design is unobtrusive .

Page 203

Good design is honest .

Page 203

Good design is long – lasting .

Page 203

Good design is thorough down to the last detail .

Page 203

Good design is environmentally friendly .

Page 203

Good design is as little design as possible .

Design relationship skills

Page 204

handy way to think about the difference is that product managers focus on the ideal customer , whereas lead designers often focus on the ideal user .

Page 206

Your job is to give requirements and constraints along with how you’ll consider the problem solved , and let Design and Engineering find the solution .

Page 206

your primary job as a PM is to focus on giving clear personas , requirements , and goals .

Page 207

napkin sketch is a drawing that’s low quality and created quickly , as if you drew on the back of a napkin with a pen . We recommend using a tool like FiftyThree’s Paper for the iPad

Chapter 6 Tips

Being Open and Flexible

Page 209

Be flexible , rather than authoritarian . Don’t try to push a singular agenda an call it a “ vision . ” Be open to compromise as the deeper complexities of the product reveal themselves .

Google Design Sprints

Page 211

These sprints typically last a week . You start the week with a specific challenge to solve , and you end the week with a design the team’s agreed upon and that you’ve validated with real customers .

Sprint preparation

Page 211

Start by picking a sprint master . This person will set the context for the design sprint and facilitate each stage of the sprint .

Page 211

Google recommends about one day of preparation for each day of the sprint .

Page 212

the sprint master will write a design brief that clearly defines the challenge ( the PRD can be a great reference here ) , the deliverable , and the timeline to launch .

Page 212

she’ll start by determining the right team to have on the sprint . The best teams are five to eight people and include the PM , designers , engineers , and other experts or stakeholders .

Page 212

schedule the room

Page 212

needed supplies , including paper , tape , sticky notes , voting stickers , a timer , and pens .

Understand

Page 212

The first part of the sprint is devoted to understanding the problem you’re trying to solve , why you’re trying to solve it , who the customers are , those customers ’ needs and capabilities , and more .

Page 212

The sprint master might arrange short talks , user interviews , field visits to customers , competitive overviews ,

Page 212

During the first day of the sprint , you’ll also schedule your customer – testing interviews for the last day .

Define

Page 213

come up with a clear problem definition . This is when you narrow the problem and come up with the key principles and goals

Diverge

Page 213

After you clearly know the problem and what you want your solution to achieve , you and the sprint team will brainstorm as many ideas as possible for how to solve the sprint challenge .

Page 213

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 .

Page 213

Make sure not to reject anyone’s ideas during this phase

Page 214

Get crazy , get creative , and don’t filter yourself . Ideate , ideate , ideate .

Decide

Page 214

Once you’ve come up with a lot of ideas , you’ll pick the best ones , so far , by voting .

Page 214

Even though each idea should be self – explanatory , spend some time discussing each one . For example , take three minutes

Page 214

After you’ve discussed each idea , you’ll super – vote . This is the decision – making vote . Each team member will get a limited number of voting stickers , and the CEO and PM will get extra voting stickers .

Prototype

Page 214

After picking a key idea or two , create a prototype . Building this prototype will take the most time of all the steps , but you will emerge with a mock – up , demo , physical prototype , or other way of demonstrating the idea that you can show to real people .

User testing

Page 215

The final step in the sprint is showing your prototype to real customers and getting feedback . Try to find out what they like and dislike , if the solution will meet their needs , and if there are hidden factors that could stop them from using this solution .

Page 215

highly recommend reading Google Ventures’s book Sprint : How to Solve Big Problems and Test New Ideas in Just Five Days .

Page 216

design is done when our prototypes and mock – ups are validated as a solution to the problem we’re trying to solve and Engineering has agreed to the designs ’ viability .

Chapter 7: Working With Engineering

Page 217

You’ll work closely with Engineering day to day to help oversee the product that’s being built , making sure it meets the product requirements , making scope changes if key features are taking longer than expect to develop , prioritizing the back – log , and eliminating whatever obstacles you can for the engineering team .

Product/Engineering relationships

Page 220

If you work closely with Engineering to watch the balance between time ( When are we aiming to have this done / shipped ? ) , quality ( Can we take on some technical debt now ? ) , and money ( Would more people or overtime help us get this project done ? ) , you’ll keep the process collaborative and deliver the highest – possible – quality product on the best – possible schedule .

Page 220

solving hard problems requires deep concentration . Interruptions , whether for meetings or to reply to high – priority messages via email , Slack , HipChat , etc . , can be very frustrating

Page 221

give the engineering team time to focus on getting its work done , even if it means you have to wait for an answer to a question .

Page 221

Engineering completes each task , make sure to provide feedback , whether it’s that they did a great job and exceeded your expectations or that you found a bug or something isn’t quite right .

Software-development methodologies

Waterfall Development

Page 222

In 1985 , the US Department of Defense formalized the waterfall process in its DOD – STD – 2167A document ,

Agile development

Page 225

Instead of a fully fleshed out , staged approach , agile follows an incremental approach . With agile you plan out a relatively small unit of work , build what you need to , and evaluate what you built . Then you use that knowledge to plan the next work to do .

Page 226

Short sprints — one or two weeks — or continuous deployment are ideal with agile , as they let you move quickly and get feedback .

Page 227

leveraging scrum spikes — a user story to investigate something — or having explicit R & D sprints where a developer’s only task is to try to solve one problem .

Scrum

Page 228

scrum means that the team comes together to prioritize what to do next and set short – term goals for what work to finish . You as the PM will have very strong input into that part of the process .

Page 229

Each week , you meet with the engineering team to perform backlog grooming .

Page 229

Grooming simply means you make sure the bugs and sugs are organized and have enough clarity to act on . For example , we’ve all seen

Page 229

you’ll often see complexity measured using relatively weighted story points .

Page 230

After assessing the complexity , your role as the product owner will be to provide rough prioritization for any new items along with existing backlog items based on customer need , business value , and longer – term goals / needs . Your goal with this prioritization is to have the most important thing to work on next at the top of the backlog .

Page 230

Teams often create a second list , called an icebox , for these less – immediately – relevant – but – things – you – don’t – want – to – forget stories .

Page 230

Putting something in the icebox instead of explicitly saying “ no ” is a nice way to make people feel their input is valued while avoiding feature creep .

Page 230

you’ll have another planning meeting where you determine the sprint backlog .

Page 230

You’ll pick the key things you want to work on based on priority / business value , and the engineering team will agree on whether they can commit to it during the sprint .

Page 230

Over time , you’ll find that the team tends to complete n story points per sprint . That number is called the sprint velocity .

Page 231

During sprints , you’ll periodically need to accept work that pays off that technical debt even though there’s no visible customer value .

Page 232

During the sprint , you’ll have short , 15 – minute meetings called stand – ups at the start of each workday , where each team member states what she did during the past day , what she aims to accomplish today , and if she has any blocking issues .

Page 232

demo meeting with key stake – holders / the customer / the client to show what you’ve built and gauge their feedback , and an internal sprint retrospective to assess how the sprint went .

Page 233

Scrum also makes project management easier , as you can use story points and the total story points for outstanding items in the product backlog to create trend lines . These trend lines let you estimate when the project will be done with a feature set , along with how much work will be done on a certain date .

Page 233

create new ways to communicate , like agile encourages , such as posting a status update to Slack at the end of the day rather than holding a stand – up .

Kanban

Page 234

Kanban’s goal is to match the team’s capacity to do work with how much work is actually happening .

Page 234

Kanban , you will typically create a task board showing what’s up next ( to – do ) , in progress , ready to be tested / verified , and done . Tasks will move from one column to the next , and you’ll know how much work the team can handle at once along with how many things it can verify at once .

Page 235

it enables continuous deployment .

Chapter 7 Tips

Working with Junior Development teams

Page 238

junior developers are not used to user story estimation .

Page 238

need to do a lot more QA around the work that junior developers have completed .

Page 238

You really have to document and make sure that junior team members have internalized what you are asking them to do .

Working with remote teams

Page 239

You can play a big part in helping remote teams be successful by over – communicating requirements , goals , decisions , and the definition of “ done ” for the project so that everyone feels like they’re on the same team and has a clear understanding of what they’re working towards , regardless of where their desks sit . Sometimes

Page 240

at the review meeting , rather than trying to accommodate everyone’s schedule and possibly making the meeting inconvenient for the stakeholders , try having the product owner , rather than individual developers , present the overall team’s work to the stakeholders .

Working with third-party development teams

Page 241

you can do a few things to ensure success . The biggest is to make sure you’re communicating the requirements , goals , and deadlines to the third – party team clearly .

Page 241

Coordinate the timelines and progress with any stakeholders internally to make sure everything looks good . It’s often better to over – communicate , especially at first .

Page 241

establish frequent milestones with the external team .

Page 242

we say that the development phase of the product life cycle is done when working , tested software that meets your product requirements is ready for release .

Chapter 8: Bringing Your Product to Market

Page 243

this point you’ve found an opportunity , validated it , gotten your team on board , and built a product .

Understanding customers

Page 246

These are the key areas to focus on from a marketing point of view : Customer segments : Who are the key personas ? Value propositions : What’s the benefit / value each persona will gain from your product ? Channels : How does the company reach each persona ? Customer relationships : What communication level and type does each persona expect ? Revenue streams : How much and how often will the customer pay ?

Page 247

How the persona would consider your product a success How the persona perceives your product / company ( if you have an existing product ) What buying criteria the persona has How the persona evaluates products ( e.g . , does he expect a free trial ? ) How the persona perceives your competition What influence this persona has on the buying process

Page 247

By fleshing out the marketing side of a persona , you’ll help the marketing team make successful decisions .

Product messaging

Page 248

Specifically , how do you communicate your product’s value to customers and explain why they should care and what problems your product solves ?

Page 248

we’ll likely need different messages for each persona .

Key elements of your product’s message

Page 249

There are three key questions our theme should answer : Why is this product / company important ? Why are you doing this ? What’s special about your company’s mission that will make a customer want your product over a competitor’s ?

Finding your company’s voice

Page 252

Enterprise products traditionally have taken a formal tone to create a “ business ” feeling and consumer products have adopted a casual tone to create a friendly and accessible feeling .

Putting the message pieces together

Page 254

remember that your message is not about what the product does , it’s about what the product lets the customer do .

Chapter 8 Tips

Ask the DRI to whiteboard it for you

Page 256

Conversely , one of the best ways for a PM to earn kudos from other teams is to tell the story in an articulate , engaging , and insightful manner .

Going to market

Page 259

For these meetings , it’s helpful to create a launch tracker to organize the launch . Three sheets in a spreadsheet are sufficient . The first sheet will contain the action items . These are specific tasks , assigned to a particular person / team , along with when each task was assigned , when it was due , and any comments / status updates appropriate for the task . The second sheet will contain caution items . These are possible problem issues along with who raised them , when they raised them , when each issue was resolved , and any comments . The last sheet will have key decisions , including who made them , when , and any comments . In the same way the PRD is a living document that acts as the key product resource as you build the product , this launch tracker will be your launch reference .

Page 260

At a high level , the GTM plan is subdivided into three sections : prelaunch , launch , and postlaunch .

Prelaunch planning

Page 260

The main things to decide during prelaunch are the key launch

Launch objectives

Page 260

goals , how you’ll make sure the product is ready for that launch , when and how you’ll launch the product , and what assets you need to launch .

Launch Timing

Page 262

The only rule of thumb for these smaller releases is to release earlier in the week so that if any support issues arise your team doesn’t have to work over the weekend to resolve them .

Testing

Page 266

The most common result of a beta test is that you use the results to make a few minor changes and bug fixes ,

Page 266

After a couple of iterations with larger sample sizes in each , the product will be ready to launch .

Page 266

quite common to add a launch task for Engineering to scale up your virtual server capacity during a launch window , until traffic has leveled off to a predictable level .

What kind of launch

Page 268

These are the key things to think about for your launch type : Which personas care about this feature , and what customers do they map to ? How will you reach new customers ? How do you reach existing customers ? What’s your launch objective , beyond reaching the right customers effectively ?

Page 269

One simple approach is to build up an email list of interested customers prelaunch . A “ tell me more ” landing page for your product is a simple way to capture email addresses .

Page 269

Many smaller companies choose to work with a PR agency that has connections at various media outlets to help get coverage in places your target personas look .

Launch asset planning

Page 269

As the product manager , you’ll often have a hand in creating these launch assets ,

Page 270

Website updates .

Support documentation .

Sample video / images .

Blog posts and other social media material .

Ads .

Demo plan .

Distribution review needs .

Internal product FAQ .

Support – team training materials .

Sales – team training materials .

A helpful prelaunch marketing framework

Page 272

This framework , called the 4Ps Framework , is a guide to making marketing decisions and a reminder of key decisions you have to make when launching a product . The Ps stand for product , price , promotion , and place .

Page 272

product ( what is it , who’s it for , what’s the benefit ? )

Page 272

the packaging , accessories , support , warranty , and return policy .

Launch

Postlaunch

The customer lifecycle

Page 274

customer life cycle .

Page 274

Customers often start their journey with the awareness , interest , and engagement phases .

Page 275

next life cycle phase is about getting people to trust your product will deliver on its promise and to buy it — offering money – back guarantees is a common technique here .

Page 275

The last phases of the customer life cycle are about customer satisfaction and advocacy . The ultimate goal of the customer life cycle is to have customers advocating for you .

Marketing cost measurement terms

Page 276

Pay per impression ( PPI ) : You pay for the ad whenever it’s shown . Impression means “ someone saw the ad . ” Pay per click ( PPC ) : You pay for the ad only when someone clicks on it . Pay per action ( PPA ) : You pay only when the user achieves some final action , such as downloading your app . Click – through rate ( CTR ) : The percentage of people who click on your ad . Cost per impression ( CPI ) / cost per thousand impressions ( CPM ) : This is how much you pay to have your ad shown once ( CPI ) — more commonly listed as the cost to have it shown 1,000 times ( CPM ) . This can be used to assess how effective a campaign is . It’s simply the advertising cost divided by the number of impressions . Cost per click ( CPC ) : This is the actual price you pay for each click in your PPC advertising . In bid – based systems like

Page 277

Customer lifetime value ( CLV / LTV ) :

Chapter 9: Finishing The Product-Development Life Cycle

Page 281

you need to do three more things during this cycle : PARTY , self – assess the cycle , and create a recommendation for the next iteration .

Post Mortem

Page 284

Here’s how we like to run postmortems . Find a time where the product’s core team and the key stakeholders are available , and schedule a meeting for an hour or so . You’ll want to try to create a relaxed and open atmosphere , which can mean anything from booking the meeting room with the comfy chairs to providing food and alcoholic / non – alcoholic drinks for the team — it varies company to company . Just make sure you have a whiteboard or something to write on that everyone can see . Since this meeting is about feedback , all opinions are valid — make sure you don’t put value judgments on what people say , especially if they give you negative feedback . Divide the whiteboard into two columns : things you did well , and things you wish went more smoothly . Start by asking everyone to say what they think went well . After a bit , switch to the other list and ask for things people wish had gone better . Bounce back and forth between the lists until you feel everyone’s been heard . Last , take some time to discuss what you want to do differently and what you want to keep the same during the next cycle .

Chapter 9 Tips

Page 289

you will stop being a specialist in one part of the process to become a generalist in all the parts involved in the process by leveraging other people’s talents .

Page 290

three critical skills I think you have to develop in order to get a job as a product manager are technical expertise , domain expertise , and communication expertise .

Page 291

Decode and Conquer by Lewis C . Lin