Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
1
The Product Book 2nd Edition EN pdf product school
THE
PRODUCT
BOOK
JOSH ANON
CARLOS GONZÁLEZ DE VILLAUMBROSIA
PUBLISHED BY
and
The Product Book: How to Become a Great Product Manager
Copyright Š2017 Product School
All rights reserved.
No part of this publication may be reproduced, stored, or transmitted in any form or by
any means, electronic, mechanical, photocopying, recording, scanning, or otherwise,
without written permission from the publisher. It is illegal to copy this book, post it to a
website, or distribute it by any other means without permission.
LEGAL NOTE
All trademarks are property of their respective owners. Unless otherwise noted, all text
and images are copyright Product School, and they may not be reproduced without
permission.
ISBNS 978-0-9989738-0-7 PRINT
978-0-9989738-3-8 MOBI
BOOK DESIGN The Frontispiece
PUBLISHED BY Product School
TABLE OF CONTENTS
INTRODUCTION				
1 What Is Product Management
2 Strategically Understanding a Company
3 Creating an Opportunity Hypothesis
4 Validating Your Hypothesis
5 From Idea to Action
6 Working with Design
7 Working with Engineering
8 Bringing Your Product to Market
9 Finishing the Product-Development Life Cycle
Acknowledgments
About the Authors
7
9
32
64
109
149
189
218
243
279
300
302
The Product Book 2nd Edition EN pdf product school
7
INTRODUCTION
Thank you for picking up this book! We know your time is valuable, and
we will do our best to make this book worth your while.
One of the most important parts of being a product manager is knowing
who your customers are and what they need. So, who do we believe you are,
and what need will this book fill? Fundamentally, you are someone who’d
like to know more about product management. Maybe you’re a recent
graduate trying to figure out if product management is the right career
for you. Maybe you’re an engineer actively transitioning into product
management. Maybe you’re a start-up founder figuring out how to build
your product division. Or maybe you’re already a product manager who
naturally evolved into the role, seeking to fill gaps in your knowledge.
Furthermore, there’s a lot of wisdom out there regarding best practices
for product managers, but most of it focuses on parts of the product-
development life cycle. This book will give you an end-to-end view of
what goes into building a great product, as well as what product managers
do each day.
8
The upcoming chapters will cover a mix of theory and practical
advice to teach you how to identify an opportunity, and build a product
successfully to address that opportunity, whether the result is a new
product or a refinement of an existing product. Whether you are new to
product management, or an experienced veteran, this book is here to help
you learn the needed skills to be a successful and effective product leader.
A brief word of warning: Much like chess, poker, and Minecraft,
product management is easy to learn, but can take a lifetime to master. If
your goal is to be a product manager, consider this book the start of your
journey. Becoming a truly effective product manager takes practice!
If after reading this book you still want to become a product manager,
consider enrolling in Product School, the world’s first tech business
school. Product School offers product management classes taught by
real-world product managers, working at renowned tech companies
like Google, Facebook, Snapchat, Airbnb, LinkedIn, PayPal, and Netflix.
Product School’s classes are designed to fit into your work schedule, and
the campuses are conveniently located in Silicon Valley, San Francisco,
Los Angeles, Santa Monica, and New York.
Now, read on to begin your journey through the wide and fascinating
world of product management.
9
WHAT IS PRODUCT MANAGEMENT?
CHAPTER ONE
“Nobody asked you to show up.” Every experienced product manager has
heard some version of those words at some point in their career. In this case,
those painfully frustrating words are from Ken Norton, partner at Google
Ventures, in a blog post titled “How to Hire a Product Manager.” Think
about a company for a second. Engineers build the product. Designers
make sure it has a great user experience and looks good. Marketing makes
sure customers know about the product. Sales gets potential customers to
open their wallets to buy the product. What more does a company need?
Where does a product manager fit into that mix?
Those simple questions are what cause not only the confusion, but
also the opportunity that comes with product management. Heck, if
you’re transitioning into product management, these questions might
make you worry that product managers are irrelevant. And if you are
currently a product manager, you might feel a sudden need to justify
your existence. Truthfully, without a product manager a company will
10
THE
PRODUCT
BOOK
continue to operate pretty well—to a point. Yet with a strong product
manager a company can become great.
WHAT DO PRODUCT MANAGERS DO?
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.
There’s a lot behind this simple definition, though. Adam Nash, CEO
of Wealthfront and former VP of product at LinkedIn, summed up
product management by saying, PMs figure out what game a company
is playing, and how it keeps score (hint: it’s not always about how much
money the company makes).
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. They must know how to work with engineers and designers to
get the right product built, keeping it as simple as possible. They must
know how to work with marketing to explain to the customer how the
product fills the customer’s need better than a competitor’s product. They
must do whatever’s needed to help ship the product, finding solutions
rather than excuses. Sometimes, this even means a PM getting coffee for
a team that’s working long hours to show appreciation. By the way, PMs
manage products, not people, so they must achieve everything using soft
influence, effective communication, leadership, and trust—not orders.
11
1.
What
Is
Product
Management?
Even though it’s not always obvious what PMs do from the outside, they
genuinely do a lot! PMs do so much that they’re sometimes even called
“Mini CEOs.”
Ironically, the thing a PM does the most is say “no.” Some people
believe that product managers just dictate what features to build. Given
everyone has lots of ideas for features, why bother with a PM? It’s true
that everyone has lots of ideas, some of them good, but most ideas people
have are for things they want, not necessarily things customers want.
For example, think of an engineer who spends her days using cryptic
command-line tools—I’m sure you know someone like this! This engineer
probably prefers keyboard shortcuts, dislikes GUIs, and favors using code
to explicitly specify meaning. Now, imagine that engineer is part of a team
working on an iPad word processor for senior citizens. Do you think the
features the engineer would prioritize match what the customers need? A
large part of a PM’s job is to figure out the small number of key features
to prioritize for the customer, and to lay the groundwork for long-term
business viability by gracefully saying “no” to the numerous requests that
don’t fit the customer’s needs.
Similar but Different
It’s also worth looking at roles that are related to, but different from,
product management. These jobs get confused with product management
because in some companies a product manager will also handle these
roles’ responsibilities, even though they aren’t the product manager’s
primary strengths. For example, remember how we said a good PM
would do whatever it took to ship the product? Further confusing things,
all of these related roles are abbreviated “PM.”
Project managers are most often confused with product managers.
While there are many subtle differences, they can be summed up by
12
THE
PRODUCT
BOOK
saying that a project manager owns the schedule and helps ensure the
team is on track to meet any deadlines. The project manager will often
work with the product manager, and a product manager will provide
input on the schedule. Project managers are masters of schedules and
Gantt charts, not of representing customers.
Program managers are usually a bit more similar to product managers,
but program managers generally focus more on the “getting it built” side,
working closely with Engineering and Operations. If you’re building a
wearable, for example, the program manager will likely be in touch with
the manufacturing facility frequently, whereas a product manager will
have limited direct interaction with them. Program managers tend to be
masters of execution, sort of like a “super” project manager.
To further confuse things, the title that describes what a product
manager does varies slightly from company to company. Microsoft, for
example, calls its product managers “Program Managers.” Apple generally
splits the product manager role into the “Engineering Program Manager”
(EPM), and the “Product Marketing Manager” (PMM), with the PMM
being closer to our definition a product manager, and the EPM being
closer to a project manager.
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.
Project managers help keep all the rehearsals organized so that the
orchestrawillbepreparedfortheconcerts.Programmanagersareinvolved
in planning the entire season’s schedule for the concert hall, setting things
up so that the project managers can make each performance successful.
13
1.
What
Is
Product
Management?
BECOMING A PM
There’s no obvious path to becoming a product manager. And if you’re
reviewing résumés for potential PM hires, especially if you’re a start-up
founder, it’s not obvious what to look for. Most careers have a very clear-
cut path—you go to school, study computer science, and then you’re set
to become an engineer. Product management isn’t one of those careers.
Because product management is a relatively new discipline, it has a much
less formalized training process than other careers. Given that the role
often comes down to “doing whatever it takes to ship a product that
customers will love and that achieves business goals,” product managers
should be smart, talented people who can figure things out on their own.
Beyond that, product managers commonly have an intersection of a
technical background—not just engineering—such as industry expertise,
and communication skills. The most common type of product manager is
someone with an engineering/computer science background who became
interested in business. PMs often start out as individually contributing
engineers who then find themselves taking on more responsibilities:
conducting customer interviews, working with Design to validate ideas,
and possibly even collaborating with marketing to make sure what they’re
working on aligns with customer needs. They’re not necessarily the best
coders or the most definitive domain experts, but their mix of skills
makes them unique. Sometimes PMs come from Design, Marketing, or
even business school!
At Product School, we often talk about the Product Triangle (Figure
1-1). This is a simple way to visualize and understand where product
management (ideally) sits in relation to other core departments:
Engineering (product development), Design, and Marketing. This
diagram is helpful for two reasons. First, it visually emphasizes that
product management is a generalist role and PMs need to be able to
14
THE
PRODUCT
BOOK
work with significantly different domains. Second, as you go through
the process of building a product, you will shift your balance to different
parts of the triangle—more on this shortly. Thinking about which
leg of the triangle you’re focusing on will let you think about the right
way to communicate—you’ll talk with Design differently than you do
Engineering—and the right goals to set during each phase.
Product
Design
Product
Development
Product
Marketing
Product
Management
Figure 1-1. The Product Triangle, showing product management at the intersection of three
core domains.
A common question about becoming a PM is, how technical do PMs have
to be? They need to know enough that they can work effectively with
engineers, participating in things like bug prioritization and scoping
meetings, but they don’t need a computer science or electrical engineer-
ing degree. Especially for software PMs, knowing how to code even a
little will be beneficial, and if you want to become a PM but don’t know
how to code, we’d highly recommend learning the basics. Fortunately,
there are plenty of resources to help you learn—you can enroll in a boot
camp like Code School or Hack Reactor or take an online course from
lynda.com or Udemy.
15
1.
What
Is
Product
Management?
A big benefit to learning to code is that 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. After
building the small pieces, you combine them to get the big picture.
Learning to code will give you consistent practice thinking this way.
Another common question is, how business-oriented do PMs have
to be? PMs don’t need an MBA—in fact, some tech companies prefer
not to hire MBAs—nor do they need a sales background. 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 such as revenue vs. profit—revenue is how much
money a company takes in, and profit is how much is left after expenses.
In general, when we’re working with people who want to make the
transition to being a product manager, we recommend they start with
an industry/company they’re already very familiar with. That makes for
an easier transition because they likely know the answers to many of the
questions above, even if they don’t explicitly realize it! After you have a
few years of product management experience, it’s fairly easy to switch to
a new domain, as you know the right questions to ask to be successful.
If you’re a founder looking to build your start-up’s product team, we’d
recommend focusing on finding the best product person possible, even if
that person isn’t familiar with your domain.
Types of Product Managers
Whileyouwilloftenhearpeopletalkaboutproductmanagersinthegeneral
sense, you will also hear about specialized product managers. Depending
on your background, you might find one of these specializations a more
appropriate career choice than the general role.
16
THE
PRODUCT
BOOK
The most common specialization is technical product management.
This refers to a PM who has a strong technical background, and who
works on a technical product. For example, this person might work on a
software API where the end customer is a software developer. Technical
PMs won’t be writing the code or performing technical tasks, but they
need to understand the details of what goes into those tasks.
Another specialization is strategic product management. This role is
the complement to a technical PM, and it’s someone who has a strong
business-oriented background.
Once in a while, you’ll also see titles linked to specific verticals or
tasks, such as growth product manager or mobile product manager. These
roles are more focused than the general PM role, and a person in such
a role will have a more specific set of skills, such as being an expert in
all the different things you can do to grow a product—that is, get more
customers using it.
HOW PRODUCT MANAGERS GET PRODUCTS BUILT
While sometimes it might seem like the CEO imagines a product in the
shower, and then tells the engineering team to build it, any one who has
been a CEO knows this is not the case. Product management is similarly
misunderstood by the general public. On TV you’re likely to see the guy
get out of the shower and start hacking on a laptop with bright green
text, occasionally solving a hard problem by drawing on glass. The real
world doesn’t work like that. So, how do products get built? What does a
product manager really do, and how?
In reality, products continuously undergo a product-development
life cycle, and a product manager shepherds the product through each
phase, owning some phases and contributing to others. The product-
17
1.
What
Is
Product
Management?
development life cycle involves discrete steps, and each step emphasizes a
different leg of the Product Triangle.
While the steps are well defined, there are multiple approaches to how
these steps can be implemented. On one end of the spectrum there’s the
lean approach, based on Toyota’s manufacturing methods and adapted
to software/product development by Steve Blank and Eric Ries. 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.
On the opposite end of the spectrum you have the waterfall approach,
where you build something big in a very linear fashion—you spend a
lot of time planning a product, and once you’ve decided what to do,
that’s what you’re going to build and ship even if it takes a long time. The
product moves through each process step by step and, like a waterfall,
things flow one way, and—almost—never change once they’re defined it.
Waterfall cycles might take a year or more.
For software product development, larger and older companies tend
to use a waterfall approach, whereas many start-ups use a lean approach.
As you might expect intuitively—and there have been many studies to
back this up—building products with a lean approach is more successful
because you’re not risking everything on a potentially long, slow-to-
create project. Instead, you risk a little bit to build something small, learn
from it, and iterate. For that reason, even larger and older companies are
shifting towards a lean approach, moving away from waterfall.
The most common approach you’ll encounter is a hybrid of water- fall
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
18
THE
PRODUCT
BOOK
customers don’t want the product you’re building. We’ll mainly focus on
a hybrid approach in this book.
Hardware product development takes a more waterfall approach
because it’s harder to change things you’re physically building. For
example, hardware requires a lot more planning up front, and the iterative
cycles during development to get new hardware builds are a lot longer
than with software. However, the overall principles for building products
are very similar to those for software, and the process is similar enough
that the life cycle stages we’ll teach you about apply for both hardware and
software product management.
In future chapters we’ll dig into each stage of the product-development
life cycle in depth. For now, let’s look at an overview of each stage, starting
with the planning phase.
THE PRODUCT-DEVELOPMENT LIFE CYCLE
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. Sounds easy, right?
Conceptually, it is! The devil’s in the details. To help you see how each
stage connects, before we dive deep, let’s look at a high-level overview of
each stage.
19
1.
What
Is
Product
Management?
Finding and Planning the Right Opportunity
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.
This phase is a critical part of your job. Unlike the other phases,
where other disciplines take the lead, this phase is where product leads,
taking input from other disciplines. It’s probably the most different from
anything expected in another position. Because this is so core to your
job, we’ll cover finding the right opportunity in extreme depth, breaking
it down into three parts: strategically understanding a company (Chapter
2), creating an opportunity hypothesis (Chapter 3), and validating that
hypothesis (Chapter 4).
To a product manager, strategically understanding a company involves
learningaboutaspectsofthecompanythatcontributetoitsproductsuccess
including its target customers, its expertise, its competitive landscape,
and more. Understanding these aspects, which we sometimes refer to as
a company’s context, will help you make the right product decisions, and
start to find focus in the sea of possibilities. A simple example is CNN.
com’s team. They are great at building software products—including a
website and mobile apps—that deliver the news quickly and efficiently
to their customers. Because their PMs know they have software and not
hardware expertise, they are—probably—not encouraging CNN.com to
build a news-focused smart watch, or other hardware product.
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
20
THE
PRODUCT
BOOK
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.
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?
With the company’s context in mind, the next step, which we’ll cover
in Chapter 3, is to create an opportunity hypothesis. What do you believe
is the right thing to work on next? It could be something as small as fixing
a bug that’s been in your backlog for a while, or something as large as
building an entirely new product.
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. A metric is a measurement of a task
a customer does with your product. Collectively, your metrics can provide
some great insight! From metrics, you might find an opportunity, such as
wanting to get higher engagement with a com- ponent of your product.
For example, CNN.com likely keeps track of what headlines visitors
click on, how many people start watching each video, how many finish
watching each video, how many scroll down and read each article, and
more. They might then use this data to pull out conclusions, such as, “We
21
1.
What
Is
Product
Management?
should prioritize video content instead of text because people tend to
watch videos to completion and see each ad, whereas very few people
read articles to completion.”
After thinking about the company’s context and goals, talking with
users, analyzing usage data, looking at existing bug reports and feature
requests, and using other approaches we’ll cover in Chapter 3, you’ll have
an idea about what to do next. But before you start to build a feature,
you should do some type of validation work to ensure this is the right
opportunity to pursue, and that it actually will help you achieve your
goals. You have limited time and resources, and spending a little bit of
time validating an opportunity hypothesis can often save you significant
time and money by keeping you focused on the best opportunities.
Chapter 4 goes into depth about how to validate an idea.
Onceyou’vevalidatedyouridea,you’llneedtodevelopitintosomething
your teams can implement. An important part of the product-planning
phase in the product-development life cycle is scoping the opportunity.
Scoping means clearly defining the opportunity and the customers you
want to target, along with the requirements for the solution. If you’re
building a pen, do you need it to work in space? Underwater? Upside
down? You’ll want to clearly define these situations to help everyone
understand what the product will need to do when it’s finished.
When working in lean or hybrid environments, you’ll often hear
the phrase minimum viable product (MVP). This is a term from lean
methodology that simply means, “What’s the most minimally featured
thing you can build that will address the opportunity well for most of
your target customers and validate your opportunity?” In other words, if
you were to think about the core function you’re trying to let customers
accomplish, what’s the simplest product you can build that lets them
achieve that goal?
22
THE
PRODUCT
BOOK
Continuing our CNN example, if you went back in time and were
working on the first version of CNN’s mobile app, what’s the simplest app
you could build that would provide value to your customers? It might be
somethingwithalistofnewsheadlinesandarefreshbutton,andwhenyou
tap on each, you see the video for the story. Again, the key to identifying
the MVP is that you’re focused on the core functionality it provides to
the user—news, in this case—rather than focusing on all the possible
features you might build in addition to that core function. Identifying the
MVP is a key part of scoping a product because it helps you identify the
most important thing to build first—we’ll cover tips on how to do that
in Chapter 5. This lets you focus your design and development efforts to
create a—hopefully—useful product that you can deliver to customers
quickly, whether as shipped software or software tested in house. Testing
the MVP with real customers will help you figure out what other features
will be in and out of scope, as you quickly will get real feedback about
what customers like and don’t like. Note that 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.
Contrast this with non-MVP-based approaches to product
development, which are especially common in waterfall development. In
that world, you end up spending lots of time trying to build the “perfect”
product with every feature you can imagine, it takes forever to build, and
once it’s out in the real world you discover that customers don’t use half
the features you thought they would.
A key differentiator between lean and waterfall is that lean leverages
MVPs. With a lean approach, you build the simplest thing you can,
gather data about how customers use it, and then refine the product if
needed. This will let you work quite effectively, building only the features
customers want and will use rather than wasting time building things
customers don’t care about.
23
1.
What
Is
Product
Management?
Spending lots of time iterating internally and building features
without releasing a product can be quite harmful to your business. With
our hypothetical CNN app example, if we didn’t take an MVP-based
approach, we might decide to replicate the website completely, including
features like comments, user-submitted video, and customized news
streams. Building all those features could delay our launch by months
and who knows how much of our customer base would use those features
on their phones. Yes, we could use metrics from the website to prioritize
these features, but hopefully you get the point. Additionally, while we
were taking lots of time and building features for our unre- leased app,
our customers wanted a mobile news app and turned to Fox News or
another competitor that built its app using an MVP-based approach. The
customers cared about the core function—getting news on the go—not
about all the extra features. And it’s hard to get customers back after
they’ve turned to a competitor!
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.
To be fair, hardware development often requires you to try to build
more than an MVP because releasing a hardware update is much more
complex than a software update. But keeping the MVP in mind, even
with hardware, will help you prioritize your development efforts.
Sometimes, as we’ll discuss in Chapter 4, your very first MVP will be
human-powered rather than automated. For example, if you’re a PM at Yelp
and want to add a restaurant-recommendation feature, eventually you’ll
create a fully automated algorithm to generate recommendations. But you
could build an initial MVP that makes it appear that the user is getting
automated recommendations when it actually has a human making and
24
THE
PRODUCT
BOOK
sendingtheselists.Ifmanypeoplelikeandusethis feature, thengreat, you’ll
build the automation engine. If no one uses it, then this very lightweight
MVP saved you the time and effort of building the full feature.
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?
Going back to CNN.com, its ultimate goal might be to become the
place people go to for news. This means its success metrics include the
number of views on a piece of content, the percentage of people who
consume each piece of content, the number of articles read or videos
watched in a session, and how often the person comes back to CNN.com.
The reason we don’t solely use page views on a piece of content is because
a person might click on an article but never read it. That means that
person is not actually getting news/consuming content from CNN.com.
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 ex-
planation 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.
One of the biggest reasons that other stakeholders, such as design
and engineering leads, are involved in the PRD is that it will be up to
them—not the product manager—to figure out the right solution for this
opportunity. After all, the design and engineering teams are the experts
in their domains, and the product manager is not, even if she started her
career in one of those domains!
PRDs gained a bad reputation from waterfall development because
they were huge dictating documents that people disliked reading. In
25
1.
What
Is
Product
Management?
fact, 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. We’ll go
over how to effectively write and use a PRD in Chapter 5.
Once we have this first draft of a PRD—clearly identifying the
opportunity/problem and success metrics—and all stakeholders have
agreed on the right problem to focus on next, we’ll move on to the next
phase of the product-development life cycle.
Designing the Solution
During this phase, covered in depth in Chapter 6, we’ll figure out a feasible
solution to the problem we’ve identified.
Here, PMs will primarily work with the design team, but the
engineering team will offer input as well, to help gauge feasibility. For
example, a CNN.com PM might have found that her readers com- plete
a lot more articles when a virtual reality 360° video is included, meaning
better success metrics, and the PM wants to integrate 360° videos into
more content. The design team might then create designs where every
breaking news story has a live-streaming 360° video to put viewers right
there with the reporter, but the engineering team might not be able to
build a live-streaming solution. This means the design team needs to
come up with another solution that the engineering team can implement.
Even though the PM won’t be coming up with the solution herself,
she’ll stay actively involved in this phase. She’ll likely work closely with
design to conduct user research, looking at people’s current behavior.
26
THE
PRODUCT
BOOK
She’ll also help communicate with Engineering to ensure Design isn’t
working in isolation—that everyone is working together to solve the
customer’s problems.
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?). It’s
uncommon to find a designer who’s an expert on every one of these aspects,
and a PM will likely be working with a design team rather than with just
one designer to figure out how the product should function and look.
If possible, you’ll want the design team to produce prototypes of the
solutions that they can test with customers to validate the design. These
prototypes could be printouts that you swap in when the customer clicks
on something, clickable mockups working with fake data, etc. The key is
to have something that accurately represents the solution, but that you
can mock up without having to actually build the solution.
Design is done when you have validated a prototype as a suitable
solution, Engineering has agreed to the viability of the solution, and
you’ve defined the look and feel of the solution that all stakeholders
have agreed to.
Building the Solution
Once you’ve defined the problem and designed a solution, it’s time to
build it.
Companies have different approaches to implementing solutions,
depending on their history, the product, and their desires. For example,
if you’re working on a mobile app, it’s very easy to release a new version
to customers every week, and development is likely focused on smaller
but more frequent releases—lean development is very common with
mobile and web apps. If you’re building hardware, there is a long time
27
1.
What
Is
Product
Management?
between the product’s design and when its hardware is ready for mass
production. Hardware-engineering companies generally have fewer but
very high-quality releases. After all, it’s difficult to release a hardware
update to fix a bug!
In Chapter 7, we’ll cover some of the most common software-
development methodologies, along with tips for working with engineers.
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.
A note of caution if you’re currently an engineer who wants to
transition to product management—development might turn out to
be the most frustrating phase to you because you are not an engineer
anymore. You will not be writing code for the product, or telling people
what code to write. Your job is to stand aside, and let the people who are
still engineers write the code. You help them however else you can, even
if it’s getting them coffee, but don’t tell them what to do unless they ask
for your help. Furthermore, as a PM, you’ll be put into positions where
you have to negotiate taking on technical debt, meaning you need to ask
Engineering to write kludgey code that isn’t sustainable in the long term
to get something done in the short term.
Engineers hate taking on technical debt—they want to write a com-
plete answer from the outset. If you come from an engineering back-
ground, 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.
Also, although we’re presenting the product-development life cycle in
averylinearfashion,it’salotmoreiterativeinreallife,especial- lybetween
28
THE
PRODUCT
BOOK
designing and building the solution. For example, 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.
During the development phase a PM should try to find effective
opportunities to share prototypes of the product with customers or people
inside the company, so that you can get early feedback about the product.
Does it address the customer’s need effectively, or is there a big tradeoff
you didn’t anticipate? If you prioritize building the minimum viable
product you previously identified, then you can start testing the core
product once the MVP’s ready. It’s important to ask for this feedback at
the right times—if you wait until right before you release to get feedback,
you might not have time to act on what you learn.
New information that affects the product’s scope might come up during
development, too. Going back to our example of 360° live-stream- ing on
CNN.com, maybe a third-party company released a tool that makes it
very easy to live-stream these videos. That’d make it simple for CNN.com’s
engineers to add on-the-scene 360° video to breaking news stories, which
was originally deemed out of scope because of the technical challenge.
In the product-development approach we’re presenting in this book,
it’s always best to do more investigation up front, so that you don’t waste
resources designing a solution and then have to change large parts of
it. But the best product managers are ones who know they can’t define
everything perfectly up front, and that it’s generally impractical to spend
months trying to do so. Instead they do their best to plan, but also seek
out new information to help the product get better, and react to any
needed changes with open arms.
The development phase of the product-development life cycle is done
whenaworkingproductthathasbeenthoroughlytestedisreadyforrelease.
29
1.
What
Is
Product
Management?
Sharing the Solution
As much as we’d like to believe that if we build it, they will come, the world
doesn’t work that way. Product marketing (Chapter 8)—in fact, marketing
in general—is an incredibly important part of the product-development
life cycle, and really begins after we’ve built the solution. This phase of the
life cycle is where we launch our product, sharing it with the world and
letting our customers know how our product will help them.
Effectively telling the world about our product is so important that
some companies even create a separate position, the product marketing
manager. A PMM is very similar to a PM, but a PM tends to be more
internally focused—getting the product built—while a PMM is externally
focused—working with customers to understand their needs and to
communicate the product’s value.
Early in the first stage of the product-development life cycle, even
before scoping the opportunity, it should be clear what this product
will do for the customer. This isn’t a list of what features it has or what
the product does, but rather what problem it will solve. In the product
marketingphaseoftheproduct-developmentlifecycle,youfigureouthow
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.”
For example, going back to CNN.com’s 360° VR video streaming
feature, if we promoted the feature itself, “Live 360° VR video streaming,”
most customers wouldn’t know what that meant—or care. Instead of
talking about the specific feature, we can focus on the value and the
benefit this feature provides: “Be on the scene with our reporters.” We
might then go on to say what the feature is and how to use it, but we’ve led
with a clear message about why a customer should care.
30
THE
PRODUCT
BOOK
This phase of the product-development life cycle is more than just
mes- saging, though. We’ll also plan for the product’s release. Release
might involve planning a beta test, creating marketing assets for a website
or ad, working with key partners before release, briefing the press, or
planning a launch event. The exact needs will vary from launch to launch.
Broadly, this phase of the product-development life cycle is done when
the product is launched, but there will likely be many marketing campaigns
and tasks to help achieve the product’s success metrics beyond the launch.
Marketing will continue even while the team, in- ternally, has moved on to
the next version of the product, or to a completely different product.
Assessing the Solution
The last phase of the product-development life cycle is to assess how the
just-completed iteration of the cycle went, see if you’re on track to achieve
your success metrics, and come up with a recommendation for what to
do in the next iteration. As you might guess, that recommenda- tion feeds
into the initial planning phase of the next iteration.
During this phase, you will meet with the team that you built the
product with and assess how it went. Did everyone get so burned out that
half the team quit? Was the team very happy with the process and excited
to work on the next project? What was the team’s overall competitive
strength, and what could they improve at? Use this feedback to determine
what went well, and what you should do differently the next time around.
Now that the product’s released, you should start seeing real data
about how people are using it. Is it in line with your expectations, or is
something far off? And most importantly, does it look like you’re on track
to achieve your success metrics? For example, CNN.com could look at
how many people are watching its new 360° broadcasts and whether the
overall number of people getting their content from CNN has increased
after the release of this new feature. If the number of peo- ple watching
31
1.
What
Is
Product
Management?
these broadcasts and seeking out more content on CNN improved, then
your product was a success. If it’s unchanged, then you should evaluate
why this strategy didn’t work how you expected—why don’t customers
like it?
Once you’ve had a chance to see how your new product was received
by your customers, you’ll put together a recommendation for what’s next:
should you iterate more on this feature/product, move on to something
else, or end-of-life this feature/product? This recommendation will help
inform the next iteration through the product-development life cycle,
and we’ll explain how to create a good recommendation in Chapter 9.
As you can see, there’s a lot to product management and the product-
development life cycle! But don’t worry, the following chapters will break
each step down into more detail and help you understand how to be a great
product manager who makes awesome products that customers love.
32
STRATEGICALLY UNDERSTANDING A
COMPANY
CHAPTER TWO
One of the first things a great product manager should do before even
thinking about a product is to understand the company that makes it.
Every company is a little bit different, and they have different priorities,
values, strengths, and weaknesses. Knowing these details about a
company—understanding the full context of its current situation—is
the starting point to find and evaluate product opportunities and make
strategic product decisions. We’ll build upon how to leverage these details
in the following chapters.
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?
WHAT PRODUCT ARE WE BUILDING?
This category of analysis is focused on the company’s current product.
This might be an existing product that you’re tasked with improving, or it
might be the next new product that you want to build.
33
2.
Strategically
Understanding
a
Company
Why Does the Company Exist?
The most fundamental thing to understand about a company is why it
exists.What’sitsmissionstatementor,evenmoreimportantly,itscorebelief:
the value it adds to the world that differentiates it from other companies?
Simon Sinek has a great TED talk called “How Great Leaders Inspire
Action” and a book on the same topic, Start With Why. In both, he
advocates for what he calls the Golden Circle (Figure 2-1). Specifically,
he says that the “why” of a company is what people actually care about
and buy into. How you deliver that value and the products you create
will build on top of this core value. From a product point of view that
“why” is your guiding light—it will help you figure out what fits with the
company’s reason to exist and what doesn’t. 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? Themes in movies are often
obvious: love conquers all, revenge doesn’t lead to happiness, etc. A
company’s theme can be a little harder to decipher. Often its theme is
expressed as a value within the company’s mission statement, which
you can usually find on the website. But even if a company has a clear
mission statement with a clear theme, it may forget about it when making
decisions, leading to mixed results.
Let’s look at Sinek’s example of Apple. If Apple started with the “what,”
which many companies do, Sinek asserts its messaging would read, “We
make great computers. They’re user-friendly, beautifully designed, and
easy to use. Want to buy one?” That’s fine, but it sounds pretty generic.
Many other PC manufacturers even make the same claim!
34
THE
PRODUCT
BOOK
WHY
HOW
WHAT
Figure 2-1. Simon Sinek’s Golden Circle, starting with “why” as the most important as- pect
of a company.
Instead, recall the Think Different campaign Apple ran in the late ’90s,
which talked about Apple’s “why” without even mentioning the products:
“Here’s to the crazy ones.” Starting from that mission state- ment, Sinek
says a more realistic marketing message from Apple would be, “With
everything we do, we aim to challenge the status quo. We aim to think
differently. Our products are user-friendly, beautifully designed, and easy
to use. We just happen to make great computers. Want to buy one?”
That version starts with the “why” (challenging the status quo), then
moves into the “how” (being user-friendly, etc.), and finally the “what”
(selling great computers). It’s way more compelling than the first version,
and it also says a lot more about what Apple represents, and who they are
as a company.
“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
35
2.
Strategically
Understanding
a
Company
makes for those products, should emerge from that value. If it doesn’t,
there’s a good chance that decision isn’t working well for the company.
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. It’s unlikely to make a toaster oven,
even a Wi-Fi-connected one, because that doesn’t organize the world’s
information, make it accessible, or drive us forward. However, Google
did purchase Nest, which made appliance-like devices, including a
thermostat and a smoke detector. Nest’s products involve organizing
information about your home and applying computer science to that
information to make your home function better. The Nest Thermostat
learns you behavior and automatically adapts how it heats and cools your
house to save energy—thereby saving you money—while still keeping
you comfortable.
It’s worth noting that every company whose fundamental mission
is “to make money” rather than focusing on what value it can add to
customers’ lives has failed. Sinek discusses this in detail in his talk. If your
company functions well and customers want the products you’re making,
you’ll make money. Revenue is be validation that a company is doing the
right thing for its customers—revenue should not be a company’s reason
for existing. This isn’t true for only socially conscious companies like
TOMS, the shoe company, but for all com- panies. Customers will pay for
your product because it makes their lives better, not because they want to
give you money.
Similarly, companies that start without a mission, but rather with
some invention that they’re trying to find a use for, often fail. Specifically,
if your company started because someone said, “This is a cool idea—can
we sell it?” rather than “This invention would make people’s lives better
because…,” you have a solution looking for a prob- lem. An engineering
36
THE
PRODUCT
BOOK
innovation by itself doesn’t make a product— products are solutions
to problems people encounter. You’ll often hear startups talk about
“pivoting” because they found customers didn’t want the product they
made, and the startup is trying to repurpose what it built to something
customers will use.
Some companies are moderately successful without having a clear
mission statement. But they struggle to grow because it’s be unclear to
their leadership why their product was successful and how to expand the
product line. The result is a product portfolio that feels very disconnected.
Misfit, which was purchased by Fossil, achieved suc- cess with its Shine
wearable activity tracker, but it didn’t have a clear mission. Its follow-up
products included a smart light bulb and sleep sensor, and they failed to
gain much attention. Misfit appears to be aware of this problem and has
tried to fix it, though, as it’s now focused on making wearables a natural
part of your life, with fashion-conscious activity trackers, and smart
headphones with a built-in activity tracker. The implicit value proposition
is that Misfit wants you to live a better life, and it achieves that by enabling
you to analyze your life, especially your health.
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.”
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.
37
2.
Strategically
Understanding
a
Company
Let’s imagine we’re building a camera accessory that plugs into the
iPhone, like the DxO ONE. Your customers are likely people who enjoy
shooting with their smartphones, but want better image quality than the
built-in camera provides. Since we’re iPhone-specific, we won’t care about
people with Android phones. And, since we’re building an accessory that
people need to pay extra for, we will ignore people who are happy with
the built-in camera.
But even amongst all the customers we do care about, there’s a lot of
variability. Maybe one loves taking photos of his dogs while another takes
photos of her ferrets. Dealing with lots of real people and their variability
can make for complex discussions—our camera accessory has to work
with cats, dogs, ferrets, rabbits, etc. Instead, it would be easier if we just
abstracted things and said, “Our customers take photos of their pets.”
We can take the various common traits we care about in our potential
customers and abstract them out into a persona. A 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. A great way to think
about the difference is that Facebook and Snapchat have many of the
same customers, but their internal personas—how they segment those
customers and what aspects of the product they care about—are different.
You’ve likely already talked about a persona without realizing it. When
someone asks, “Can my mom use it?” they don’t mean their actual mom,
she might be a rocket scientist. Instead, they mean the “mom” persona
of a middle-aged person who is never the first to buy new technology,
and will break many gadgets simply by turning them on. When we say,
“Can my mom use it?” we’re actually asking if the product is user-friendly
enough that someone in the “mom” persona can use the product to
achieve a goal without breaking it and without asking for help.
38
THE
PRODUCT
BOOK
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—you want enough detail that you can imagine yourself
in the persona’s shoes. Roman Pichler put this into a template you can fill
out to start crafting your own personas (Figure 2-2).
ROMAN’S PERSONA TEMPLATE
PICTURE AND NAME DETAILS GOAL
What does the persona
look like? What is its name?
Choose a picture and a name
that are appropriate and that
help you develop sympathy
for the persona.
What are the persona’s
relevant characteristics and
behaviours? For instance,
demographics such as age,
gender, occupation, and
income; psychographics
including lifestyle, social
class, and personality;
behavioural attributes like
usage patterns, attitudes,
and brand loyalty. Only list
relevant details.
Why would the persona
want to use or buy the
product? What benet does
the persona want to achieve?
Which problem does the
persona want to solve?
Figure 2-2. Roman Pichler’s persona-building template, available at www.romanpichler.com
and included under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA
3.0) license, https://creativecommons.org/licenses/by-sa/3.0.
While it’s tempting to make your personas very detailed, describing every
aspect of the person’s life, they can quickly become overwhelmed with
lots of irrelevant details. 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.
39
2.
Strategically
Understanding
a
Company
The key things you’re looking for are this person’s priorities, related to
your product/area of expertise. What is the persona “IT Tech Tom” trying
to do that’s significant and what’s actually insignificant: 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? For example, IT
Tech Tom might be very busy his entire workday with customer support
tickets. He would likely favor a new automated machine deployment
system over one that involves lots of manual intervention.
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.
Don’t forget about the social or emotional side. Dental headgear
can solve orthodontic problems—a significant pain point—but do you
want to be the kid on the playground who has to wear headgear for two
years? Other factors, like which distribution channels reach the various
personas, and whether they’re willing to pay for different parts of the
product, can help differentiate personas.
Personas contain demographic information only if it’s relevant. For
example, Airbnb’s “host” personas probably don’t include how much each
personmakesperyear,buttheylikelydoincludewhyapersonaisinterested
in renting her place out. A young urban host might be renting a couch or
second bedroom to help pay for his condo. In fact, he might have to do so,
meaning he cares most about maximizing how much he gets for his space
vs. having someone there all the time. A retired couple who are snowbirds,
flying from Pennsylvania to Florida each winter, might want to rent out
their vacation home when they’re not using it, to supplement their income.
They’ll likely prefer Airbnb guests who stay for longer periods of time,
and treat the home like their own, even if it means their vacation home is
empty periodically. This might be counter to what you know about typical
40
THE
PRODUCT
BOOK
marketing theory, where demographics are key. Again and again, product
theory and practice have shown that focusing on a common problem, pain,
or desire yields better segmentation than demographics.
Harvard Business School professor Clayton Christensen has been
working on a customer-segmentation approach he calls “jobs to be done”
foroveradecade.Thinkingthiswayhelpsbuildgreatpersonas.Theexample
Christensen gives is that when a fast-food company tried to improve its
milkshake sales, it first did traditional demo- graphic segmentation and
asked each persona (e.g., the 18–35-year- old milkshake drinker) about her
ideal shake and implemented changes. Sales were stagnant.
But when the fast-food company focused on who bought milkshakes,
when they bought them, and where they drank them, it found a different
way to segment its customers. One segment bought milkshakes in the
morning to keep them feeling full until lunch. As an added benefit, the
morning milkshake gave them something to occupy their free hand while
driving during a boring commute. That group wants a milkshake
36 that takes a while to drink so that it lets them feel full longer
and lasts for the commute. Now consider another segment: customers
buying milkshakes as a special treat for young children. Kids likely just
want a tasty treat and don’t have the patience to drink a milkshake for 30
minutes. Using pains and goals instead of just demographics will help
you segment your customers into useful personas.
It’s possible your product has multiple personas. For example,
the people who read and write reviews on Yelp are customers, but the
businesses these people review are also Yelp’s customers. Create multiple
personas if needed, and identify the primary one you want to satisfy.
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. This is common with enterprise
41
2.
Strategically
Understanding
a
Company
software, and you’ll need to create separate personas for these cases.
Ultimately your goal with each persona is to have enough information
and detail about that category of customer that you can imagine yourself
in this person’s shoes. This will help you empathize with that customer,
understand his pain points, and think about ways your product can solve
that pain (we’ll go into this in depth in Chapter 3).
Because personas help you understand what a group of customers
is like, a key piece of a persona is to be authentic—if you find your
persona is incredibly busy, working 80+ hours/week, how much time
do you think he’ll have to learn how to use your product? If you fail
to note how much your persona works, you could make the wrong
product decisions, errantly assuming this persona has time to watch a
long onboarding video tutorial.
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.
Many companies use Word or Google Docs files with their persona data,
and there are specialized tools that explicitly manage your personas and
organize the research that goes into each one (As of the time of writing,
the landscape of persona tools is so in flux that we’ve elected to leave it
up to you to search and find what’s current). If there’s nothing written
down, it’s still likely the company has a rough idea of who its customers
are. Use that knowledge to write down a first draft of the persona, you
will revise it over time.
It’s not mandatory to have pre-existing customer knowledge to build
a persona. Just make your personas rough at first, and as you learn more
about your customers, refine the personas, perhaps dividing them up and
creating a new persona when key differences appear. You might even find
as you talk with customers and show them prototypes of your product/
feature that someone you thought was a certain per- sona really isn’t.
42
THE
PRODUCT
BOOK
Take Airbnb, for example. Even though business travelers travel
frequently, they might not be the best persona for Airbnb to focus on
because they expense their hotel rooms, meaning they’re not price
sensitive, they care more about service than connecting with the host,
and they often have rewards cards that let them accumulate free stays
for personal travel. Airbnb focuses on making interactions with your
host and other locals part of your travel experience. Business travelers,
however, are there to work, not to feel like a local. All of that means they’re
currently better served by regular hotels, and Airbnb might choose not to
spend lots of time targeting that persona right now.
You’ll also want to ensure your personas align with what your product
does. If you’re building payroll software for a small to medium-size
business, your personas should be based on coffee shops and doctor’s
offices, not a stay-at-home dad. Stay-at-home dads won’t have any reason
to buy your software, and you want to spend your time making decisions
based on the customers who will buy and use your software. Note that
“everyone” is not a persona, as “everyone” is too vague to help you make
decisions. Many people think that big companies like Google, Facebook,
and Apple target “everyone,” but they don’t and are quite forward about
it. Facebook started off targeted at one per- sona, college students. Over
time Facebook grew, adding high-school students and beyond, and its
current customer base is very diverse. Facebook likely has many internal
personas, but when it releases new features, they’re still targeted at
specific personas. A “Henrietta High- School Student” persona doesn’t
care about the reviews feature on busi- ness pages, but a business that
created a Facebook page certainly does! Another great attribute to
consider about your personas is where on the adoption curve they fall.
Not everyone buys/starts using something new at the same time. There’s
a general theory of adoption—which can refer to a new product or a new
feature—that says there’s a tiny group of early adopters that have to be
43
2.
Strategically
Understanding
a
Company
the first to have new things— think of the first person you know to own a
smartwatch. Then, there’s a slightly larger group of people who like being
one of the first—but not necessarily the first—to have something new—
think of the first person you know who bought an Apple Watch but didn’t
own a pre- vious smartwatch.
Unfortunately, there’s a gap (see Figure 2-3) before you get to the
next group of people. If your product’s awesome and delivers on a value
proposition your customers care about, you’ll continue on to the next
step, mass-market adoption, when the bulk of potential cus- tomers buy/
use your product. Eventually, even the late adopters—the people who
always seem to be years behind everyone else technology-wise—will start
using your product. Considering where your various personas fit into this
curve will help you understand when they’re likely to adopt your new
product or feature. This will help prioritize features. Early adopters will
tolerate missing features that laggards might require, for example.
Market
Share
A
D
O
P
T
I
O
N
G
A
P
Time of adoption
Investors
Early
Adopters
Early
Majority
Late
Majority Leggards
Figure 2-3. La curva de adopciĂłn donde el eje X representa los grupos de clientes que
potencialmente comprarĂĄn tu producto con el tiempo. El eje Y representa la cuota de mercado
aproximada de cada grupo.
44
THE
PRODUCT
BOOK
But if your product isn’t awesome, when you hit the chasm before
mass-market adoption, your growth will stop because your product
doesn’t provide enough value to most people’s lives. The mass market
won’t adopt it.
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. This gives you
a great immediate filter to make sure you’re making strategic decisions
about what to do next.
45
2.
Strategically
Understanding
a
Company
CHAPTER TWO TIP
Throughout this book, to give you an additional perspective, we’ve
asked experienced product managers to share their best advice about
each chap- ter’s topic.
Our first tip comes from Jeremy Toeman, vice president of products at
CNET. Jeremy runs CNET’s audience development, engagement, and
social media teams, and he’s responsible for building CNET’s multichan-
nel products, including web, mobile, and apps. Jeremy has more than 20
years of experience, including being VP of product management at Sling
Media; working on Dropcam, Sonos, and Sphero; and founding multiple
companies that had successful exits. In other words, he knows what he’s
talking about! Here’s what he has to say about personas.
MAKING PERSONAS REAL WITH EMPATHY 41
With ~20 years under my belt, I’ve noticed the consistent trend is for
product managers to define personas with 90% demographics, and 10%
wants/needs/emotions. Maybe less. For example, it’s easy to create Jill—a
23-year-old in a major metro who has a roommate, loves travel, and is very
into the DJ scene. Jill is thinking about buying her first car. That’s a great
starting point. But it’s barely the tip of the iceberg.
Does Jill care about what the car says about her, or does she care about
fuel efficiency? Is Jill focused on saving money, or on resale value? Does
Jill care about the car tech, or just that it gets her places? Further, does
Jill enjoy the research process, or does she just want to be pointed in
the right direction? Is she going to make a little comparison spread-sheet
for herself, or just wing it? Far too often products are coming to market
without considering the needs of the individual, as opposed to pure
46
THE
PRODUCT
BOOK
demographic fit. All of the above scenarios are valid to a product manager
who is designing a site/ app to cater to car buyers. But a simple review of
car-buying websites shows a distinct lack of consideration for emotional
needs versus purely practical ones.
When the TV industry tried to bring 3D technology into the house, they
showed a distinct lack of empathy. Sure, 3D movies were performing
well in theaters, so it made logical sense to bring that kind of tech into
the home. But an empathic product manager could have easily pre- dicted
the poor reception: movie theaters are primarily solitary (though shared)
experiences, whereas family/living rooms are primarily social experiences.
And no family wants to sit on the couch wearing a bunch of goofy glasses
(not a problem in a darkened theater).
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.
47
2.
Strategically
Understanding
a
Company
Use Cases
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.
Day to day, a PM will need to think about what use cases they want
to support for their product, which helps in finding and prioritizing
opportunities. The use cases will affect everything from what features
you prioritize to solve your customers’ problems to what customers you’ll
market your product to.
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. Conversely, the iPhone isn’t designed to help you press
cloves of garlic, although you could theoretically use it to do so—we’d
recommend buying a garlic press instead. Apple cares about the former,
not the latter. The choices it makes will be focused on improving email
on the go, even if it means a future iPhone is no good for cooking with
garlic. That example is pretty drastic and obvious, so let’s look at a more
subtle example companies often face. One major category of company
is called enterprise or B2B (business to business), which applies to
companies that create tools to address other companies’ work-related
needs. B2B companies will frequently pick a size of customer company
to focus on—small, medium, or large—and then further focus on select
industry verticals.
Gusto, formerly ZenPayroll, is an HR-solutions company for small
businesses. It realized that small businesses have a wide range of fairly
complex “run the business” (RTB) needs such as HR, accounting, and
office-administration. One person usually can’t do all of those tasks,
small businesses don’t have the resources to hire many people to do
those tasks, and existing tools like ADP are overkill for small businesses.
48
THE
PRODUCT
BOOK
Gusto’s initial persona was likely a small-business owner—we’ll call
her “Suzanne Small Business Owner.” The Gusto website lists instances
of this persona, including in her repertoire tech startups, coffee shops,
auto shops, creative agencies, law firms, and restaurants. Those are the
customers Gusto targets.
Let’s pretend Suzanne owns a coffee shop. Put yourself in her shoes for
a second—what are the RTB tasks she has to deal with? The simplest ones
are around payroll: she wants a way to collect W2-related infor- mation
(US-government-required work forms) for her employees, she wants an
easy way to pay employees, and she wants an automated way to provide
them with tax information. These situations she wants to address—
problems she wants to solve—are use cases she might want to use Gusto
for, and Gusto will likely build features to solve these problems.
At the top of Gusto’s website is a Payroll link. When you click on
it you’ll see that Gusto specifically states how it has employee self-on-
boarding for W2s and more, payroll solutions, and automated taxes. It
has built features into its product to enable it to work in these use cases
that its target persona, Suzanne Small Business Owner, has.
Gusto initially focused on one use main use case: payroll management.
But over time it has expanded to cover more use cases, such as health
insurance. Over time, Gusto will likely continue to help small businesses
simplify their RTB tasks. They’ll be addressing more use cases that
Suzanne Small Business Owner deals with.
However, if a large business tried to use Gusto, the business would find
features it needed lacking because its requirements are more complex than
those of the small businesses that Gusto targets. Gusto doesn’t handle all
the use cases for a large business, but a more complex product like ADP
does handle those use cases.
49
2.
Strategically
Understanding
a
Company
Down the road, Gusto could choose to expand to support another
customer, a large business. To address that customer, Gusto would create
personas to represent the different types of large-business customers,
like “Multinational Matt.” Gusto would then add features to the product
to address the use cases large business have but small businesses don’t,
like dealing with multiple international offices. This would be one way to
grow and to gain more customers. However, supporting large businesses
and their use cases isn’t currently a priority for Gusto, so it hasn’t built
features to address these needs.
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. Adding features to support new use
cases or making it easier to achieve current use cases is a common source
of product opportunities.
Enterprise vs. Consumer Companies
Related to use cases and personas is knowing if the company is developing
enterprise (B2B) or consumer (also called business-to-consumer or B2C)
products. This simply means asking whether end customers are using the
product in their personal lives, or at work. You likely don’t need payroll
software at home, and you likely don’t need a smart- phone-connected
sous vide device at work.
The primary difference in how these companies function is that B2B
involves more decision makers, and the people who decide to buy the
product are often not the ones using it—e.g., a CTO will approve buying
software for HR, but it’s HR who uses it day to day. B2B companies often
have larger sales forces with specialized roles such as sales engineers
who help integrate the product into the customer’s environment, and
customer-training roles. You’re unlikely to just start using SalesForce out
of the box, for example, nor are you expected to.
50
THE
PRODUCT
BOOK
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.
The tools and techniques you’ll learn in this book will apply to both
styles of companies. You’ll build personas and break down use cases
regardless of whether you’re building B2B or B2C products. Just be
aware that you’ll have to do extra legwork to account for the additional
decision makers and their personas in a B2B company. B2B software is
also more likely to be subject to legal compliance requirements and to
need to function in a multi-user environment, which creates additional
fundamental product requirements that B2C software doesn’t have.
HOW DO WE KNOW IF OUR PRODUCT’S GOOD?
In Chapter 1, we mentioned that a big part of product management is
knowing how we keep score. Metrics, in particular success metrics, are
how we measure that score.
Metricsarethemeasurementofdifferentaspectsofyourproduct.These
might include things within your product, like how many people complete
a task, or things affected by your product, like how much revenue you’re
making. Success metrics, sometimes called key performance indicators
(KPIs), are the key metrics that define how we keep score, like how many
goals you scored in a soccer game.
Success metrics are useful because they help us validate if our current
strategy is working, and if it’s not we can dig into the overall metrics to
come up with a hypothesis for how we could make changes to achieve our
success metrics (more on this in Chapter 3). While product management
51
2.
Strategically
Understanding
a
Company
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” we talked about earlier. If part of your
company’s mission is that you want your customers to love your products,
then a key ongoing, long-term strategy company success metric will be
how satisfied your customers are with each product.
You will have additional success metrics that change over time based
on your short-term goals. For example, it’s common to see companies
switchingtheirshort-termgoalfromgrowth(peopleareusingourproduct)
to revenue (people like our product enough to pay for it).
When goals change, what was a success metric one week might just be
considered a regular metric the next week.
Generally, you’ll have separate company and product success metrics,
and the product success metrics will support the company metrics.
Maybe your current company success metric is brand awareness, a
common initial success metric for startups. In that case, your product
success metrics will include number of downloads of your app, visits to
your website, and so on: metrics that indicate people are aware of your
company and products.
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: Of
those who downloaded the app, how many complete a core task? How
many customers do that task each day/week/month? As your strategy and
success metrics change, your product plan and the features you choose to
work on will similarly shift—you want to make sure what you’re working
on supports your goals and success metrics.
52
THE
PRODUCT
BOOK
It’s critical to compare these metrics over time, allowing you to see
if your strategy is working. You might be using revenue as a success
metric—getting people to open their wallets is a sign they value your
product—and perhaps you have $1 million in revenue right now. That
seems great until you realize you had $10 million in revenue last month.
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.
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, and we could say that completing
the core action is a success metric that supports an engagement goal.
Pinterest’s core action is pinning something. In 2011, when Pinterest
was growing well, over 50% of its weekly users were still pinning things.
Compare this to Viddy, a video-sharing startup that became popular
in 2012. When Facebook started featuring Viddy content on April 24,
Viddy’s growth skyrocketed to about 35 million users, as you see in Figure
2-4. But the daily active users and the people actually posting content was
much lower, peaking around 5 million users, or around 14% of all users.
Even though Viddy appeared to be doing well, with lots of people signing
up, very few completed that core action. Viddy shut down in late 2014.
53
2.
Strategically
Understanding
a
Company
Figure 2-4. A graph of Viddy’s monthly active users (top line) vs. daily active users (bottom
line) for April/May 2012, from KPCB/Mary Meeker’s Internet Trends report.
Now let’s look at the second of Tavel’s three phases, retention. 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. The idea is that
if the product gets better for users over time, they will keep using it and
they’ll miss out if they leave. In fact, it’s better to have slightly slower
growth but a higher percentage of customers continuously using the
product than constant growth but low retention because you’ll end up
with more customers over time.
A simple example of this is frequent-flier points on airlines: The more
you fly, the more status you achieve and the more pleasant flying becomes.
In software, think about social networks. The bigger the audience you’ve
54
THE
PRODUCT
BOOK
built up on Twitter, the more you’d have to lose by stopping using Twitter
and trying to rebuild your audience on another network. Products that
don’tencouragecustomerstocontinuouslyusethemareeasilyreplaceable.
Lyft and Uber are the same for an end customer whether you’ve ridden
once or a hundred times. You likely just request a ride from whichever
service has the shortest wait time. And if a new competitor comes around
that offers an incentive, such as ride 10 times and get $10 in credit, you
lose nothing by deleting the Uber app and using the competitor instead.
The final phase that Tavel describes is when your goal is self-
perpetuation. This means your product has various loops that keep
the customer engaged, and encourage other customers to get engaged.
Your success metrics will be around how often people complete these
loops. Pinterest gets better when more people post pins because this
leads to better discovery of new, relevant things to pin. And sharing
notifications (which we’ll look at more in Chapter 3 with the Hook
Canvas) encourage both new customers to pin something and existing
users to return to the product.
Tavel goes on to describe cohort performance as the ultimate success
metric your company should look at over time, encompassing all three of
these stages. Specifically, look at the number of weekly users completing
the core action and the percentage of weekly active users completing the
core action over time. This shows growth from the size of the cohort,
engagement from the ratio of users completing the core action, and
retention from your performance over time.
While these stages don’t apply directly to some products, like a B2B
product a company mandates its employees use, the principles are still
applicable. You want your customers to be able to complete the core tasks
in your product smoothly and repeatedly, and as long as those core tasks
align with use cases your customers care about, your product is off to a
good start.
55
2.
Strategically
Understanding
a
Company
Vanity vs. Actionable Metrics
As product managers, we see a lot of metrics. Some are more helpful to
us than others, and we often talk about two categories of metrics: vanity
and actionable. 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.
Instead, product managers need to focus on actionable metrics that
let us make decisions. Now that we know only 10 people completed our
product’s core task, we can look at other metrics to try and figure out why
so few people were engaged with the app.
How to Measure Metrics
The most common way you’ll measure metrics is by adding bits of code
into your product to measure customer behavior, and to automatically
collect the individual measurements into an analytics tool, like Google
Analytics. Usually these measurements are very simple: How many people
up- loaded a file? How many people clicked this button? How much time
did a person spend looking at a web page or a screen in an app? Early on
56
THE
PRODUCT
BOOK
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 (Chapter 5). For legal reasons, customers often have to opt in to
providing this analytics data, which is why you frequently see disclosures
in usage term sheets or pop-ups in software alerting customers that you’re
collecting usage data for a product.
However, not every metric gets captured automatically. It’s tough to
know from an automated tool whether customers like your product or
swear at it multiple times a day when they use it. If your long-term goal
is for customers to love your product, what should you do? Companies
frequently use surveys and interviews to sample groups of customers and
gauge these higher-level metrics. Sometimes these surveys are automated,
such as a pop-up asking how you like the app on a scale from 1 to 10.
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. The idea is
that if customers love your product, they’ll tell others about it. If they’re
ambivalent, they could switch to a competitor. And if they dislike it, they
might tell others to stay away and cost you business.
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.”
57
2.
Strategically
Understanding
a
Company
From those replies, the NPS is the percentage of promoters minus the
percentage of detractors, giving you a score from –100 to 100. Reichheld,
in his 2003 article about NPS, entitled “The One Number You Need to
Grow,” found that many companies’ NPS were low, with a median being
16 across 400 companies, showing that a lot of companies have work to
do to improve customer satisfaction!
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. We’ll dig into how to figure out what
changes to make to improve customer satisfaction in Chapters 3 and 4.
Whew—for such a simple concept, there’s sure a lot to success metrics.
But they are incredibly important to product managers, as they let us
figure out if our product and the strategy we’re taking are meeting our
short-and long-term goals.
WHAT ELSE HAS BEEN, IS BEING, AND WILL BE BUILT?
Unfortunately, you can’t look at a product or a company in complete
isolation around this moment in time. What the company did in the past
likely has an impact on where it is now. Microsoft completely missed the
start of the mobile era, and that has led to its drive now to be “mobile-
first, cloud-first.”
It’s also worth thinking about where a product might go next. While
sometimes you’ll build a product by releasing it to customers, getting
feedback, and reacting to customer demand, you’ll also often need to
think about the long term to support overall company strategic initiatives.
What do you want to do in three months, in six months, or in two years
that you need to lay the groundwork for today? Maybe your product is
free right now but your company wants to add a subscription payment
58
THE
PRODUCT
BOOK
system—your customers aren’t asking to pay you each month, but your
company needs to generate revenue to survive. You’ll need to do work
now so that you can handle billing information later.
Roadmap
Companies generally collect their product plans into a 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. It’s a valuable tool to help people
communicate about the company, both internally by helping employees
understand what projects you’re working on next, and externally by
helping partners anticipate your needs or plan for products you’re
releasing, a situation common with hardware-component providers.
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. This happens over the long term because priorities
can change, and it’s not worth planning out details for things that might
not happen. Just knowing you want to work on something at a high level
is sufficient. Companies and products will have related roadmaps. The
compa- ny-level one defines how all the products come together, and the
product one—obviously—focuses on each specific product. Company
roadmaps are generally determined by senior executives at a company,
such as the CEO or the head of product. Product roadmaps are created by
the product’s PMs, and are often influenced by and exert influence over
the company roadmap.
The factors we discussed at the very beginning of this chapter, in
the “What Product Are We Building?” section, affect the roadmap, too.
59
2.
Strategically
Understanding
a
Company
The best roadmaps are ones where the company has set goals to achieve
and then planned projects that will help it achieve those goals. These
roadmaps will also provide the sense of the ownership needed for each
project, and determine the order in which the projects should happen.
The next chapters will cover how we find opportunities and how items
end up on the roadmap, but for now simply know that roadmaps are not
arbitrary.
Roadmaps take many forms. Sometimes they’re a spreadsheet using
colors to show all the scheduled projects, their timeframes, and what
goal each project supports. Other times companies use a special tool like
Aha! (http://aha.io) that has additional features, such as bug-tracking
integration with Jira so that you can dig into specific details like how each
bug relates to the roadmap. It doesn’t matter what tool you use to create
your roadmap—it matters that you have a roadmap.
There’s one major risk with roadmaps—you don’t know the future,
and if your plans change someone might ask you later on why you didn’t
deliver an item on the roadmap. Keeping roadmaps up to date and
keeping items further out intentionally vague—even if you have more
accurate timing estimates—can help alleviate this issue.
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?
At Product School, we had a student who cofounded a service focused
on helping schools book their facilities for other events. Originally, he and
his company were not aware of any other competitors. However, while
60
THE
PRODUCT
BOOK
the student was in class and working on his final project, he discovered
that another company had pivoted from focusing on broader booking
services to focusing specifically on schools. While this was validation that
there’s an opportunity with the use cases his company was targeting and
it focused on delivering a better product than its competitors, it stressed
him out knowing that his company wasn’t the only one playing in that
space anymore!
Beyond competition, what’s going on in the industry in general? Has
some broader invention or change caused every company to drastically
alter its plans? For example, as smartwatches become popular, many
companies are racing to create their own watches or versions of their apps
for watches. And with Google Chrome now blocking Flash ads, ad tech
companies are forced to adjust their plans to deal with this change.
Broader world changes can impact a company, too. China devalued
its currency in August 2015, possibly to keep its manufacturing rates
attractive, and that has had an impact on revenue for companies that sell
in China. It also might have had an influence any company looking to
build its products in Vietnam.
The world, and especially technology, doesn’t stand still! A great PM
will stay on top of the news to make sure that her company doesn’t fall by
the wayside because it missed a broader force that changed!
A 5C ANALYSIS
If you’ve ever talked with consultants or MBAs, you probably heard
them name-drop a framework or seven. There is a variety of “standard”
frameworks in the business world—we say “standard” because there
are many similar frameworks, and different companies pick different
standards. We’ll cover some common ones in this book, but we will
always prioritize presenting things with a product focus, even if it means
we don’t use a framework.
61
2.
Strategically
Understanding
a
Company
There’s a framework called 5C that’s similar to the areas we just
covered. It’s a situational framework, meaning it helps you understand
a company’s current situation so that you can create an opportunity
hypothesis. The 5C structure is generic—useful to product, marketing,
and more—whereas the way we presented the sections in this chapter is
very focused on product management. It’s good to know what the “C”s
stand for because you’ll likely hear 5C mentioned. Plus if you need to do
a situational analysis on your feet in a meeting or interview, it’s relatively
easy to remember.
• 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.
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school
The Product Book 2nd Edition EN pdf product school

More Related Content

The Product Book 2nd Edition EN pdf product school

  • 1. 1
  • 3. THE PRODUCT BOOK JOSH ANON CARLOS GONZÁLEZ DE VILLAUMBROSIA PUBLISHED BY and
  • 4. The Product Book: How to Become a Great Product Manager Copyright Š2017 Product School All rights reserved. No part of this publication may be reproduced, stored, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, without written permission from the publisher. It is illegal to copy this book, post it to a website, or distribute it by any other means without permission. LEGAL NOTE All trademarks are property of their respective owners. Unless otherwise noted, all text and images are copyright Product School, and they may not be reproduced without permission. ISBNS 978-0-9989738-0-7 PRINT 978-0-9989738-3-8 MOBI BOOK DESIGN The Frontispiece PUBLISHED BY Product School
  • 5. TABLE OF CONTENTS INTRODUCTION 1 What Is Product Management 2 Strategically Understanding a Company 3 Creating an Opportunity Hypothesis 4 Validating Your Hypothesis 5 From Idea to Action 6 Working with Design 7 Working with Engineering 8 Bringing Your Product to Market 9 Finishing the Product-Development Life Cycle Acknowledgments About the Authors 7 9 32 64 109 149 189 218 243 279 300 302
  • 7. 7 INTRODUCTION Thank you for picking up this book! We know your time is valuable, and we will do our best to make this book worth your while. One of the most important parts of being a product manager is knowing who your customers are and what they need. So, who do we believe you are, and what need will this book fill? Fundamentally, you are someone who’d like to know more about product management. Maybe you’re a recent graduate trying to figure out if product management is the right career for you. Maybe you’re an engineer actively transitioning into product management. Maybe you’re a start-up founder figuring out how to build your product division. Or maybe you’re already a product manager who naturally evolved into the role, seeking to fill gaps in your knowledge. Furthermore, there’s a lot of wisdom out there regarding best practices for product managers, but most of it focuses on parts of the product- development life cycle. This book will give you an end-to-end view of what goes into building a great product, as well as what product managers do each day.
  • 8. 8 The upcoming chapters will cover a mix of theory and practical advice to teach you how to identify an opportunity, and build a product successfully to address that opportunity, whether the result is a new product or a refinement of an existing product. Whether you are new to product management, or an experienced veteran, this book is here to help you learn the needed skills to be a successful and effective product leader. A brief word of warning: Much like chess, poker, and Minecraft, product management is easy to learn, but can take a lifetime to master. If your goal is to be a product manager, consider this book the start of your journey. Becoming a truly effective product manager takes practice! If after reading this book you still want to become a product manager, consider enrolling in Product School, the world’s first tech business school. Product School offers product management classes taught by real-world product managers, working at renowned tech companies like Google, Facebook, Snapchat, Airbnb, LinkedIn, PayPal, and Netflix. Product School’s classes are designed to fit into your work schedule, and the campuses are conveniently located in Silicon Valley, San Francisco, Los Angeles, Santa Monica, and New York. Now, read on to begin your journey through the wide and fascinating world of product management.
  • 9. 9 WHAT IS PRODUCT MANAGEMENT? CHAPTER ONE “Nobody asked you to show up.” Every experienced product manager has heard some version of those words at some point in their career. In this case, those painfully frustrating words are from Ken Norton, partner at Google Ventures, in a blog post titled “How to Hire a Product Manager.” Think about a company for a second. Engineers build the product. Designers make sure it has a great user experience and looks good. Marketing makes sure customers know about the product. Sales gets potential customers to open their wallets to buy the product. What more does a company need? Where does a product manager fit into that mix? Those simple questions are what cause not only the confusion, but also the opportunity that comes with product management. Heck, if you’re transitioning into product management, these questions might make you worry that product managers are irrelevant. And if you are currently a product manager, you might feel a sudden need to justify your existence. Truthfully, without a product manager a company will
  • 10. 10 THE PRODUCT BOOK continue to operate pretty well—to a point. Yet with a strong product manager a company can become great. WHAT DO PRODUCT MANAGERS DO? 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. There’s a lot behind this simple definition, though. Adam Nash, CEO of Wealthfront and former VP of product at LinkedIn, summed up product management by saying, PMs figure out what game a company is playing, and how it keeps score (hint: it’s not always about how much money the company makes). 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. They must know how to work with engineers and designers to get the right product built, keeping it as simple as possible. They must know how to work with marketing to explain to the customer how the product fills the customer’s need better than a competitor’s product. They must do whatever’s needed to help ship the product, finding solutions rather than excuses. Sometimes, this even means a PM getting coffee for a team that’s working long hours to show appreciation. By the way, PMs manage products, not people, so they must achieve everything using soft influence, effective communication, leadership, and trust—not orders.
  • 11. 11 1. What Is Product Management? Even though it’s not always obvious what PMs do from the outside, they genuinely do a lot! PMs do so much that they’re sometimes even called “Mini CEOs.” Ironically, the thing a PM does the most is say “no.” Some people believe that product managers just dictate what features to build. Given everyone has lots of ideas for features, why bother with a PM? It’s true that everyone has lots of ideas, some of them good, but most ideas people have are for things they want, not necessarily things customers want. For example, think of an engineer who spends her days using cryptic command-line tools—I’m sure you know someone like this! This engineer probably prefers keyboard shortcuts, dislikes GUIs, and favors using code to explicitly specify meaning. Now, imagine that engineer is part of a team working on an iPad word processor for senior citizens. Do you think the features the engineer would prioritize match what the customers need? A large part of a PM’s job is to figure out the small number of key features to prioritize for the customer, and to lay the groundwork for long-term business viability by gracefully saying “no” to the numerous requests that don’t fit the customer’s needs. Similar but Different It’s also worth looking at roles that are related to, but different from, product management. These jobs get confused with product management because in some companies a product manager will also handle these roles’ responsibilities, even though they aren’t the product manager’s primary strengths. For example, remember how we said a good PM would do whatever it took to ship the product? Further confusing things, all of these related roles are abbreviated “PM.” Project managers are most often confused with product managers. While there are many subtle differences, they can be summed up by
  • 12. 12 THE PRODUCT BOOK saying that a project manager owns the schedule and helps ensure the team is on track to meet any deadlines. The project manager will often work with the product manager, and a product manager will provide input on the schedule. Project managers are masters of schedules and Gantt charts, not of representing customers. Program managers are usually a bit more similar to product managers, but program managers generally focus more on the “getting it built” side, working closely with Engineering and Operations. If you’re building a wearable, for example, the program manager will likely be in touch with the manufacturing facility frequently, whereas a product manager will have limited direct interaction with them. Program managers tend to be masters of execution, sort of like a “super” project manager. To further confuse things, the title that describes what a product manager does varies slightly from company to company. Microsoft, for example, calls its product managers “Program Managers.” Apple generally splits the product manager role into the “Engineering Program Manager” (EPM), and the “Product Marketing Manager” (PMM), with the PMM being closer to our definition a product manager, and the EPM being closer to a project manager. 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. Project managers help keep all the rehearsals organized so that the orchestrawillbepreparedfortheconcerts.Programmanagersareinvolved in planning the entire season’s schedule for the concert hall, setting things up so that the project managers can make each performance successful.
  • 13. 13 1. What Is Product Management? BECOMING A PM There’s no obvious path to becoming a product manager. And if you’re reviewing rĂŠsumĂŠs for potential PM hires, especially if you’re a start-up founder, it’s not obvious what to look for. Most careers have a very clear- cut path—you go to school, study computer science, and then you’re set to become an engineer. Product management isn’t one of those careers. Because product management is a relatively new discipline, it has a much less formalized training process than other careers. Given that the role often comes down to “doing whatever it takes to ship a product that customers will love and that achieves business goals,” product managers should be smart, talented people who can figure things out on their own. Beyond that, product managers commonly have an intersection of a technical background—not just engineering—such as industry expertise, and communication skills. The most common type of product manager is someone with an engineering/computer science background who became interested in business. PMs often start out as individually contributing engineers who then find themselves taking on more responsibilities: conducting customer interviews, working with Design to validate ideas, and possibly even collaborating with marketing to make sure what they’re working on aligns with customer needs. They’re not necessarily the best coders or the most definitive domain experts, but their mix of skills makes them unique. Sometimes PMs come from Design, Marketing, or even business school! At Product School, we often talk about the Product Triangle (Figure 1-1). This is a simple way to visualize and understand where product management (ideally) sits in relation to other core departments: Engineering (product development), Design, and Marketing. This diagram is helpful for two reasons. First, it visually emphasizes that product management is a generalist role and PMs need to be able to
  • 14. 14 THE PRODUCT BOOK work with significantly different domains. Second, as you go through the process of building a product, you will shift your balance to different parts of the triangle—more on this shortly. Thinking about which leg of the triangle you’re focusing on will let you think about the right way to communicate—you’ll talk with Design differently than you do Engineering—and the right goals to set during each phase. Product Design Product Development Product Marketing Product Management Figure 1-1. The Product Triangle, showing product management at the intersection of three core domains. A common question about becoming a PM is, how technical do PMs have to be? They need to know enough that they can work effectively with engineers, participating in things like bug prioritization and scoping meetings, but they don’t need a computer science or electrical engineer- ing degree. Especially for software PMs, knowing how to code even a little will be beneficial, and if you want to become a PM but don’t know how to code, we’d highly recommend learning the basics. Fortunately, there are plenty of resources to help you learn—you can enroll in a boot camp like Code School or Hack Reactor or take an online course from lynda.com or Udemy.
  • 15. 15 1. What Is Product Management? A big benefit to learning to code is that 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. After building the small pieces, you combine them to get the big picture. Learning to code will give you consistent practice thinking this way. Another common question is, how business-oriented do PMs have to be? PMs don’t need an MBA—in fact, some tech companies prefer not to hire MBAs—nor do they need a sales background. 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 such as revenue vs. profit—revenue is how much money a company takes in, and profit is how much is left after expenses. In general, when we’re working with people who want to make the transition to being a product manager, we recommend they start with an industry/company they’re already very familiar with. That makes for an easier transition because they likely know the answers to many of the questions above, even if they don’t explicitly realize it! After you have a few years of product management experience, it’s fairly easy to switch to a new domain, as you know the right questions to ask to be successful. If you’re a founder looking to build your start-up’s product team, we’d recommend focusing on finding the best product person possible, even if that person isn’t familiar with your domain. Types of Product Managers Whileyouwilloftenhearpeopletalkaboutproductmanagersinthegeneral sense, you will also hear about specialized product managers. Depending on your background, you might find one of these specializations a more appropriate career choice than the general role.
  • 16. 16 THE PRODUCT BOOK The most common specialization is technical product management. This refers to a PM who has a strong technical background, and who works on a technical product. For example, this person might work on a software API where the end customer is a software developer. Technical PMs won’t be writing the code or performing technical tasks, but they need to understand the details of what goes into those tasks. Another specialization is strategic product management. This role is the complement to a technical PM, and it’s someone who has a strong business-oriented background. Once in a while, you’ll also see titles linked to specific verticals or tasks, such as growth product manager or mobile product manager. These roles are more focused than the general PM role, and a person in such a role will have a more specific set of skills, such as being an expert in all the different things you can do to grow a product—that is, get more customers using it. HOW PRODUCT MANAGERS GET PRODUCTS BUILT While sometimes it might seem like the CEO imagines a product in the shower, and then tells the engineering team to build it, any one who has been a CEO knows this is not the case. Product management is similarly misunderstood by the general public. On TV you’re likely to see the guy get out of the shower and start hacking on a laptop with bright green text, occasionally solving a hard problem by drawing on glass. The real world doesn’t work like that. So, how do products get built? What does a product manager really do, and how? In reality, products continuously undergo a product-development life cycle, and a product manager shepherds the product through each phase, owning some phases and contributing to others. The product-
  • 17. 17 1. What Is Product Management? development life cycle involves discrete steps, and each step emphasizes a different leg of the Product Triangle. While the steps are well defined, there are multiple approaches to how these steps can be implemented. On one end of the spectrum there’s the lean approach, based on Toyota’s manufacturing methods and adapted to software/product development by Steve Blank and Eric Ries. 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. On the opposite end of the spectrum you have the waterfall approach, where you build something big in a very linear fashion—you spend a lot of time planning a product, and once you’ve decided what to do, that’s what you’re going to build and ship even if it takes a long time. The product moves through each process step by step and, like a waterfall, things flow one way, and—almost—never change once they’re defined it. Waterfall cycles might take a year or more. For software product development, larger and older companies tend to use a waterfall approach, whereas many start-ups use a lean approach. As you might expect intuitively—and there have been many studies to back this up—building products with a lean approach is more successful because you’re not risking everything on a potentially long, slow-to- create project. Instead, you risk a little bit to build something small, learn from it, and iterate. For that reason, even larger and older companies are shifting towards a lean approach, moving away from waterfall. The most common approach you’ll encounter is a hybrid of water- fall 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
  • 18. 18 THE PRODUCT BOOK customers don’t want the product you’re building. We’ll mainly focus on a hybrid approach in this book. Hardware product development takes a more waterfall approach because it’s harder to change things you’re physically building. For example, hardware requires a lot more planning up front, and the iterative cycles during development to get new hardware builds are a lot longer than with software. However, the overall principles for building products are very similar to those for software, and the process is similar enough that the life cycle stages we’ll teach you about apply for both hardware and software product management. In future chapters we’ll dig into each stage of the product-development life cycle in depth. For now, let’s look at an overview of each stage, starting with the planning phase. THE PRODUCT-DEVELOPMENT LIFE CYCLE 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. Sounds easy, right? Conceptually, it is! The devil’s in the details. To help you see how each stage connects, before we dive deep, let’s look at a high-level overview of each stage.
  • 19. 19 1. What Is Product Management? Finding and Planning the Right Opportunity 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. This phase is a critical part of your job. Unlike the other phases, where other disciplines take the lead, this phase is where product leads, taking input from other disciplines. It’s probably the most different from anything expected in another position. Because this is so core to your job, we’ll cover finding the right opportunity in extreme depth, breaking it down into three parts: strategically understanding a company (Chapter 2), creating an opportunity hypothesis (Chapter 3), and validating that hypothesis (Chapter 4). To a product manager, strategically understanding a company involves learningaboutaspectsofthecompanythatcontributetoitsproductsuccess including its target customers, its expertise, its competitive landscape, and more. Understanding these aspects, which we sometimes refer to as a company’s context, will help you make the right product decisions, and start to find focus in the sea of possibilities. A simple example is CNN. com’s team. They are great at building software products—including a website and mobile apps—that deliver the news quickly and efficiently to their customers. Because their PMs know they have software and not hardware expertise, they are—probably—not encouraging CNN.com to build a news-focused smart watch, or other hardware product. 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
  • 20. 20 THE PRODUCT BOOK 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. 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? With the company’s context in mind, the next step, which we’ll cover in Chapter 3, is to create an opportunity hypothesis. What do you believe is the right thing to work on next? It could be something as small as fixing a bug that’s been in your backlog for a while, or something as large as building an entirely new product. 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. A metric is a measurement of a task a customer does with your product. Collectively, your metrics can provide some great insight! From metrics, you might find an opportunity, such as wanting to get higher engagement with a com- ponent of your product. For example, CNN.com likely keeps track of what headlines visitors click on, how many people start watching each video, how many finish watching each video, how many scroll down and read each article, and more. They might then use this data to pull out conclusions, such as, “We
  • 21. 21 1. What Is Product Management? should prioritize video content instead of text because people tend to watch videos to completion and see each ad, whereas very few people read articles to completion.” After thinking about the company’s context and goals, talking with users, analyzing usage data, looking at existing bug reports and feature requests, and using other approaches we’ll cover in Chapter 3, you’ll have an idea about what to do next. But before you start to build a feature, you should do some type of validation work to ensure this is the right opportunity to pursue, and that it actually will help you achieve your goals. You have limited time and resources, and spending a little bit of time validating an opportunity hypothesis can often save you significant time and money by keeping you focused on the best opportunities. Chapter 4 goes into depth about how to validate an idea. Onceyou’vevalidatedyouridea,you’llneedtodevelopitintosomething your teams can implement. An important part of the product-planning phase in the product-development life cycle is scoping the opportunity. Scoping means clearly defining the opportunity and the customers you want to target, along with the requirements for the solution. If you’re building a pen, do you need it to work in space? Underwater? Upside down? You’ll want to clearly define these situations to help everyone understand what the product will need to do when it’s finished. When working in lean or hybrid environments, you’ll often hear the phrase minimum viable product (MVP). This is a term from lean methodology that simply means, “What’s the most minimally featured thing you can build that will address the opportunity well for most of your target customers and validate your opportunity?” In other words, if you were to think about the core function you’re trying to let customers accomplish, what’s the simplest product you can build that lets them achieve that goal?
  • 22. 22 THE PRODUCT BOOK Continuing our CNN example, if you went back in time and were working on the first version of CNN’s mobile app, what’s the simplest app you could build that would provide value to your customers? It might be somethingwithalistofnewsheadlinesandarefreshbutton,andwhenyou tap on each, you see the video for the story. Again, the key to identifying the MVP is that you’re focused on the core functionality it provides to the user—news, in this case—rather than focusing on all the possible features you might build in addition to that core function. Identifying the MVP is a key part of scoping a product because it helps you identify the most important thing to build first—we’ll cover tips on how to do that in Chapter 5. This lets you focus your design and development efforts to create a—hopefully—useful product that you can deliver to customers quickly, whether as shipped software or software tested in house. Testing the MVP with real customers will help you figure out what other features will be in and out of scope, as you quickly will get real feedback about what customers like and don’t like. Note that 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. Contrast this with non-MVP-based approaches to product development, which are especially common in waterfall development. In that world, you end up spending lots of time trying to build the “perfect” product with every feature you can imagine, it takes forever to build, and once it’s out in the real world you discover that customers don’t use half the features you thought they would. A key differentiator between lean and waterfall is that lean leverages MVPs. With a lean approach, you build the simplest thing you can, gather data about how customers use it, and then refine the product if needed. This will let you work quite effectively, building only the features customers want and will use rather than wasting time building things customers don’t care about.
  • 23. 23 1. What Is Product Management? Spending lots of time iterating internally and building features without releasing a product can be quite harmful to your business. With our hypothetical CNN app example, if we didn’t take an MVP-based approach, we might decide to replicate the website completely, including features like comments, user-submitted video, and customized news streams. Building all those features could delay our launch by months and who knows how much of our customer base would use those features on their phones. Yes, we could use metrics from the website to prioritize these features, but hopefully you get the point. Additionally, while we were taking lots of time and building features for our unre- leased app, our customers wanted a mobile news app and turned to Fox News or another competitor that built its app using an MVP-based approach. The customers cared about the core function—getting news on the go—not about all the extra features. And it’s hard to get customers back after they’ve turned to a competitor! 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. To be fair, hardware development often requires you to try to build more than an MVP because releasing a hardware update is much more complex than a software update. But keeping the MVP in mind, even with hardware, will help you prioritize your development efforts. Sometimes, as we’ll discuss in Chapter 4, your very first MVP will be human-powered rather than automated. For example, if you’re a PM at Yelp and want to add a restaurant-recommendation feature, eventually you’ll create a fully automated algorithm to generate recommendations. But you could build an initial MVP that makes it appear that the user is getting automated recommendations when it actually has a human making and
  • 24. 24 THE PRODUCT BOOK sendingtheselists.Ifmanypeoplelikeandusethis feature, thengreat, you’ll build the automation engine. If no one uses it, then this very lightweight MVP saved you the time and effort of building the full feature. 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? Going back to CNN.com, its ultimate goal might be to become the place people go to for news. This means its success metrics include the number of views on a piece of content, the percentage of people who consume each piece of content, the number of articles read or videos watched in a session, and how often the person comes back to CNN.com. The reason we don’t solely use page views on a piece of content is because a person might click on an article but never read it. That means that person is not actually getting news/consuming content from CNN.com. 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 ex- planation 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. One of the biggest reasons that other stakeholders, such as design and engineering leads, are involved in the PRD is that it will be up to them—not the product manager—to figure out the right solution for this opportunity. After all, the design and engineering teams are the experts in their domains, and the product manager is not, even if she started her career in one of those domains! PRDs gained a bad reputation from waterfall development because they were huge dictating documents that people disliked reading. In
  • 25. 25 1. What Is Product Management? fact, 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. We’ll go over how to effectively write and use a PRD in Chapter 5. Once we have this first draft of a PRD—clearly identifying the opportunity/problem and success metrics—and all stakeholders have agreed on the right problem to focus on next, we’ll move on to the next phase of the product-development life cycle. Designing the Solution During this phase, covered in depth in Chapter 6, we’ll figure out a feasible solution to the problem we’ve identified. Here, PMs will primarily work with the design team, but the engineering team will offer input as well, to help gauge feasibility. For example, a CNN.com PM might have found that her readers com- plete a lot more articles when a virtual reality 360° video is included, meaning better success metrics, and the PM wants to integrate 360° videos into more content. The design team might then create designs where every breaking news story has a live-streaming 360° video to put viewers right there with the reporter, but the engineering team might not be able to build a live-streaming solution. This means the design team needs to come up with another solution that the engineering team can implement. Even though the PM won’t be coming up with the solution herself, she’ll stay actively involved in this phase. She’ll likely work closely with design to conduct user research, looking at people’s current behavior.
  • 26. 26 THE PRODUCT BOOK She’ll also help communicate with Engineering to ensure Design isn’t working in isolation—that everyone is working together to solve the customer’s problems. 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?). It’s uncommon to find a designer who’s an expert on every one of these aspects, and a PM will likely be working with a design team rather than with just one designer to figure out how the product should function and look. If possible, you’ll want the design team to produce prototypes of the solutions that they can test with customers to validate the design. These prototypes could be printouts that you swap in when the customer clicks on something, clickable mockups working with fake data, etc. The key is to have something that accurately represents the solution, but that you can mock up without having to actually build the solution. Design is done when you have validated a prototype as a suitable solution, Engineering has agreed to the viability of the solution, and you’ve defined the look and feel of the solution that all stakeholders have agreed to. Building the Solution Once you’ve defined the problem and designed a solution, it’s time to build it. Companies have different approaches to implementing solutions, depending on their history, the product, and their desires. For example, if you’re working on a mobile app, it’s very easy to release a new version to customers every week, and development is likely focused on smaller but more frequent releases—lean development is very common with mobile and web apps. If you’re building hardware, there is a long time
  • 27. 27 1. What Is Product Management? between the product’s design and when its hardware is ready for mass production. Hardware-engineering companies generally have fewer but very high-quality releases. After all, it’s difficult to release a hardware update to fix a bug! In Chapter 7, we’ll cover some of the most common software- development methodologies, along with tips for working with engineers. 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. A note of caution if you’re currently an engineer who wants to transition to product management—development might turn out to be the most frustrating phase to you because you are not an engineer anymore. You will not be writing code for the product, or telling people what code to write. Your job is to stand aside, and let the people who are still engineers write the code. You help them however else you can, even if it’s getting them coffee, but don’t tell them what to do unless they ask for your help. Furthermore, as a PM, you’ll be put into positions where you have to negotiate taking on technical debt, meaning you need to ask Engineering to write kludgey code that isn’t sustainable in the long term to get something done in the short term. Engineers hate taking on technical debt—they want to write a com- plete answer from the outset. If you come from an engineering back- ground, 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. Also, although we’re presenting the product-development life cycle in averylinearfashion,it’salotmoreiterativeinreallife,especial- lybetween
  • 28. 28 THE PRODUCT BOOK designing and building the solution. For example, 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. During the development phase a PM should try to find effective opportunities to share prototypes of the product with customers or people inside the company, so that you can get early feedback about the product. Does it address the customer’s need effectively, or is there a big tradeoff you didn’t anticipate? If you prioritize building the minimum viable product you previously identified, then you can start testing the core product once the MVP’s ready. It’s important to ask for this feedback at the right times—if you wait until right before you release to get feedback, you might not have time to act on what you learn. New information that affects the product’s scope might come up during development, too. Going back to our example of 360° live-stream- ing on CNN.com, maybe a third-party company released a tool that makes it very easy to live-stream these videos. That’d make it simple for CNN.com’s engineers to add on-the-scene 360° video to breaking news stories, which was originally deemed out of scope because of the technical challenge. In the product-development approach we’re presenting in this book, it’s always best to do more investigation up front, so that you don’t waste resources designing a solution and then have to change large parts of it. But the best product managers are ones who know they can’t define everything perfectly up front, and that it’s generally impractical to spend months trying to do so. Instead they do their best to plan, but also seek out new information to help the product get better, and react to any needed changes with open arms. The development phase of the product-development life cycle is done whenaworkingproductthathasbeenthoroughlytestedisreadyforrelease.
  • 29. 29 1. What Is Product Management? Sharing the Solution As much as we’d like to believe that if we build it, they will come, the world doesn’t work that way. Product marketing (Chapter 8)—in fact, marketing in general—is an incredibly important part of the product-development life cycle, and really begins after we’ve built the solution. This phase of the life cycle is where we launch our product, sharing it with the world and letting our customers know how our product will help them. Effectively telling the world about our product is so important that some companies even create a separate position, the product marketing manager. A PMM is very similar to a PM, but a PM tends to be more internally focused—getting the product built—while a PMM is externally focused—working with customers to understand their needs and to communicate the product’s value. Early in the first stage of the product-development life cycle, even before scoping the opportunity, it should be clear what this product will do for the customer. This isn’t a list of what features it has or what the product does, but rather what problem it will solve. In the product marketingphaseoftheproduct-developmentlifecycle,youfigureouthow 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.” For example, going back to CNN.com’s 360° VR video streaming feature, if we promoted the feature itself, “Live 360° VR video streaming,” most customers wouldn’t know what that meant—or care. Instead of talking about the specific feature, we can focus on the value and the benefit this feature provides: “Be on the scene with our reporters.” We might then go on to say what the feature is and how to use it, but we’ve led with a clear message about why a customer should care.
  • 30. 30 THE PRODUCT BOOK This phase of the product-development life cycle is more than just mes- saging, though. We’ll also plan for the product’s release. Release might involve planning a beta test, creating marketing assets for a website or ad, working with key partners before release, briefing the press, or planning a launch event. The exact needs will vary from launch to launch. Broadly, this phase of the product-development life cycle is done when the product is launched, but there will likely be many marketing campaigns and tasks to help achieve the product’s success metrics beyond the launch. Marketing will continue even while the team, in- ternally, has moved on to the next version of the product, or to a completely different product. Assessing the Solution The last phase of the product-development life cycle is to assess how the just-completed iteration of the cycle went, see if you’re on track to achieve your success metrics, and come up with a recommendation for what to do in the next iteration. As you might guess, that recommenda- tion feeds into the initial planning phase of the next iteration. During this phase, you will meet with the team that you built the product with and assess how it went. Did everyone get so burned out that half the team quit? Was the team very happy with the process and excited to work on the next project? What was the team’s overall competitive strength, and what could they improve at? Use this feedback to determine what went well, and what you should do differently the next time around. Now that the product’s released, you should start seeing real data about how people are using it. Is it in line with your expectations, or is something far off? And most importantly, does it look like you’re on track to achieve your success metrics? For example, CNN.com could look at how many people are watching its new 360° broadcasts and whether the overall number of people getting their content from CNN has increased after the release of this new feature. If the number of peo- ple watching
  • 31. 31 1. What Is Product Management? these broadcasts and seeking out more content on CNN improved, then your product was a success. If it’s unchanged, then you should evaluate why this strategy didn’t work how you expected—why don’t customers like it? Once you’ve had a chance to see how your new product was received by your customers, you’ll put together a recommendation for what’s next: should you iterate more on this feature/product, move on to something else, or end-of-life this feature/product? This recommendation will help inform the next iteration through the product-development life cycle, and we’ll explain how to create a good recommendation in Chapter 9. As you can see, there’s a lot to product management and the product- development life cycle! But don’t worry, the following chapters will break each step down into more detail and help you understand how to be a great product manager who makes awesome products that customers love.
  • 32. 32 STRATEGICALLY UNDERSTANDING A COMPANY CHAPTER TWO One of the first things a great product manager should do before even thinking about a product is to understand the company that makes it. Every company is a little bit different, and they have different priorities, values, strengths, and weaknesses. Knowing these details about a company—understanding the full context of its current situation—is the starting point to find and evaluate product opportunities and make strategic product decisions. We’ll build upon how to leverage these details in the following chapters. 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? WHAT PRODUCT ARE WE BUILDING? This category of analysis is focused on the company’s current product. This might be an existing product that you’re tasked with improving, or it might be the next new product that you want to build.
  • 33. 33 2. Strategically Understanding a Company Why Does the Company Exist? The most fundamental thing to understand about a company is why it exists.What’sitsmissionstatementor,evenmoreimportantly,itscorebelief: the value it adds to the world that differentiates it from other companies? Simon Sinek has a great TED talk called “How Great Leaders Inspire Action” and a book on the same topic, Start With Why. In both, he advocates for what he calls the Golden Circle (Figure 2-1). Specifically, he says that the “why” of a company is what people actually care about and buy into. How you deliver that value and the products you create will build on top of this core value. From a product point of view that “why” is your guiding light—it will help you figure out what fits with the company’s reason to exist and what doesn’t. 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? Themes in movies are often obvious: love conquers all, revenge doesn’t lead to happiness, etc. A company’s theme can be a little harder to decipher. Often its theme is expressed as a value within the company’s mission statement, which you can usually find on the website. But even if a company has a clear mission statement with a clear theme, it may forget about it when making decisions, leading to mixed results. Let’s look at Sinek’s example of Apple. If Apple started with the “what,” which many companies do, Sinek asserts its messaging would read, “We make great computers. They’re user-friendly, beautifully designed, and easy to use. Want to buy one?” That’s fine, but it sounds pretty generic. Many other PC manufacturers even make the same claim!
  • 34. 34 THE PRODUCT BOOK WHY HOW WHAT Figure 2-1. Simon Sinek’s Golden Circle, starting with “why” as the most important as- pect of a company. Instead, recall the Think Different campaign Apple ran in the late ’90s, which talked about Apple’s “why” without even mentioning the products: “Here’s to the crazy ones.” Starting from that mission state- ment, Sinek says a more realistic marketing message from Apple would be, “With everything we do, we aim to challenge the status quo. We aim to think differently. Our products are user-friendly, beautifully designed, and easy to use. We just happen to make great computers. Want to buy one?” That version starts with the “why” (challenging the status quo), then moves into the “how” (being user-friendly, etc.), and finally the “what” (selling great computers). It’s way more compelling than the first version, and it also says a lot more about what Apple represents, and who they are as a company. “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
  • 35. 35 2. Strategically Understanding a Company makes for those products, should emerge from that value. If it doesn’t, there’s a good chance that decision isn’t working well for the company. 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. It’s unlikely to make a toaster oven, even a Wi-Fi-connected one, because that doesn’t organize the world’s information, make it accessible, or drive us forward. However, Google did purchase Nest, which made appliance-like devices, including a thermostat and a smoke detector. Nest’s products involve organizing information about your home and applying computer science to that information to make your home function better. The Nest Thermostat learns you behavior and automatically adapts how it heats and cools your house to save energy—thereby saving you money—while still keeping you comfortable. It’s worth noting that every company whose fundamental mission is “to make money” rather than focusing on what value it can add to customers’ lives has failed. Sinek discusses this in detail in his talk. If your company functions well and customers want the products you’re making, you’ll make money. Revenue is be validation that a company is doing the right thing for its customers—revenue should not be a company’s reason for existing. This isn’t true for only socially conscious companies like TOMS, the shoe company, but for all com- panies. Customers will pay for your product because it makes their lives better, not because they want to give you money. Similarly, companies that start without a mission, but rather with some invention that they’re trying to find a use for, often fail. Specifically, if your company started because someone said, “This is a cool idea—can we sell it?” rather than “This invention would make people’s lives better because…,” you have a solution looking for a prob- lem. An engineering
  • 36. 36 THE PRODUCT BOOK innovation by itself doesn’t make a product— products are solutions to problems people encounter. You’ll often hear startups talk about “pivoting” because they found customers didn’t want the product they made, and the startup is trying to repurpose what it built to something customers will use. Some companies are moderately successful without having a clear mission statement. But they struggle to grow because it’s be unclear to their leadership why their product was successful and how to expand the product line. The result is a product portfolio that feels very disconnected. Misfit, which was purchased by Fossil, achieved suc- cess with its Shine wearable activity tracker, but it didn’t have a clear mission. Its follow-up products included a smart light bulb and sleep sensor, and they failed to gain much attention. Misfit appears to be aware of this problem and has tried to fix it, though, as it’s now focused on making wearables a natural part of your life, with fashion-conscious activity trackers, and smart headphones with a built-in activity tracker. The implicit value proposition is that Misfit wants you to live a better life, and it achieves that by enabling you to analyze your life, especially your health. 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.” 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.
  • 37. 37 2. Strategically Understanding a Company Let’s imagine we’re building a camera accessory that plugs into the iPhone, like the DxO ONE. Your customers are likely people who enjoy shooting with their smartphones, but want better image quality than the built-in camera provides. Since we’re iPhone-specific, we won’t care about people with Android phones. And, since we’re building an accessory that people need to pay extra for, we will ignore people who are happy with the built-in camera. But even amongst all the customers we do care about, there’s a lot of variability. Maybe one loves taking photos of his dogs while another takes photos of her ferrets. Dealing with lots of real people and their variability can make for complex discussions—our camera accessory has to work with cats, dogs, ferrets, rabbits, etc. Instead, it would be easier if we just abstracted things and said, “Our customers take photos of their pets.” We can take the various common traits we care about in our potential customers and abstract them out into a persona. A 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. A great way to think about the difference is that Facebook and Snapchat have many of the same customers, but their internal personas—how they segment those customers and what aspects of the product they care about—are different. You’ve likely already talked about a persona without realizing it. When someone asks, “Can my mom use it?” they don’t mean their actual mom, she might be a rocket scientist. Instead, they mean the “mom” persona of a middle-aged person who is never the first to buy new technology, and will break many gadgets simply by turning them on. When we say, “Can my mom use it?” we’re actually asking if the product is user-friendly enough that someone in the “mom” persona can use the product to achieve a goal without breaking it and without asking for help.
  • 38. 38 THE PRODUCT BOOK 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—you want enough detail that you can imagine yourself in the persona’s shoes. Roman Pichler put this into a template you can fill out to start crafting your own personas (Figure 2-2). ROMAN’S PERSONA TEMPLATE PICTURE AND NAME DETAILS GOAL What does the persona look like? What is its name? Choose a picture and a name that are appropriate and that help you develop sympathy for the persona. What are the persona’s relevant characteristics and behaviours? For instance, demographics such as age, gender, occupation, and income; psychographics including lifestyle, social class, and personality; behavioural attributes like usage patterns, attitudes, and brand loyalty. Only list relevant details. Why would the persona want to use or buy the product? What benet does the persona want to achieve? Which problem does the persona want to solve? Figure 2-2. Roman Pichler’s persona-building template, available at www.romanpichler.com and included under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license, https://creativecommons.org/licenses/by-sa/3.0. While it’s tempting to make your personas very detailed, describing every aspect of the person’s life, they can quickly become overwhelmed with lots of irrelevant details. 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.
  • 39. 39 2. Strategically Understanding a Company The key things you’re looking for are this person’s priorities, related to your product/area of expertise. What is the persona “IT Tech Tom” trying to do that’s significant and what’s actually insignificant: 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? For example, IT Tech Tom might be very busy his entire workday with customer support tickets. He would likely favor a new automated machine deployment system over one that involves lots of manual intervention. 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. Don’t forget about the social or emotional side. Dental headgear can solve orthodontic problems—a significant pain point—but do you want to be the kid on the playground who has to wear headgear for two years? Other factors, like which distribution channels reach the various personas, and whether they’re willing to pay for different parts of the product, can help differentiate personas. Personas contain demographic information only if it’s relevant. For example, Airbnb’s “host” personas probably don’t include how much each personmakesperyear,buttheylikelydoincludewhyapersonaisinterested in renting her place out. A young urban host might be renting a couch or second bedroom to help pay for his condo. In fact, he might have to do so, meaning he cares most about maximizing how much he gets for his space vs. having someone there all the time. A retired couple who are snowbirds, flying from Pennsylvania to Florida each winter, might want to rent out their vacation home when they’re not using it, to supplement their income. They’ll likely prefer Airbnb guests who stay for longer periods of time, and treat the home like their own, even if it means their vacation home is empty periodically. This might be counter to what you know about typical
  • 40. 40 THE PRODUCT BOOK marketing theory, where demographics are key. Again and again, product theory and practice have shown that focusing on a common problem, pain, or desire yields better segmentation than demographics. Harvard Business School professor Clayton Christensen has been working on a customer-segmentation approach he calls “jobs to be done” foroveradecade.Thinkingthiswayhelpsbuildgreatpersonas.Theexample Christensen gives is that when a fast-food company tried to improve its milkshake sales, it first did traditional demo- graphic segmentation and asked each persona (e.g., the 18–35-year- old milkshake drinker) about her ideal shake and implemented changes. Sales were stagnant. But when the fast-food company focused on who bought milkshakes, when they bought them, and where they drank them, it found a different way to segment its customers. One segment bought milkshakes in the morning to keep them feeling full until lunch. As an added benefit, the morning milkshake gave them something to occupy their free hand while driving during a boring commute. That group wants a milkshake 36 that takes a while to drink so that it lets them feel full longer and lasts for the commute. Now consider another segment: customers buying milkshakes as a special treat for young children. Kids likely just want a tasty treat and don’t have the patience to drink a milkshake for 30 minutes. Using pains and goals instead of just demographics will help you segment your customers into useful personas. It’s possible your product has multiple personas. For example, the people who read and write reviews on Yelp are customers, but the businesses these people review are also Yelp’s customers. Create multiple personas if needed, and identify the primary one you want to satisfy. 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. This is common with enterprise
  • 41. 41 2. Strategically Understanding a Company software, and you’ll need to create separate personas for these cases. Ultimately your goal with each persona is to have enough information and detail about that category of customer that you can imagine yourself in this person’s shoes. This will help you empathize with that customer, understand his pain points, and think about ways your product can solve that pain (we’ll go into this in depth in Chapter 3). Because personas help you understand what a group of customers is like, a key piece of a persona is to be authentic—if you find your persona is incredibly busy, working 80+ hours/week, how much time do you think he’ll have to learn how to use your product? If you fail to note how much your persona works, you could make the wrong product decisions, errantly assuming this persona has time to watch a long onboarding video tutorial. 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. Many companies use Word or Google Docs files with their persona data, and there are specialized tools that explicitly manage your personas and organize the research that goes into each one (As of the time of writing, the landscape of persona tools is so in flux that we’ve elected to leave it up to you to search and find what’s current). If there’s nothing written down, it’s still likely the company has a rough idea of who its customers are. Use that knowledge to write down a first draft of the persona, you will revise it over time. It’s not mandatory to have pre-existing customer knowledge to build a persona. Just make your personas rough at first, and as you learn more about your customers, refine the personas, perhaps dividing them up and creating a new persona when key differences appear. You might even find as you talk with customers and show them prototypes of your product/ feature that someone you thought was a certain per- sona really isn’t.
  • 42. 42 THE PRODUCT BOOK Take Airbnb, for example. Even though business travelers travel frequently, they might not be the best persona for Airbnb to focus on because they expense their hotel rooms, meaning they’re not price sensitive, they care more about service than connecting with the host, and they often have rewards cards that let them accumulate free stays for personal travel. Airbnb focuses on making interactions with your host and other locals part of your travel experience. Business travelers, however, are there to work, not to feel like a local. All of that means they’re currently better served by regular hotels, and Airbnb might choose not to spend lots of time targeting that persona right now. You’ll also want to ensure your personas align with what your product does. If you’re building payroll software for a small to medium-size business, your personas should be based on coffee shops and doctor’s offices, not a stay-at-home dad. Stay-at-home dads won’t have any reason to buy your software, and you want to spend your time making decisions based on the customers who will buy and use your software. Note that “everyone” is not a persona, as “everyone” is too vague to help you make decisions. Many people think that big companies like Google, Facebook, and Apple target “everyone,” but they don’t and are quite forward about it. Facebook started off targeted at one per- sona, college students. Over time Facebook grew, adding high-school students and beyond, and its current customer base is very diverse. Facebook likely has many internal personas, but when it releases new features, they’re still targeted at specific personas. A “Henrietta High- School Student” persona doesn’t care about the reviews feature on busi- ness pages, but a business that created a Facebook page certainly does! Another great attribute to consider about your personas is where on the adoption curve they fall. Not everyone buys/starts using something new at the same time. There’s a general theory of adoption—which can refer to a new product or a new feature—that says there’s a tiny group of early adopters that have to be
  • 43. 43 2. Strategically Understanding a Company the first to have new things— think of the first person you know to own a smartwatch. Then, there’s a slightly larger group of people who like being one of the first—but not necessarily the first—to have something new— think of the first person you know who bought an Apple Watch but didn’t own a pre- vious smartwatch. Unfortunately, there’s a gap (see Figure 2-3) before you get to the next group of people. If your product’s awesome and delivers on a value proposition your customers care about, you’ll continue on to the next step, mass-market adoption, when the bulk of potential cus- tomers buy/ use your product. Eventually, even the late adopters—the people who always seem to be years behind everyone else technology-wise—will start using your product. Considering where your various personas fit into this curve will help you understand when they’re likely to adopt your new product or feature. This will help prioritize features. Early adopters will tolerate missing features that laggards might require, for example. Market Share A D O P T I O N G A P Time of adoption Investors Early Adopters Early Majority Late Majority Leggards Figure 2-3. La curva de adopciĂłn donde el eje X representa los grupos de clientes que potencialmente comprarĂĄn tu producto con el tiempo. El eje Y representa la cuota de mercado aproximada de cada grupo.
  • 44. 44 THE PRODUCT BOOK But if your product isn’t awesome, when you hit the chasm before mass-market adoption, your growth will stop because your product doesn’t provide enough value to most people’s lives. The mass market won’t adopt it. 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. This gives you a great immediate filter to make sure you’re making strategic decisions about what to do next.
  • 45. 45 2. Strategically Understanding a Company CHAPTER TWO TIP Throughout this book, to give you an additional perspective, we’ve asked experienced product managers to share their best advice about each chap- ter’s topic. Our first tip comes from Jeremy Toeman, vice president of products at CNET. Jeremy runs CNET’s audience development, engagement, and social media teams, and he’s responsible for building CNET’s multichan- nel products, including web, mobile, and apps. Jeremy has more than 20 years of experience, including being VP of product management at Sling Media; working on Dropcam, Sonos, and Sphero; and founding multiple companies that had successful exits. In other words, he knows what he’s talking about! Here’s what he has to say about personas. MAKING PERSONAS REAL WITH EMPATHY 41 With ~20 years under my belt, I’ve noticed the consistent trend is for product managers to define personas with 90% demographics, and 10% wants/needs/emotions. Maybe less. For example, it’s easy to create Jill—a 23-year-old in a major metro who has a roommate, loves travel, and is very into the DJ scene. Jill is thinking about buying her first car. That’s a great starting point. But it’s barely the tip of the iceberg. Does Jill care about what the car says about her, or does she care about fuel efficiency? Is Jill focused on saving money, or on resale value? Does Jill care about the car tech, or just that it gets her places? Further, does Jill enjoy the research process, or does she just want to be pointed in the right direction? Is she going to make a little comparison spread-sheet for herself, or just wing it? Far too often products are coming to market without considering the needs of the individual, as opposed to pure
  • 46. 46 THE PRODUCT BOOK demographic fit. All of the above scenarios are valid to a product manager who is designing a site/ app to cater to car buyers. But a simple review of car-buying websites shows a distinct lack of consideration for emotional needs versus purely practical ones. When the TV industry tried to bring 3D technology into the house, they showed a distinct lack of empathy. Sure, 3D movies were performing well in theaters, so it made logical sense to bring that kind of tech into the home. But an empathic product manager could have easily pre- dicted the poor reception: movie theaters are primarily solitary (though shared) experiences, whereas family/living rooms are primarily social experiences. And no family wants to sit on the couch wearing a bunch of goofy glasses (not a problem in a darkened theater). 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.
  • 47. 47 2. Strategically Understanding a Company Use Cases 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. Day to day, a PM will need to think about what use cases they want to support for their product, which helps in finding and prioritizing opportunities. The use cases will affect everything from what features you prioritize to solve your customers’ problems to what customers you’ll market your product to. 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. Conversely, the iPhone isn’t designed to help you press cloves of garlic, although you could theoretically use it to do so—we’d recommend buying a garlic press instead. Apple cares about the former, not the latter. The choices it makes will be focused on improving email on the go, even if it means a future iPhone is no good for cooking with garlic. That example is pretty drastic and obvious, so let’s look at a more subtle example companies often face. One major category of company is called enterprise or B2B (business to business), which applies to companies that create tools to address other companies’ work-related needs. B2B companies will frequently pick a size of customer company to focus on—small, medium, or large—and then further focus on select industry verticals. Gusto, formerly ZenPayroll, is an HR-solutions company for small businesses. It realized that small businesses have a wide range of fairly complex “run the business” (RTB) needs such as HR, accounting, and office-administration. One person usually can’t do all of those tasks, small businesses don’t have the resources to hire many people to do those tasks, and existing tools like ADP are overkill for small businesses.
  • 48. 48 THE PRODUCT BOOK Gusto’s initial persona was likely a small-business owner—we’ll call her “Suzanne Small Business Owner.” The Gusto website lists instances of this persona, including in her repertoire tech startups, coffee shops, auto shops, creative agencies, law firms, and restaurants. Those are the customers Gusto targets. Let’s pretend Suzanne owns a coffee shop. Put yourself in her shoes for a second—what are the RTB tasks she has to deal with? The simplest ones are around payroll: she wants a way to collect W2-related infor- mation (US-government-required work forms) for her employees, she wants an easy way to pay employees, and she wants an automated way to provide them with tax information. These situations she wants to address— problems she wants to solve—are use cases she might want to use Gusto for, and Gusto will likely build features to solve these problems. At the top of Gusto’s website is a Payroll link. When you click on it you’ll see that Gusto specifically states how it has employee self-on- boarding for W2s and more, payroll solutions, and automated taxes. It has built features into its product to enable it to work in these use cases that its target persona, Suzanne Small Business Owner, has. Gusto initially focused on one use main use case: payroll management. But over time it has expanded to cover more use cases, such as health insurance. Over time, Gusto will likely continue to help small businesses simplify their RTB tasks. They’ll be addressing more use cases that Suzanne Small Business Owner deals with. However, if a large business tried to use Gusto, the business would find features it needed lacking because its requirements are more complex than those of the small businesses that Gusto targets. Gusto doesn’t handle all the use cases for a large business, but a more complex product like ADP does handle those use cases.
  • 49. 49 2. Strategically Understanding a Company Down the road, Gusto could choose to expand to support another customer, a large business. To address that customer, Gusto would create personas to represent the different types of large-business customers, like “Multinational Matt.” Gusto would then add features to the product to address the use cases large business have but small businesses don’t, like dealing with multiple international offices. This would be one way to grow and to gain more customers. However, supporting large businesses and their use cases isn’t currently a priority for Gusto, so it hasn’t built features to address these needs. 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. Adding features to support new use cases or making it easier to achieve current use cases is a common source of product opportunities. Enterprise vs. Consumer Companies Related to use cases and personas is knowing if the company is developing enterprise (B2B) or consumer (also called business-to-consumer or B2C) products. This simply means asking whether end customers are using the product in their personal lives, or at work. You likely don’t need payroll software at home, and you likely don’t need a smart- phone-connected sous vide device at work. The primary difference in how these companies function is that B2B involves more decision makers, and the people who decide to buy the product are often not the ones using it—e.g., a CTO will approve buying software for HR, but it’s HR who uses it day to day. B2B companies often have larger sales forces with specialized roles such as sales engineers who help integrate the product into the customer’s environment, and customer-training roles. You’re unlikely to just start using SalesForce out of the box, for example, nor are you expected to.
  • 50. 50 THE PRODUCT BOOK 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. The tools and techniques you’ll learn in this book will apply to both styles of companies. You’ll build personas and break down use cases regardless of whether you’re building B2B or B2C products. Just be aware that you’ll have to do extra legwork to account for the additional decision makers and their personas in a B2B company. B2B software is also more likely to be subject to legal compliance requirements and to need to function in a multi-user environment, which creates additional fundamental product requirements that B2C software doesn’t have. HOW DO WE KNOW IF OUR PRODUCT’S GOOD? In Chapter 1, we mentioned that a big part of product management is knowing how we keep score. Metrics, in particular success metrics, are how we measure that score. Metricsarethemeasurementofdifferentaspectsofyourproduct.These might include things within your product, like how many people complete a task, or things affected by your product, like how much revenue you’re making. Success metrics, sometimes called key performance indicators (KPIs), are the key metrics that define how we keep score, like how many goals you scored in a soccer game. Success metrics are useful because they help us validate if our current strategy is working, and if it’s not we can dig into the overall metrics to come up with a hypothesis for how we could make changes to achieve our success metrics (more on this in Chapter 3). While product management
  • 51. 51 2. Strategically Understanding a Company 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” we talked about earlier. If part of your company’s mission is that you want your customers to love your products, then a key ongoing, long-term strategy company success metric will be how satisfied your customers are with each product. You will have additional success metrics that change over time based on your short-term goals. For example, it’s common to see companies switchingtheirshort-termgoalfromgrowth(peopleareusingourproduct) to revenue (people like our product enough to pay for it). When goals change, what was a success metric one week might just be considered a regular metric the next week. Generally, you’ll have separate company and product success metrics, and the product success metrics will support the company metrics. Maybe your current company success metric is brand awareness, a common initial success metric for startups. In that case, your product success metrics will include number of downloads of your app, visits to your website, and so on: metrics that indicate people are aware of your company and products. 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: Of those who downloaded the app, how many complete a core task? How many customers do that task each day/week/month? As your strategy and success metrics change, your product plan and the features you choose to work on will similarly shift—you want to make sure what you’re working on supports your goals and success metrics.
  • 52. 52 THE PRODUCT BOOK It’s critical to compare these metrics over time, allowing you to see if your strategy is working. You might be using revenue as a success metric—getting people to open their wallets is a sign they value your product—and perhaps you have $1 million in revenue right now. That seems great until you realize you had $10 million in revenue last month. 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. 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, and we could say that completing the core action is a success metric that supports an engagement goal. Pinterest’s core action is pinning something. In 2011, when Pinterest was growing well, over 50% of its weekly users were still pinning things. Compare this to Viddy, a video-sharing startup that became popular in 2012. When Facebook started featuring Viddy content on April 24, Viddy’s growth skyrocketed to about 35 million users, as you see in Figure 2-4. But the daily active users and the people actually posting content was much lower, peaking around 5 million users, or around 14% of all users. Even though Viddy appeared to be doing well, with lots of people signing up, very few completed that core action. Viddy shut down in late 2014.
  • 53. 53 2. Strategically Understanding a Company Figure 2-4. A graph of Viddy’s monthly active users (top line) vs. daily active users (bottom line) for April/May 2012, from KPCB/Mary Meeker’s Internet Trends report. Now let’s look at the second of Tavel’s three phases, retention. 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. The idea is that if the product gets better for users over time, they will keep using it and they’ll miss out if they leave. In fact, it’s better to have slightly slower growth but a higher percentage of customers continuously using the product than constant growth but low retention because you’ll end up with more customers over time. A simple example of this is frequent-flier points on airlines: The more you fly, the more status you achieve and the more pleasant flying becomes. In software, think about social networks. The bigger the audience you’ve
  • 54. 54 THE PRODUCT BOOK built up on Twitter, the more you’d have to lose by stopping using Twitter and trying to rebuild your audience on another network. Products that don’tencouragecustomerstocontinuouslyusethemareeasilyreplaceable. Lyft and Uber are the same for an end customer whether you’ve ridden once or a hundred times. You likely just request a ride from whichever service has the shortest wait time. And if a new competitor comes around that offers an incentive, such as ride 10 times and get $10 in credit, you lose nothing by deleting the Uber app and using the competitor instead. The final phase that Tavel describes is when your goal is self- perpetuation. This means your product has various loops that keep the customer engaged, and encourage other customers to get engaged. Your success metrics will be around how often people complete these loops. Pinterest gets better when more people post pins because this leads to better discovery of new, relevant things to pin. And sharing notifications (which we’ll look at more in Chapter 3 with the Hook Canvas) encourage both new customers to pin something and existing users to return to the product. Tavel goes on to describe cohort performance as the ultimate success metric your company should look at over time, encompassing all three of these stages. Specifically, look at the number of weekly users completing the core action and the percentage of weekly active users completing the core action over time. This shows growth from the size of the cohort, engagement from the ratio of users completing the core action, and retention from your performance over time. While these stages don’t apply directly to some products, like a B2B product a company mandates its employees use, the principles are still applicable. You want your customers to be able to complete the core tasks in your product smoothly and repeatedly, and as long as those core tasks align with use cases your customers care about, your product is off to a good start.
  • 55. 55 2. Strategically Understanding a Company Vanity vs. Actionable Metrics As product managers, we see a lot of metrics. Some are more helpful to us than others, and we often talk about two categories of metrics: vanity and actionable. 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. Instead, product managers need to focus on actionable metrics that let us make decisions. Now that we know only 10 people completed our product’s core task, we can look at other metrics to try and figure out why so few people were engaged with the app. How to Measure Metrics The most common way you’ll measure metrics is by adding bits of code into your product to measure customer behavior, and to automatically collect the individual measurements into an analytics tool, like Google Analytics. Usually these measurements are very simple: How many people up- loaded a file? How many people clicked this button? How much time did a person spend looking at a web page or a screen in an app? Early on
  • 56. 56 THE PRODUCT BOOK 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 (Chapter 5). For legal reasons, customers often have to opt in to providing this analytics data, which is why you frequently see disclosures in usage term sheets or pop-ups in software alerting customers that you’re collecting usage data for a product. However, not every metric gets captured automatically. It’s tough to know from an automated tool whether customers like your product or swear at it multiple times a day when they use it. If your long-term goal is for customers to love your product, what should you do? Companies frequently use surveys and interviews to sample groups of customers and gauge these higher-level metrics. Sometimes these surveys are automated, such as a pop-up asking how you like the app on a scale from 1 to 10. 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. The idea is that if customers love your product, they’ll tell others about it. If they’re ambivalent, they could switch to a competitor. And if they dislike it, they might tell others to stay away and cost you business. 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.”
  • 57. 57 2. Strategically Understanding a Company From those replies, the NPS is the percentage of promoters minus the percentage of detractors, giving you a score from –100 to 100. Reichheld, in his 2003 article about NPS, entitled “The One Number You Need to Grow,” found that many companies’ NPS were low, with a median being 16 across 400 companies, showing that a lot of companies have work to do to improve customer satisfaction! 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. We’ll dig into how to figure out what changes to make to improve customer satisfaction in Chapters 3 and 4. Whew—for such a simple concept, there’s sure a lot to success metrics. But they are incredibly important to product managers, as they let us figure out if our product and the strategy we’re taking are meeting our short-and long-term goals. WHAT ELSE HAS BEEN, IS BEING, AND WILL BE BUILT? Unfortunately, you can’t look at a product or a company in complete isolation around this moment in time. What the company did in the past likely has an impact on where it is now. Microsoft completely missed the start of the mobile era, and that has led to its drive now to be “mobile- first, cloud-first.” It’s also worth thinking about where a product might go next. While sometimes you’ll build a product by releasing it to customers, getting feedback, and reacting to customer demand, you’ll also often need to think about the long term to support overall company strategic initiatives. What do you want to do in three months, in six months, or in two years that you need to lay the groundwork for today? Maybe your product is free right now but your company wants to add a subscription payment
  • 58. 58 THE PRODUCT BOOK system—your customers aren’t asking to pay you each month, but your company needs to generate revenue to survive. You’ll need to do work now so that you can handle billing information later. Roadmap Companies generally collect their product plans into a 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. It’s a valuable tool to help people communicate about the company, both internally by helping employees understand what projects you’re working on next, and externally by helping partners anticipate your needs or plan for products you’re releasing, a situation common with hardware-component providers. 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. This happens over the long term because priorities can change, and it’s not worth planning out details for things that might not happen. Just knowing you want to work on something at a high level is sufficient. Companies and products will have related roadmaps. The compa- ny-level one defines how all the products come together, and the product one—obviously—focuses on each specific product. Company roadmaps are generally determined by senior executives at a company, such as the CEO or the head of product. Product roadmaps are created by the product’s PMs, and are often influenced by and exert influence over the company roadmap. The factors we discussed at the very beginning of this chapter, in the “What Product Are We Building?” section, affect the roadmap, too.
  • 59. 59 2. Strategically Understanding a Company The best roadmaps are ones where the company has set goals to achieve and then planned projects that will help it achieve those goals. These roadmaps will also provide the sense of the ownership needed for each project, and determine the order in which the projects should happen. The next chapters will cover how we find opportunities and how items end up on the roadmap, but for now simply know that roadmaps are not arbitrary. Roadmaps take many forms. Sometimes they’re a spreadsheet using colors to show all the scheduled projects, their timeframes, and what goal each project supports. Other times companies use a special tool like Aha! (http://aha.io) that has additional features, such as bug-tracking integration with Jira so that you can dig into specific details like how each bug relates to the roadmap. It doesn’t matter what tool you use to create your roadmap—it matters that you have a roadmap. There’s one major risk with roadmaps—you don’t know the future, and if your plans change someone might ask you later on why you didn’t deliver an item on the roadmap. Keeping roadmaps up to date and keeping items further out intentionally vague—even if you have more accurate timing estimates—can help alleviate this issue. 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? At Product School, we had a student who cofounded a service focused on helping schools book their facilities for other events. Originally, he and his company were not aware of any other competitors. However, while
  • 60. 60 THE PRODUCT BOOK the student was in class and working on his final project, he discovered that another company had pivoted from focusing on broader booking services to focusing specifically on schools. While this was validation that there’s an opportunity with the use cases his company was targeting and it focused on delivering a better product than its competitors, it stressed him out knowing that his company wasn’t the only one playing in that space anymore! Beyond competition, what’s going on in the industry in general? Has some broader invention or change caused every company to drastically alter its plans? For example, as smartwatches become popular, many companies are racing to create their own watches or versions of their apps for watches. And with Google Chrome now blocking Flash ads, ad tech companies are forced to adjust their plans to deal with this change. Broader world changes can impact a company, too. China devalued its currency in August 2015, possibly to keep its manufacturing rates attractive, and that has had an impact on revenue for companies that sell in China. It also might have had an influence any company looking to build its products in Vietnam. The world, and especially technology, doesn’t stand still! A great PM will stay on top of the news to make sure that her company doesn’t fall by the wayside because it missed a broader force that changed! A 5C ANALYSIS If you’ve ever talked with consultants or MBAs, you probably heard them name-drop a framework or seven. There is a variety of “standard” frameworks in the business world—we say “standard” because there are many similar frameworks, and different companies pick different standards. We’ll cover some common ones in this book, but we will always prioritize presenting things with a product focus, even if it means we don’t use a framework.
  • 61. 61 2. Strategically Understanding a Company There’s a framework called 5C that’s similar to the areas we just covered. It’s a situational framework, meaning it helps you understand a company’s current situation so that you can create an opportunity hypothesis. The 5C structure is generic—useful to product, marketing, and more—whereas the way we presented the sections in this chapter is very focused on product management. It’s good to know what the “C”s stand for because you’ll likely hear 5C mentioned. Plus if you need to do a situational analysis on your feet in a meeting or interview, it’s relatively easy to remember. • 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.