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

1. What Is Product Management?

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
11
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
 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
12 example, calls its product managers “Program Managers.” Apple generally
splits the product manager role into the “Engineering Program Manager”
THE PRODUCT BOOK

(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
orchestra will be prepared for the concerts. Program managers are involved
in planning the entire season’s schedule for the concert hall, setting things
up so that the project managers can make each performance successful.
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-

1. What Is Product Management?

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 13
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
 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
Management
14
Product Product
Development Marketing
THE PRODUCT BOOK

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

1. What Is Product Management?

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

While you will often hear people talk about product managers in the general
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.
 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
16 customers using it.
THE PRODUCT BOOK

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

1. What Is Product Management?

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

18 Every product goes through five key conceptual stages:
THE PRODUCT BOOK

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

1. What Is Product Management?

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 19
learning about aspects of the company that contribute to its product success
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
 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
20 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
THE PRODUCT BOOK

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