Product marketing is our critical partner in this.
Modern product marketing managers represent the market to the product
team---the positioning, the messaging, and a winning go-to-market plan.
They are deeply  engaged with
the sales channel and know their capabilities, limitations, and current
competitive issues.
The nature of product marketing is a bit different, depending on the
type of business you have and how your product gets to market. When you
make products for businesses that are sold through either a direct sales
force or a channel sales organization, it is a very significant and
critical job to declare the positioning---by that we mean the market
position the product must occupy, in addition to the
messaging---digital/content assets, sales tools, and training that
enable sales to effectively sell.
If your company has a sales organization, and you don't have a product
marketing partner, then this responsibility likely falls on you as
product manager. This can easily become a full-time job. And given the
cost of the sales organization, it's really not an option to ignore
them. But, of course, if you're spending your day helping the sales
organization, who is figuring out the product for these people to sell?
If your company sells directly to consumers, it becomes easy for the
marketing teams to focus on clicks and brand at the expense of ensuring
all the product work adds up to a successfully differentiated market
position. This is important to the long-term prospects of any company
but also brings more meaning into all the work the product team does.
It is very much in your best interest to make sure you have a product
marketing manager to work with, and it's absolutely worth your time to
make sure you understand the market---and your product marketing
colleague understands the product---well enough for each of you to be
successful.
There are many important interactions throughout discovery and delivery,
so it's worth making a special effort to develop and maintain a strong
working relationship with your product marketing colleague. For example,
ensuring the product team is getting good signal from a broad enough
representation of the market. It also becomes important in the messaging
and deciding on the go-to-market plan based on these early product
signals.
Note here that I am talking about the modern definition of the product
marketing role. I am not
describing the old model wherein product marketing was responsible for
defining the product, and product management was primarily responsible
for working with engineering to deliver that product.
Having a strong product marketing partner does not diminish in any sense
the product manager's responsibility for delivering a successful
product. The best product marketing manager and product manager
relationships understand their respective roles but realize they are
essential to each  other's
success.


Modern product marketing managers represent the market to the product
team---the positioning, the messaging, and a winning go-to-market plan.
They are deeply engaged with the sales channel and know their
capabilities, limitations, and current competitive issues.


Product marketing managers are a little different from the other members
of the product team. This is not because they are any less important,
but because the product marketing manager is usually not a full-time,
dedicated member of each product team.
Product marketing is most typically organized by customer-facing
product, by target market, or sometimes by go-to-market channel,
especially for more established companies (e.g., enterprise, vertical,
mid-market). There are typically fewer product marketers than product
teams, as such, they get spread across different product teams.
In the best tech product companies, product marketing plays an essential
role in discovery, delivery, and, ultimately, go-to-market, which is why
they are important members of the product team.
As you'll soon see, coming up with winning products is never easy. We
need a product that our customers love, yet also works for our business.
However, a very large component of what is meant by works for our
business is that there is a real market there (large enough to sustain
a business), we can successfully differentiate from the many competitors
out there, we can cost-effectively acquire and engage new customers, and
we have the go-to-market channels and capabilities required to get our
product into the hands of our customers.


[CHAPTER 13][Product Marketing Managers]


The Tech Lead Role
There are, of course, many different types of engineers. Some focus on
engineering the user experience (generally referred to as front-end
developers), and some focus on specific technologies (for example,
database, search, machine learning).
Similarly, as with most other roles, there is a career progression for
engineers. Many go on to become senior engineers, and some go from there
to principal engineer or architect roles. Others move into more of an
engineering leadership path, which generally starts with the tech lead
role (aka dev lead, or lead engineer).
In general, from the product management perspective, any senior engineer
is helpful because of the broad knowledge he or she brings that pertains
to what is possible. However, a tech lead not only has this
knowledge---and is responsible for helping to share this knowledge with
the other engineers on the team---but the tech lead also has an explicit
responsibility to help the product manager and product designer discover
a strong solution.
Not every engineer or even senior engineer wants to participate in
discovery activities, and this is fine. What's not okay is to have a
team of engineers in which none of them wants to engage in discovery
activities.
It is for this reason that the product manager and product designer work
most closely with  the tech
lead. In some product teams, there may be more than one tech lead, which
is all the better.
It's also worth pointing out that engineers often have different work
styles, which is also true for many designers. The product manager needs
to be sensitive to the best way to interact. For example, many product
managers are happy to speak in front of a larger group, or even a group
of senior executives, but many engineers or designers are not. It's
important to be sensitive to this.


It's also hugely important that you have an actual appreciation for the
demands and complexities of the engineering job. If you were an engineer
before or if you've studied computer science in school, you're
probably in good shape. But if not, I want to strongly encourage you to
take a class at a local community college or online education where
you'll learn a programming
language.
The purpose of developing this programming literacy is not so you start
telling your engineers how to do their job but, rather, to significantly
improve your ability to engage with and collaborate with your engineers.
Less obviously, but at least as important, this knowledge will give you
a much better appreciation for technology and the art of the possible.
It's also critical that you share very openly what you know about your
customers---especially their pain---the data, and your business
constraints. Your job is to bring this information to your team and then
to discuss the various potential solutions to these problems.
There is nothing wrong with you bringing a strong point of view, but you
must constantly demonstrate to your team that you're open minded, you
know how to listen, and you want and need their help in coming up with
the right product.
As a practical matter, you need to engage directly with your engineers
every workday. There are typically two types of discussions going on
each day. In the first type of discussion, you're soliciting their
ideas and input for the items you're working on in discovery. In the
second type of discussion, they're asking you clarifying questions on
the items they're working on delivering to production.
Where a lot of product managers go sideways is in how they communicate
with their engineers. Just as most product managers don't like it when
an executive or stakeholder spells out exactly what they want you to
build, engineers generally don't like it when you try to spell out how
to build something. So, while it's good if you have a strong technology
understanding, it's not good if you use that knowledge to try to do
their jobs for them.
You want to give your engineers as much latitude as possible in coming
up with the best solution. Remember, they are the ones who will be
called in the middle of the night to fix issues if they arise.
One last thing to keep in mind: the morale of the engineers is very much
a function of you as the product manager. It is your job to make sure
they feel like missionaries and not mercenaries. You do this by
involving them deeply in the customer pain you are trying to solve and
in the business problems you face. Don't try to shelter them from
this---instead, share these
problems and challenges very openly with them. They will respect you
more for it, and, in most cases, the developers will rise to the
challenge.


There's probably no more important relationship for a successful
product manager than the one with your engineers.


In this chapter, I describe the engineering role (also commonly known as
developers or, in some circles, programmers). But as with the last
chapter, I'm not trying to speak here to the engineers---I'm aiming
this discussion at product managers who need to learn how to work
effectively with engineers.
There's probably no more important relationship for a successful
product manager than the one with your engineers.
If your relationship is strong, with mutual and sincere respect both
ways, then the product manager job is great. If your relationship is not
strong, your days as product manager will be brutal (and probably
numbered). Therefore, this is a relationship worth taking very seriously
and doing everything you can to nurture.
This strong relationship begins with you. You need to do your homework
and bring to the team the knowledge and skills of good product
management.
Engineers are typically smart and often skeptical by nature, so if
you're bluffing, they likely won't be fooled. If you don't know
something, it's much better to fess up and say you'll find out rather
than try to bluster.


[CHAPTER 12][The Engineers]


The bottom line is that you and your designer really are partners.
You're there to discover the necessary product solutions together, and
you each bring different and critical skills to the team.


[Do whatever you need to do to have your designer sit next to
you.]
[Include your designer from the very inception of every
idea.]
[Include your designer in as many customer and user interactions as
possible. Learn about the users and customers
together.]
[Fight your temptation to provide your designer with your own design
ideas. Give your designer as much room as possible to solve the
design challenges him or herself.]
[Encourage your designer to iterate early and often. The best way
you can encourage this is to not get all nitpicky about design
details with the very early iterations. More generally, encourage
your designer to feel free not to just iterate on the particular
design approach but to explore alternative solutions to the
problem.]


If that's the way we needed
to work, we'd probably continue to use external agencies. But it's
not. We need design---not just as a service to make our product
beautiful---but to discover the right product.
In strong teams today, the design informs the functionality at least as
much as the functionality drives the design. This is a hugely important
concept. For this to happen, we need to make design a first-class member
of the product team, sitting side by side with the product manager, and
not a supporting service.
Once you get a designer dedicated to your product team, here are five
keys to a successful and healthy relationship with your designer:


We need design---not just as a service to make our product
beautiful---but to discover the right product.


All three situations are
serious problems because they rarely provide good results. They don't
provide the full holistic design we're looking for.
Apple is one of the most valuable and design-conscious companies on the
planet; yet few tech companies understand the importance of design
talent. While everyone talks about the engineers at Google and
Facebook---and their engineering is indeed strong---both companies have
made huge investments in design talent.
If you are building user-facing products, it's critically important
that you get a trained product designer for your team. If you're doing
products for consumers, I would argue that strong design today is table
stakes. If you're doing products for businesses, then this is one of
your best competitive differentiators.
It's sad to say, but most products for businesses have awful design.
They've been able to get away with this, however, because the user is
so often not the customer---the one that buys. I'm happy to say that's
now changing, and there's a new breed of B2B (business-to-business)
companies that take design very seriously. They are displacing the old
guard.
In the case of products for small businesses, the user is typically the
buyer, so the bar is set as high as it is for consumer products.
But getting your organization to invest in design staff is only half of
the solution.
Here's why.
Many organizations wake up one morning and suddenly realize design is
important. So, they spend money to bring this talent in-house; yet, they
set up the operation like it's an internal agency. You're supposed to
bring your design requests to this group of designers---often sitting
together in their own little studio---and when they're done, you get
the results.


[You as product manager try to do the actual design yourself. Now,
this is distinct from the situation where you are a trained designer
and have also taken on the product manager responsibilities. In this
situation, you have not been trained in design; yet, your
engineers clearly need designs, so you oblige. That usually means
you provide the engineers with wireframes, and they cobble together
some form of visual design themselves.]
[You as product manager don't provide the designs but, rather,
provide very high-level user stories to the engineers. To begin
coding, the engineers have no choice but to work out the design
themselves.]
[You as product manager provide the interaction design---especially
the wireframes---and then you use a visual or graphic designer to
provide the visual design.]


Prototyping
Later in this book I explore the many techniques used to test out
product ideas. Many of these techniques depend on prototypes, and most
of these prototypes are created by the product designer.
Good product designers use prototypes as their primary canvas for
communicating ideas, both internally and externally. They are generally
comfortable with many different prototyping tools and are able to apply
the correct one for the task at hand.
User Testing
Good product designers are constantly testing their ideas with real
users and customers. They don't just test when a prototype or idea is
ready; they build testing into their weekly cadence, so they're able to
constantly validate and refine ideas as well as collect new insights
they might not have been looking for. It also means that they aren't as
likely to become too attached to ideas before they come in contact with
objective, outside opinions.
User testing is broader than usability testing. Product designers and
their product teams utilize the opportunity to assess the value of
their ideas. Will customers use or buy the product and, if not, why not?
Interaction and Visual Design
Interaction and visual design have historically been considered separate roles.
Interaction design generally includes the underlying conceptual models
(e.g., a photo management application may have photos, albums,
projects), task flows, and control layouts to manipulate those concepts.
Visual design includes composition, typography, and how the visual
brand is expressed.
Modern product designers may have different strengths but, generally,
have some level of skill with both interaction and visual design. Having
a more complete tool set allows them to work quickly at different levels
of fidelity, depending on the context. It also allows them to design
experiences in ways that wouldn't have been natural when thinking of
interaction and visual design separately. This is particularly important
in mobile interfaces in which designers must often create new models of
interaction fundamentally intertwined with the visual design.
If you're building devices such as consumer electronics, there's
another critical dimension to design---industrial design---which looks
at materials and design for manufacturing.
The Absence of Product Design
Three situations in particular are incredibly common and serious
problems:


[How will customers first learn about the
product?]
[How will we onboard a first-time user and (perhaps gradually)
reveal new functionality?]
[How might users interact at different times during their
day?]
[What other things are competing for the user's
attention?]
[How might things be different for a one-month-old customer versus a
one-year-old customer?]
[How will we motivate a user to a higher level of commitment to the
product?]
[How will we create moments of
gratification?]
[How will a user share his experience with
others?]
[How will customers receive an offline
service?]
[What is the perceived responsiveness of the
product?]


Rather than being measured on the output of their design work, the
product designer is measured on the success of the product. Given this,
product designers have many of the same concerns as product managers.
They are deeply oriented around actual customers and the value their
product brings to those customers. They also understand that the product
is in service  of a business
and can incorporate those constraints into the design of the product.
Designers further understand that the user experience is as important to
customer value as is the underlying functionality.
Holistic User Experience Design
User experience (UX) is much bigger than user interface (UI). Some
people even use the term customer experience to further emphasize the
point. UX is any way that customers and end users realize the value
provided by your product. It includes all the touch points and
interactions a customer has with your company and product over time. For
modern products, this usually includes multiple different interfaces, as
well as other customer touch points (e-mail, marketing campaigns, sales
process, customer support, and so forth).
With some products, UX also includes offline services, such as riding in
a car summoned through Uber or staying in a house sourced through
Airbnb.
Good product designers think about the customer's journey over time as
they interact with the product and with the company as a whole.
Depending on the product, the list of touch points could be very long,
considering questions as:


Rather than being measured on the output of their design work, the
product designer is measured on the success of the product.


In this chapter, I describe the product designer role. But I'm not
trying to speak here to designers---I'm aiming this at product managers
who need to learn how to work effectively with designers.
It's amazing to me how many companies I encounter that just don't
understand why having strong and talented designers is so important.
They understand the need for engineers, but often will waste significant
time and money because they do not understand the need for design.
Modern product designers are responsible for the following:
Product Discovery
In the old model, designers took requirements or specifications from
product managers and used that to create their designs. In contrast,
modern product designers continuously collaborate with product managers
and engineers---from discovery to delivery. Similarly, rather than
sitting with fellow designers, the modern product designer sits side by
side with his or her product manager, a full partner with the product
manager on product discovery.


[CHAPTER 11][The Product Designer]


[Introduction to Business
Accounting/Finance]
Just as you need to know the language of computing, you also need to
know the language of business. If you have never done so, you need
to take a course in the basics of business finance.
You will need to understand how for-profit companies work and the main business key
performance indicators (KPIs) that are important to your
business---including, but not limited to, lifetime value of
customers, average revenue per user/customer, customer acquisition
cost, cost of sales, and contribution margins, among others.
A good general marketing course will often cover these topics as
well. The key is to make sure you gain a big-picture understanding
of how businesses work.
You can easily do this through a community college course or through
self-study, especially if you ask someone in your finance department
to guide you a little. This is a good thing to do in any case.


[Introduction to Computer Programming]
If you have never taken a course in a programming language, then
this is your first necessary class. It doesn't really matter which
language but not HTML. You can try to do this online, but I will
tell you that many people struggle with learning their first
programming language; therefore, an actual course for which you're
accountable for turning in programming assignments every week is
what it usually takes.
You may love it, or you may hate it, but either way it will
fundamentally expand your technology horizons and enable you to have
much richer discussions with your engineers and designers. It will
also give you a better appreciation for the power of enabling
technology.


The Two Critical Classes for Product Managers
Product managers come  to the
role from any and all disciplines. Certainly, many come from computer
science, while others may come from business or economics. But you'll
find great product managers that come from politics, philosophy, art,
literature, history---and everything in between.
If you want to be an engineer or a designer, there is an academic
education to be had that will prepare you for a career in those fields.
That is not the case with tech product management. That's because
what's most essential for this job is the smart, creative, and
persistent qualities I've discussed.
That said, I believe there are two specific academic courses that every
product manager should take:


In product companies, it is critical that the product manager also be
the product owner. If you split these roles into two people, some very
common and predictable problems result---most commonly, the loss of your
team's ability to innovate and consistently create new value for your
business and your customers. Moreover, the additional responsibilities
of the product manager are what enables good product owner decisions in
a product company.
Second, while I always encourage product managers to learn the
development process their team is using, taking a class or certification
on the product owner role covers a very small part of the
responsibilities of a product manager.
To summarize, product owner responsibilities are a small subset of
product management responsibilities, but it's critical that the product
manager covers both.


In product companies, it is critical that the product manager also be
the product owner.


Product Manager versus Product Owner
You've likely encountered the term product owner, and you may wonder
how it relates to the product manager job.
First, product owner is the name of the role on an Agile team for the
person responsible for the product backlog. Keep in mind that Agile is
used in all types of companies, not just product companies.


No matter what your title or level may be, if you aspire to be great,
don't be afraid to lead.


[Product management is absolutely distinct from the other
disciplines. It's clearly different than the contribution of the
designers, and it's also clearly not a project manager. There is
some amount of project management inevitably involved, just as there
is for all leadership positions. But to characterize this as a
project manager is to completely miss the essence of the role. The
role I would argue the product manager is most similar to is the
role of the CEO. But with the obvious difference that, unlike the
CEO, the product manager is not the boss of
anyone.]
[Like a CEO, the product manager must deeply understand all
aspects of the business. The product manager must ensure a
business outcome, not just ensure a product gets defined. This
requires a good understanding of the many interrelated parts and
constraints of the business---financial, marketing, sales, legal,
partnership, service, the customer environment, the technical
capabilities, the user's experience---and figure out a solution
that works for the customers as well as for the business. But don't
think this means an MBA is required---not one of the impressive
product managers I feature in this book has an MBA---or that you
need to have all these skills yourself. You must simply have a broad
understanding of how a product can affect a business and work with
people from your team and across your company to cover everything
that's important.]
[In every one of these examples, the winning solutions didn't
come from users, customers, or sales. Rather, great products
require an intense collaboration with design and engineering to
solve real problems for your users and customers, in ways that meet
the needs of your business. In each of these examples, the users had
no idea the solution they fell in love with was
possible.]
[True leadership is  a
big part of what separates the great product people from the merely
good ones. So, no matter what your title or level may be, if you
aspire to be great, don't be afraid to
lead.]


Anyone who's ever worked in product for any amount of time knows that
creating products is never easy. I selected these particular individuals
to illustrate the very difficult but essential contribution that comes
from a strong product manager.
The products I highlight are all iconic, and you will immediately
recognize them. But few people know the product managers behind these
products, and even fewer know their backstories.
Each of the product  managers
I selected went out of her way to emphasize to me just how amazing their
product team was, and how in no way was the success due to their efforts
alone. But hopefully these examples help make clear to you the true and
essential contribution of the product manager.
The big points I hope you take away from these examples are:


[Jane Manning of Google]
[Lea Hickman of Adobe]
[Alex Pressland of the BBC]
[Martina Lauchengco of Microsoft]
[Kate Arnold of Netflix]
[Camille Hearst of Apple]


I'm not saying that doing all this is easy; it's not. But believe me
when I tell you it's table stakes for being a successful product
manager.
Product Manager Profiles
In addition to giving you the theory and techniques in this book, I make
a point of introducing you to real people---product managers who have
done their job and done it well. These individuals include:


[Start by becoming an expert in your users and customers. Share very
openly what you learn, both the good and the bad. Become your
team's and your
company's go-to person for understanding anything about your
customer---quantitative and qualitative.]
[Work to establish a strong relationship with your key stakeholders
and business partners. Convince them of two things: (1) You
understand the constraints they operate under. (2) You will only
bring to them solutions that you believe will work within those
constraints.]
[Become an undisputed expert on your product and your industry.
Again, share your knowledge openly and
generously.]
[Finally, work very hard to build and nurture the strong
collaborative relationship with your product
team.]


By smart, I don't just mean raw IQ. I especially mean intellectually
curious, quickly learning and applying new technologies to solve
problems for customers, to reach new audiences, or to enable new
business models.
By creative, I mean thinking outside the normal product box of features
to solve business problems.
By persistent, I mean pushing companies way beyond their comfort zone
with compelling evidence, constant communication, and building bridges
across functions in the face of stubborn resistance.
The passion for products and for solving customer problems is not
something I think you can teach. That's something you either have or
don't have, and it is among the first things I interview for when I'm
evaluating potential product managers. I assume that you have this.
Maybe this is a good time to be very honest with you about the demands
of this role.
The product manager position is not a 9-to-5 job. I'm not saying you
need to be in the office 15 hours a day, but I am saying that there is a
ton of work, and it follows you home every night. Pretty much any other
role on a product team is better if you're looking for a good work-life
balance. Now, I know it may not be politically correct to say that, but
I don't think I'm doing you any favors by misleading you. The level of
time and effort required by the product manager role is extremely tough
to sustain if you're not personally passionate about your products and
your role.
Perhaps the most important thing I can tell you to help you succeed is
that you simply must take very seriously your preparation for this role.


The successful product manager must be the very best versions of
smart, creative, and persistent.


This means knowing who  your
various stakeholders are and especially learning the constraints they
operate under. There are usually key stakeholders representing general
management, sales, marketing, finance, legal, business development, and
customer service. Your CEO is usually a very important stakeholder as
well.
Succeeding in the job of product means convincing each key stakeholder
that you understand their constraints and that you are committed to only
delivering solutions that you believe are consistent with those
constraints.
Deep Knowledge of Your Market and Industry
The fourth critical contribution is deep knowledge of the market and
industry in which you're competing. This includes not only your
competitors but also key trends in technology, customer behaviors and
expectations, following the relevant industry analysts, and
understanding the role of social media for your market and customers.
Most markets have more competitors today than ever before. Further,
companies understand the value in making products that are sticky, and
this means that it can be difficult for prospective customers to move
from your competitor to you. This is one of the big reasons why it is
not enough to have feature parity with a competitor. Rather, you need to
be substantially better to motivate a user or customer to switch.
Another reason to have a deep understanding of the competitive landscape
is that your products will need to fit into a more general ecosystem of
other products, and ideally your product is not only compatible with
that ecosystem but adds significant value to it.
Further, your industry is constantly moving, and we must create products
for where the market will be tomorrow, not where it was yesterday.
As an example, as of this writing, there is a major enabling technology
trend sweeping through our industry, which is based on machine learning
and other forms of artificial intelligence. I feel comfortable
predicting that this will be a major technology trend for at least the
next decade, and this is why you need to love technology-powered
products. What is possible is constantly changing. If you're not excited about learning
these new technologies, and exploring with your engineers and designers
how you can use these trends to deliver dramatically improved products
and experiences to your customers, then you really need to consider
whether this career is for you.
To summarize, these are the four critical contributions you need to
bring to your team: deep knowledge (1) of your customer, (2) of the
data, (3) of your business and its stakeholders, and (4) of your market
and industry.
If you're a designer or engineer, and you've been asked to cover the
product manager role as well, then this is what you need to sign up for.
I warned you---it's a ton of work.
One additional note: In some companies, there is so much in terms of
industry and domain knowledge that the product manager may be
supplemented with what are called domain experts or subject matter
experts. Examples of domain experts can be found in companies that
build tax software or create medical devices. In these cases, you can't
expect the product managers to have the necessary level of domain depth,
in addition to everything else. But these cases are fairly rare. The
normal case is that the product manager does need to have (or be able to
learn) the necessary domain expertise.
It normally takes about two to three months of dedicated work for a new
product manager to get up to speed. This assumes you have a manager who
can give you the help and access you need to gain this expertise,
including lots of access to customers, access to data (and when
necessary, training in the tools to access that data), access to key
stakeholders, and time to learn your product and industry inside and
out.
Smart, Creative, and Persistent
Now that we've seen what the product manager needs to contribute to the
team, let's consider the kind of person who thrives in this
environment.
The successful product
manager must be the very best versions of smart, creative, and
persistent.


Successful products are not only loved by your customers, but they work
for your business.


Sounds simple enough. And the mechanics of that are not the hard part.
What's hard is to make sure that what goes on the product backlog is
worth building. And, today,
on the best teams, the engineers and designers want to see some
evidence that what you're asking to build is truly worth building.
But if you want to know why the product manager role is considered so
important today by CEOs and venture capitalists (VCs), it's this:
Every business depends on customers. And what customers buy---or choose
to use---is your product. The product is the result of what the product
team builds, and the product manager is responsible for what the product
team will build.
So, this is why the product manager is the person we hold responsible
and accountable for the success of the product.
When a product succeeds, it's because everyone on the team did what
they needed to do. But when a product fails, it's the product
manager's fault.
You can start to see why this role is a proving ground for future CEOs
and why the best VCs only want to invest in a company that has one of
these proven product people as one of the co-founders.
So, this chapter is really about what you need to do to succeed at this
job. In that spirit, there are four key responsibilities of a strong
product manager; four things that the rest of your team is counting on
you to bring to the party:
Deep Knowledge of the Customer
First and foremost is deep knowledge of the actual users and customers.
To make this explicit, you need to become an acknowledged expert on the
customer: their issues, pains, desires, how they think---and for
business products, how they work, and how they decide to buy.
This is what informs so many of the decisions that must be made every
day. Without this deep customer knowledge, you're just guessing. This requires both
qualitative learning (to understand why our users and customers behave
the way they do), and quantitative learning (to understand what they are
doing), which is what we'll talk about next.
It should go without saying as it's really table stakes for a product
manager, but just to be clear, the product manager must also be an
undisputed expert on your actual product.
Deep Knowledge of the Data
Today, product managers are expected to be comfortable with data and
analytics. They are expected to have both quantitative skills as well as
qualitative skills. The Internet enables unprecedented volume and
timeliness of data.
A big part of knowing your customer is understanding what they're doing
with your product. Most product managers start their day with half an
hour or so in the analytics tools, understanding what's been happening
in the past 24 hours. They're looking at sales analytics and usage
analytics. They're looking at the results of A/B tests.
You might have a data analyst to help you with this, but the analysis of
the data and understanding you get of your customer is not something you
can delegate.
Deep Knowledge of Your Business
Successful products are not only loved by your customers, but they work
for your business.
The third critical contribution---and the one that is often considered
the most difficult by many product managers---is a deep understanding of
your business and how it works, and the role your product plays in
your business. This is tougher than it sounds.


When a product succeeds, it's because everyone on the team did what
they needed to do. But when a product fails, it's the product
manager's fault.


My intention in this book is to convince you of this third way of
working. It will take me the entire book to describe how the strong
product manager does his or her job, but let me just say for now that
this is a very demanding job and requires a strong set of skills and
strengths.
The reason for calling this out so bluntly is that, in many companies, especially older,
enterprise companies, the product manager role has a bad reputation.
What too often happens is that the company takes people from other
organizational roles---often project management or sometimes business
analysts---and they say, "We're moving to Agile and we don't need
project managers or business analysts anymore, so we need you to be a
product manager."
The honest truth is that the product manager needs to be among the
strongest talent in the company. If the product manager doesn't have
the technology sophistication, doesn't have the business savvy,
doesn't have the credibility with the key executives, doesn't have the
deep customer knowledge, doesn't have the passion for the product, or
doesn't have the respect of their product team, then it's a sure
recipe for failure.
There are lots of ways to describe this particular role. Some people
prefer to focus on the raw ingredients of what makes a strong product
manager. Others tend to focus on the product manager's day-to-day
activities and what they'll be spending their time doing.
We'll cover all that, but to me what's most important to talk about is
what product managers are responsible for contributing to their team.
That's not so obvious for the product manager. It's not that unusual
for people to question whether they even need a product manager. If they
don't design and they don't code, why bother?
This is a clear sign of a company that hasn't experienced strong
product management.
Key Responsibilities
At one level, the responsibilities of the product manager are pretty
straightforward. He or she is responsible for evaluating opportunities
and determining what gets built and delivered to customers. We generally
describe what needs to get built on the product backlog.


The honest truth is that the product manager needs to be among the
strongest talent in the company.


[The product manager can escalate every issue and decision up to
the CEO. In this model, the product manager is really a backlog
administrator. Lots of CEOs tell me this is the model they find
themselves in, and it's not scaling. If you think the product
manager job is what's described in a Certified Scrum Product
Owner class, you almost certainly fall into this
category.]
[The product manager can call a meeting with all the stakeholders
in the room and then let them fight it out. This is design by
committee, and it rarely yields anything beyond mediocrity. In this
model, very common in large companies, the product manager is really
a roadmap administrator.]
[The product manager can do his or her
job.]


This book is about becoming an excellent product manager, and in this
chapter, I want to be very explicit about what that really means.
But first, it's time for a little dose of tough love.
There are essentially three ways for a product manager to work, and I
argue only one of them leads to success:


[CHAPTER 10][The Product Manager]


Principles and Techniques
I want to be clear as to why you'll see so many principles called out
in this book.
When I coach product managers, I always try my best to explain the
underlying principles of why we need to work the way we do.
I find that when a person reaches  the point that they have a solid understanding of the
principles, they develop a good mental model for when each technique is
useful and appropriate, and when it is not. Further, as new techniques
emerge, they are able to quickly assess the potential value of the
technique, and when and where it is best utilized.
I have found over the years that while the techniques change fairly
constantly, the underlying principles endure. So, while it may be
tempting to jump right to the techniques, I hope you will first consider
the principles, and work to develop a deeper understanding of how to
build great products.


It also means we try to minimize dependencies between teams. Notice that
I said "minimize" and not "eliminate." At scale, it's just not possible
to eliminate all dependencies, but we can work hard to continuously
minimize them.
Why It Works
Product companies moved to this model several years ago, and it's now
one of the pillars of modern, strong product organizations. There are
several reasons why this model has been so effective.
First, collaboration is built on relationships, and product
teams---especially co-located teams---are designed to nurture these
relationships.
Second, to innovate you need expertise, and the durable nature of
product teams lets people go deep enough to gain that expertise.
Third, instead of just building  what others determine might be valuable, in the product team
model the full team understands---needs to understand---the business
objectives and context. And most important, the full team feels
ownership and responsibility for the outcome.
Instead of the old project-oriented model, which is all about getting
something pushed through the process and out the door, in the dedicated
team model, the team is not off the hook just because something
launches. They don't rest until and unless it's working for the users
and for the business.
Hopefully you're already a member of a strong, dedicated product team,
and now you just have a better appreciation for the intention of this
model.
On the other hand, if your company is not yet set up around dedicated
product teams, this is probably the most important thing for you to fix.
Everything else depends on this.
You don't have to move the whole organization there at once---you can
start a team as a pilot. But one way or another, it's essential that
you create or join a durable product team.


They are able to try to solve the problems they are assigned in the
best way they see fit.


Team Composition
A typical product team is comprised of a product manager, a product designer, and somewhere
between two and about 10 to 12 engineers.
Of course, if the product you're working on doesn't have a user-facing
experience---such as for a set of programmatic APIs---you probably
don't need the product designer. But many product teams do need this
person on board, and throughout this book, I'll generally assume your
team does, too.
Teams might also have a few other members such as a product marketing
manager, one or more test automation engineers, a user researcher, a
data analyst, and, in larger product organizations, a delivery manager.
Don't worry if you don't yet know what some of these roles
are---we'll soon explore each of them.
Team Empowerment and Accountability
A big part of the concept of product teams is that they are there to
solve hard problems for the business. They are given clear objectives,
and they own delivering on those objectives.
They are empowered to figure out the best way to meet those objectives,
and they are accountable for the results.
Team Size
There's no rule that says all product teams in a company need to be the
same size. It's true there is the notion of critical mass for a product
team---usually one product manager, one designer, and two engineers.
However, some teams might justify five engineers and two test automation
engineers---others even more.
There is a practical upper bound on a team, which usually works out to
be around 8--12 engineers. You've probably heard about the two-pizza
rule, which is intended to help keep teams in this range.
More important than the absolute size of the team is the balance of
skills needed to ensure we build the right things, and build those
things right.
Team Reporting Structure
Note that I haven't said anything yet about who works for whom.
A product team is not about reporting relationships---it has an
intentionally flat organizational structure. Usually, everyone on a
product team is an individual contributor, and there are no people
managers.
The people on the team typically continue to report to their functional
manager. For example, the engineers report to an engineering manager.
Likewise, the designer usually reports to a head of design, and the
product manager reports into a head of product. So, this is not about
reporting relationships.
To be absolutely clear, the product manager is not the boss of anyone
on the product team.
Team Collaboration
A product team is a set of highly skilled people who come together for
an extended period of time to solve hard business problems.
The nature of the relationship is more about true collaboration. I
don't mean collaboration as a buzzword, either. I literally mean
product, design, and engineering working out solutions together. Much
more on that to come, but at this point, it's important for you to
understand that this is not a hierarchy.
Team Location
I also haven't said anything yet about where the members of the team
are physically located. While this isn't always possible, we try very
hard to co-locate this team.
Co-location means that team members literally sit right next to one
another. That doesn't mean in the same building or even the same floor.
It means close enough to easily see each other's computer screens.
I know this sounds a bit old school, and the tools for remote
collaboration are getting better all the time, but the best companies
have learned the value of sitting together as a team.
If you've ever been a member of a co-located product team, you likely
already know what I mean. But, as you'll see from how we do our work on
a product team, there is a special dynamic that occurs when the team
sits together, eats lunch together, and builds personal relationships
with one another.
I'm aware this can be a bit of an emotional topic. For personal reasons, quite a few people
live somewhere other than where they work, and their livelihood depends
on working effectively remotely.
I don't want to paint this as too black or white, but I also don't
want to mislead you. All other things being equal, a co-located team is
going to substantially outperform a dispersed team. That's just the way
it is.
This is also one of the reasons why we greatly prefer members of a
product team to be actual employees and not contractors or agencies.
It's much easier to be co-located and to be a stable member of the team
if the person is an employee.
Note that there is nothing wrong with a company having multiple
locations, so long as we try hard to have co-located teams in each
location.
We'll talk later about what we do when not all the members are able to
sit together.
Team Scope
Once you've got the basics of a product team, the next big question is
this: What is the scope or charter of each team? That is, what is each
team responsible for?
One dimension of this is the type of work to be done, and it's
important that a product team has responsibility for all the work---all
the projects, features, bug fixes, performance work, optimizations, and
content changes---everything and anything for their product.
The other dimension is the scope of work to be done. In some types of
companies, the product team is responsible for a complete product. But
it's more common today that the product is the full customer experience
(imagine a Facebook or a PayPal), and each team is responsible for some
smaller but meaningful piece of that experience.
For example, you might be working on a team at eBay that's responsible
for technology to detect and prevent fraud or tools and services for
high-volume sellers. Or, at Facebook, your team might be responsible for
newsfeeds, an iOS native mobile app, or the capabilities required for a
specific vertical market.
This is an easy topic for a small startup, as you typically just have
one or a small number of teams, which makes it relatively easy to split
things up.
But as a company grows, the number of teams expands from a handful to 20, 50, or more
teams in large product companies. The coordination gets harder (much
more on that when we get to the section on Product @ Scale), but the
concept is highly scalable and, in fact, is one of the keys to
scalability.
There are lots of useful ways to slice up the pie. Sometimes we have
each team focus on a different type of user or customer. Sometimes each
team is responsible for a different type of device. Sometimes we break
things up by workflow or customer journey.
Sometimes, actually very often, we are largely defining the teams based
on the architecture. This is pretty common because the architecture
drives the technology stack, which often requires different types of
engineering expertise.
In any case, what's critically important is alignment between product
management and engineering. This is why the head of product and the head
of engineering normally get together to define the size and scope of the
teams.
I will tell you there's never a perfect way to carve up the pie.
Realize that, when you optimize for one thing, it comes at the expense
of something else. So, decide what's most important to you and go with
that.
Team Duration
I've mentioned a few times already that these teams need to be durable,
but I haven't said whether this means for a few months or several
years.
The bottom line is that we try hard to keep teams together and fairly
stable.
While things do come up, and people change jobs and teams, once the
members of a team get to know one another, and learn how to work well
together, it's honestly a beautiful and powerful thing, and we try hard
not to mess up that dynamic.
Another reason that durability is important is that it can take some
time to gain enough expertise in an area to innovate. If people are
moving from team to team all the time, it's hard for them to get that
expertise and to feel the necessary sense of ownership over their
product and missionary-like passion.
And to be clear, a product team is not something we create just to deliver a specific project.
It's nearly impossible to have a team of missionaries when they're
pulled together for a project that lasts only a few months and is then
disbanded.
Team Autonomy
If we want teams to feel empowered and have missionary-like passion for
solving customer problems, we need to give them a significant degree of
autonomy. Obviously, this doesn't mean they can go off and work on
whatever looks fun, but it does mean that they are able to try to solve
the problems they are assigned in the best way they see fit.


We need teams of missionaries, not teams of mercenaries.


In later chapters, I explore each of the key roles on a team, but in
this chapter, I explain the principles of a strong product team.
Product teams are sometimes referred to as a dedicated product team or
as a durable product team, to emphasize that these are not created
just to work on a single project or feature, or sometimes as a
squad---derived from the military analogy and meant to emphasize that
these are cross-functional teams.
A product team is a group of people who bring together different
specialized skills and responsibilities and feel real ownership for a
product or at least a substantial piece of a larger product.
There are many ways to set up product teams (we'll discuss these later
in the section People @ Scale). But in good product companies, you'll
find that, despite the differences due to their unique products and
circumstances, there are several very important similarities.
Team of Missionaries
There are many benefits of product teams, but a big goal is captured
best by a quote from John Doerr, the famous Silicon Valley venture
capitalist: "We need teams of missionaries, not teams of mercenaries."
Mercenaries build whatever they're told to build. Missionaries are
true believers in the vision and are committed to solving problems for
their customers. In a dedicated product team, the team acts and feels a
lot like a startup within the larger company, and that's very much the
intention.


[CHAPTER 9][Principles of Strong Product Teams]


You'll hear me say this many different ways throughout the chapters to
follow, but so much of what we do in a strong product organization is to
optimize for the effectiveness of product teams.


It's all about the product team.


[Product Teams]
Overview
This is probably the most important concept in this entire book:


[PART II] [The Right People]
Every product begins with the people on the cross-functional product
team. How you define the roles, and the people you select to staff the
team, will very likely prove to be a determining factor in its success
or failure.
This is an area in which many companies fall short, stuck in old models
of the past. For many organizations, the roles and responsibilities
discussed here represent significant differences from what they're used
to.
In Part Two, I describe the key roles and responsibilities
of modern technology-powered product teams.


Minimum Viable Product
The concept of minimum viable product (MVP) is one of the most
important concepts in the product world. It has been around for many
years. The term was coined by Frank Robinson (in 2001), and I wrote
about the concept in the first edition of this book (in 2008). It was
popularized, however, in the book The Lean Startup by Eric Ries in
2011.
Eric's book did a great deal to help product teams, and to me, it is a
must-read book for all product people. But I think most people would
likely admit that the concept of MVP has caused considerable confusion
within product teams, and I spend a lot of my time helping teams get
value out of this critical concept.
The vast majority of times I meet a team that has been working hard to
create an MVP I am able to convince them that they could have achieved
the same learning in a fraction of the time and effort.
They have spent literally
months building an MVP when they could have had this same learning in
days or, sometimes, even in hours.
The other unhappy consequence is that very often the rest of the
company---especially key leadership in sales and marketing---is confused
and embarrassed by what the product team is trying to get customers to
buy and use.
While this is partly a result of the way most people have learned this
concept, I think the root of the issue is that while the P in MVP stands
for product, an MVP should never be an actual product (where product
is defined as something that your developers can release with
confidence, that your customers can run their business on, and that you
can sell and support).
The MVP should be a prototype, not a product.
Building an actual product-quality deliverable to learn, even if that
deliverable has minimal functionality, leads to substantial waste of
time and money, which of course is the antithesis of Lean.
I find that using the more general term prototype makes this critical
point clear to the product team, the company, and the prospective
customers.
So, in this book, I talk about different types of prototypes being
used in discovery and products being produced in delivery.


To set your expectations, strong teams normally test many product ideas
each week---on the order of 10 to 20 or more per week.
I want to emphasize that these are experiments, typically run using
prototypes. A prototype is not something that's ready for prime time
and certainly not something your company would try to sell and stand
behind. But they're immensely useful, as they're all about learning
fast and cheap.
Product Delivery
The purpose of all these prototypes and experiments in discovery is to
quickly come up with something that provides some evidence it is worth
building and that we can then deliver to our customers.
This means the necessary scale, performance, reliability, fault
tolerance, security, privacy, internationalization, and localization
have been performed, and the product works as advertised.
The purpose of product delivery is to build and deliver these
production-quality technology products, something you can sell and run
a business on.
Products and Product/Market Fit
Just because we've invested the time and effort to create a robust
product does not mean anyone will want to buy it. So, in the product
world, we strive to achieve product/market fit.
This is the smallest possible actual product that meets the needs of a
specific market of customers. Marc Andreessen is credited with
popularizing this all-important concept, and it is a major focus of this
book.
And just to be clear, since these are actual products, they are the
result of delivery. The discovery activities help us determine the
necessary product, but it is delivery that actually does the work
necessary to build, test, and release the product.
Product Vision
The final critical concept
is product vision. This refers to the longer-term objective of this
product, normally 2--10 years out. It is how we as a product
organization intend to deliver on the company's mission.
So, we use prototypes to conduct rapid experiments in product
discovery, and then in delivery, we build and release products in
hopes of achieving product/market fit, which is a key step on the way
to delivering on the company's product vision.
Now don't worry if you're hazy on any of these concepts. I know you
likely have many questions, but they'll hopefully become clear as we
dive deeper into each topic. It's also normal to be a little
skeptical---"How can I possibly run 15 of these experiments in a week?"
I warned you that strong product teams work nothing like most teams, and
this should give you your first taste of how different things can be.


To set your expectations,
strong teams normally test many product ideas each week---on the order
of 10 to 20 or more per week.


Prototypes
Product discovery involves running a series of very quick experiments,
and to do these experiments quickly and inexpensively, we use
prototypes rather than products. At this point, let me just say that
there are several types of prototypes, each for different risks and
situations, but they all require at least an order of magnitude of
less time and effort than building a product.


[Will the user buy this (or choose to use
it)?]
[Can the user figure out how to use this?]
[Can our engineers build this?]
[Can our stakeholders support this?]


Product Discovery
Discovery is very much about the intense collaboration of product
management, user experience design, and engineering. In discovery, we
are tackling the various risks before we write even one line of
production software.
The purpose of product discovery is to quickly separate the good ideas
from the bad. The output of product discovery is a validated product
backlog.
Specifically, this means getting answers to four critical questions:


We need to discover the product to be built, and we need to deliver
that product to market.


In this book, I refer to a set of concepts that form the foundation of
modern product work. I'd like to briefly explain them here.
Holistic Product
I have already been using the term product pretty loosely. I did say
I'm only talking about technology-powered products. But, more
generally, when I refer to product I mean a very holistic definition of
product.
This certainly includes the functionality---the features.
But it also includes the technology that enables this functionality.
It also includes the user experience design that presents this
functionality.
And it includes how we monetize this functionality.
It includes how we attract and acquire users and customers.
And it can also include offline experiences as well that are essential
to delivering the product's value.
If, for example, your
product is an e-commerce site, then this would include the
merchandise-fulfillment experience and the merchandise-return
experience. In general, for e-commerce businesses, product includes
everything except the actual merchandise being sold.
Similarly, for a media company, we refer to the product as everything
except the content.
The point is to have a very inclusive and holistic definition of
product. You are not just concerned with implementing features.
Continuous Discovery and Delivery
I explained previously that most companies still have a process that is
essentially waterfall at its core, and I told you that what we do in a
modern team is very different.
We'll be going more into the product development process later, but I
do need to introduce a high-level concept about process at this point in
our discussion. That is, there are two essential high-level activities
in all product teams. We need to discover the product to be built, and
we need to deliver that product to market.
<figure "Illustration of Continuous Discovery and Delivery."/>
Discovery and delivery are our two main activities on a cross-functional
product team, and they are both typically ongoing and in parallel.
There are several ways to think about this and to visualize it, but the
concept is fairly simple: We are always working in parallel to both
discover the necessary product to be built---which is primarily what
the product manager and designer work on every day---while the engineers
work to deliver production-quality product.
Now, as you'll soon see, it's a little more involved than that. For
example, the engineers are also helping daily on discovery (and many of
the best innovations come from that participation, so this is not a
minor point), and the product manager and designer are also helping
daily on delivery (mainly to clarify intended behavior). But this is
what's going on at a high level.


[CHAPTER 8][Key Concepts]


You will see that I keep these three overarching principles front and
center throughout this book.


[Risks are tackled up front, rather than at the end. In modern
teams, we tackle these risks prior to deciding to build anything.
These risks include value risk (whether customers will buy it),
usability risk (whether users can figure out how to use it),
feasibility risk (whether our engineers can build what we need
with the time, skills, and technology we have), and business
viability risk (whether this solution also works for the various
aspects of our business---sales, marketing, finance, legal,
etc.).]
[Products are defined and designed collaboratively, rather than
sequentially. They have finally moved beyond the old model in
which a product manager defines requirements, a designer designs a
solution that delivers on those requirements, and then engineering
implements those requirements, with each person living with the
constraints and decisions of the ones that preceded. In strong
teams, product, design, and engineering work side by side, in a
give-and-take way, to come up with technology-powered solutions that
our customers love and that work for our
business.]
[Finally, it's all about solving problems, not implementing
features. Conventional product roadmaps are all about output.
Strong teams know it's not only about implementing a solution. They
must ensure that solution solves the underlying problem. It's about
business results.]


People are always searching for a silver bullet to create products, and
there is always a willing industry---ready and waiting to serve with
books, coaching, training, and consulting. But there is no silver
bullet, and inevitably people figure this out. That's when the backlash
begins. As I write this, it's in vogue to criticize both Lean and
Agile.
I have no doubt that many people and teams are in some measure
disappointed with the results from their adoption of both Lean and
Agile. And I understand the reasons for this. That said, I am convinced
that Lean and Agile values and principles are here to stay. Not so much
the particular manifestations of these methods that many teams use
today, but the core principles behind them. I would argue that they both
represent meaningful progress, and I would never want to go backward on
those two fronts.
But as I said, they are not silver bullets either, and as with any tool,
you have to be smart about how you use it. I meet countless teams that
claim to be following Lean principles; yet, they work for months on what
they call an MVP, and they really don't know what they have and whether
it will sell until they've spent substantial time and money---hardly in
the spirit of Lean. Or they go way overboard and think they have to test
and validate everything, so they go nowhere fast.
And, as I just pointed out, the way Agile is practiced in most product
companies is hardly Agile  in
any meaningful sense.
The best product teams I know have already moved past how most teams
practice these methods---leveraging the core principles of Lean and
Agile, but raising the bar on what they're trying to achieve and how
they work.
When I see these teams, they may frame the issues a little differently,
sometimes using different nomenclature, but at the heart, I see three
overarching principles at work:


[CHAPTER 7][Beyond Lean and Agile]


The good news is I promise you that the best teams operate nothing
like  what I've just
described.


It's no surprise that so many companies spend so much time and money
and get so little in return.


It's no surprise that so many companies spend so much time and money
and get so little  in return.
I warned you this could be depressing. But it's critical that you have
a deep understanding of exactly why your company needs to change how it
works, if, indeed, your company is working this way.


[Finally, while we're busy doing this process and wasting our time
and money, the biggest loss of all usually turns out to be the
opportunity cost of what the organization could have and should
have been doing instead. We can't get that time or money
back.]


[The biggest flaw of the old waterfall process has always been, and
remains, that all the risk is at the end, which means that customer
validation happens way too late.]
The key principle in Lean methods is to reduce waste, and one of the
biggest forms of waste is to design, build, test, and deploy a
feature or product only to find out it is not what was needed. The
irony is that many teams believe they're applying Lean
principles; yet, they follow this basic process I've just
described. And then I point out to them that they are trying out
ideas in one of the most expensive, slowest ways we know.


[This entire process is very project-centric. The company usually
funds projects, staffs projects, pushes projects through the
organization, and finally launches projects. Unfortunately,
projects are output and product is all about outcome. This process
predictably leads to orphaned projects. Yes, something was finally
released, but it doesn't meet its objectives so what really was the
point? In any case, it's a serious problem, and not close to how we
need to build products.]


[Not only is engineering brought in way too late, but the principles
and key benefits of Agile enter the picture far too late. Teams
using Agile in this way are getting maybe 20 percent of the actual
value and potential of Agile methods. What you're really seeing is
Agile for delivery, but the rest of the organization and context is
anything but Agile.]


[Maybe the biggest missed opportunity in this model is the fact that engineering
gets brought in way too late. We say if you're just using your
engineers to code, you're only getting about half their value. The
little secret in product is that engineers are typically the best
single source of innovation; yet, they are not even invited to the
party in this process.]


[It's a similar story with the role of design. It's way too late
in the game to get the real value of design, and mostly what's
being done is what we call the "lipstick on the pig" model. The
damage has already been done, and now we're just trying to put a
coat of paint on the mess. The UX designers know this is not good,
but they try to make it look as nice and consistent as they
can.]


[Next, let's consider the role of product management in this
model. In fact, we wouldn't call this role product
management---it's really a form of project management. In this
model, it's more about gathering requirements and documenting
them for engineers. At this point, let me just say that this is 180
degrees away from the reality of modern tech product
management.]


The first truth is  that
at least half of our ideas are just not going to work. There are
many reasons for an idea to not work out. The most common is that
customers just aren't as excited about this idea as we are. So,
they choose not to use it. Sometimes they want to use it and they
try it out, but the product is so complicated that it's simply more
trouble than it's worth, so users again choose not to use it.
Sometimes the issue is that customers would love it, but it turns
out to be much more involved to build than we thought, and we decide
we simply can't afford the time and money required to deliver it.
So, I promise you that at least half the ideas on your roadmap are
not going to deliver what you hope. (By the way, the really good
teams assume that at least three quarters of the ideas won't
perform like they hope.)
If that's not bad enough, the second inconvenient truth is that
even with the ideas that do prove to have potential, it typically
takes several iterations to get the implementation of this idea to
the point where it delivers the necessary business value. We call
that time to money.
One of the most important things about product that I've learned is
that there is simply no escaping these inconvenient truths, no
matter how smart you might be. And I've had the good fortune to
work with many truly exceptional product teams. The real difference
is how you deal with these truths.


The first truth is that at least half of our ideas are just not
going to work.


[An even bigger issue is what comes next, which is when companies
get really excited about their product roadmaps. I've seen
countless roadmaps over the years, and the vast majority of them are
essentially prioritized lists of features and projects. Marketing
needs this feature for a campaign. Sales needs this feature for a
new customer. Someone wants a PayPal integration. You get the
idea.]
But here's the problem---maybe the biggest problem of all. It's
what I call the two inconvenient truths about product.


[Next, let's talk about the fatal flaw in these business cases. To be clear, I'm
personally in favor of doing business cases, at least for ideas that
need a larger investment. But the way most companies do them at this
stage to come up with a prioritized roadmap is truly ridiculous and
here's why. Remember those two key inputs to every business case?
How much money you'll make, and how much it will cost? Well, the
cold, hard truth is that, at this stage, we have no clue about
either of these. In fact, we can't know.]
We can't know how much money we'll make because that depends
entirely on how good the solution turns out to be. If the team does
an excellent job, this could be wildly successful and literally
change the course of the company. The truth, however, is that many
product ideas end up making absolutely nothing. And that's not an
exaggeration for effect. Literally nothing (we know this from A/B
testing).
In any case, one of the most critical lessons in product is knowing
what we can't know, and we just can't know at this stage how much
money we'll make.
Likewise, we have no idea what it will cost to build. Without
knowing the actual solution, this is extremely hard for engineering
to predict. Most experienced engineers will refuse to even give an
estimate at this stage, but some are pressured into the old t-shirt
sizing compromise---just let us know if this is "small, medium,
large, or extra large."
But companies really want those prioritized roadmaps, and to get
one, they need some kind of system to rate the ideas. So people play
the business case game.


While almost everyone today claims to be Agile, what I've just
described is very much a waterfall process.


[Let's start at the top---the source of ideas. This model leads
to sales-driven specials and stakeholder-driven products. Lots more
to come on this key topic, but for now, let me just say that this is
not the source of our best product ideas. Another consequence of
this approach is the lack of team empowerment. In this model,
they're just there to implement---they're
mercenaries.]


Let's start by exploring the root causes of why so many product efforts
fail.
I see the same basic way of working at the vast majority of companies,
of every size, in every corner of the globe, and I can't help but
notice that this is not close to how the best companies actually work.
Let me warn you that this discussion can be a little depressing,
especially if it hits too close to home, so if that's the case, I'll
ask you to hang in there with me.
Figure 6.1
describes the process that most companies still use to create products.
I'll try not to editorialize yet---let me first just describe the
process:
<figure"Illustration of Root Causes of Failed Product Efforts."/>
As you can see, everything starts with ideas. In most companies,
they're coming from inside (executives or key stakeholders or business
owners) or outside (current or prospective customers). Wherever the
ideas originate, there are always a whole bunch of things that different
parts of the business need us to do.
Now, most companies  want to
prioritize those ideas into a roadmap, and they do this for two main
reasons. First, they want us to work on the most important things first,
and second, they want to be able to predict when things will be ready.
To accomplish this, there is usually some form of quarterly or annual
planning session in which the leaders consider the ideas and negotiate
a product roadmap. But in order to prioritize, they first need some form
of a business case for each item.
Some companies do formal business cases, and some are informal, but
either way it boils down to the need to know two things about each idea:
(1) How much money or value will it make? and (2) How much money or time
will it cost? This information is then used to come up with the roadmap,
usually for the next quarter, but sometimes as much as a year out.
At this point, the product and technology organization has its marching
orders, and they typically work the items from the highest priority on
down.
Once an idea makes it to the top of the list, the first thing that's
done is for a product manager to talk to the stakeholders to flesh out
the idea and to come up with a set of "requirements."
These requirements might be user stories, or they might be more like
some form of a functional specification. Their purpose is to communicate
with the designers and engineers what needs to be built.
Once the requirements are gathered up, the user experience design team
(assuming the company has such a team), is asked to provide the
interaction design, the visual design, and, in cases of physical
devices, the industrial design.
Finally, the requirements and design specs make it to engineers. This
is usually where Agile
finally enters the picture.
Anyway, the engineers will typically break up the work into a set of
iterations---called "sprints" in the Scrum process. So maybe it takes
one to three sprints to build out the idea.
Hopefully the QA testing is part of those sprints, but if not, the QA
team will follow this up with some testing to make sure the new idea
works as advertised and doesn't introduce other problems (known as
regressions).
Once we get the green light from QA, the new idea is finally deployed
to actual customers.
In the majority of companies that I first meet, large and small, this is
essentially how they work, and have worked, for many years. Yet these
same companies consistently complain about the lack of innovation and
the very long time it takes to make it from idea to customers' hands.
You might recognize that while I mentioned Agile, and while almost
everyone today claims to be Agile, what I've just described is very
much a waterfall process. In fairness to the engineers, they're
typically doing about as much Agile as they can, given the broader
waterfall context.
Okay, so that may be what most teams do, but why is that necessarily the
reason for so many problems? Let's connect the dots now, so we can
clearly see why this very common way of working is responsible for most
failed product efforts.
In the list that follows, I'm going to share what I consider to be the
top-10 biggest problems with this way of working. Keep in mind that all
10 of these problems are very serious issues, any one of which could
derail a team. But many companies have more than one or even all of
these problems.


[CHAPTER 6][The Root Causes of Failed Product Efforts]


It's not intentional, of course, but once companies reach this
size---often becoming a publicly traded company---there are a tremendous
number of stakeholders throughout the business working hard to protect
what  the company has
created. Unfortunately, this often means shutting down new initiatives
or ventures that could re-create the business (but potentially put the
core business at risk), or putting up so many obstacles to new ideas
that few people are willing or able to drive the company in a new
direction.
The symptoms of this are hard to miss, starting with diminished morale,
the lack of innovation, and how much slower it is for new product work
to get into the hands of customers.
When the company was young, it likely had a clear and compelling vision.
When it achieves enterprise stage, however, the company has largely
achieved that original vision and now people aren't sure what's next.
Product teams complain about the lack of vision, lack of empowerment,
the fact that it takes forever to get a decision made, and product work
is turning into design by committee.
Leadership is likely frustrated, too, with the lack of innovation from
the product teams. All too often, they resort to acquisitions or
creating separate "innovation centers" to incubate new businesses in a
protected environment. Yet this rarely results in the innovation
they're so desperate for.
And you'll also hear lots of talk about how it is that large,
enterprise companies such as Adobe, Amazon, Apple, Facebook, Google, and
Netflix have been able to avoid this fate. The organization's
leadership team wonders why they can't do the same. The fact is they
could do the same. But they'll need to make some pretty big changes,
and that's what this book is about.


Strong tech-product companies know they need to ensure consistent
product innovation.


For those companies that succeed in scaling and that want to create a
lasting business, some of the toughest challenges still lie ahead.
Strong tech-product companies know they need to ensure consistent
product innovation. This means constantly creating new value for their
customers and for their business. Not just tweaking and optimizing
existing products (referred to as value capture) but, rather, developing
each product to reach its full potential.
Yet, many large, enterprise companies have already embarked on a slow
death spiral. They become all about leveraging the value and the brand
that was created many years or even decades earlier. The death of an
enterprise company rarely happens overnight, and a large company can
stay afloat for many years. But, make no mistake about it, the
organization is sinking, and the end state is all but certain.


[CHAPTER 5][Enterprise Companies: Consistent Product Innovation]


Sales and marketing often complain that the go-to-market strategies that worked for the first
product are not so appropriate for some of the new products in the
portfolio.
The technology infrastructure that was created to meet the needs of the
initial product is often bursting at the seams, and you start to hear
the term "technical debt" from every engineer you speak with.
This stage is also tough on leaders because the leadership style and
mechanisms that worked while the company was a young startup often fail
to scale. Leaders are forced to change their roles and, in many cases,
their behaviors.
But the motivation to overcome these challenges is very strong. The
company is often in pursuit of a public offering or, perhaps, becoming a
major business unit of an existing company. As well as the very real
possibility of having a significant and positive impact on the world can
be very motivating.


While it's an extremely difficult challenge, it is, as we say, a good
problem to have.


Those startups skilled and fortunate enough (it usually takes both) to
get to product/market fit are ready to tackle another equally difficult
challenge: how to effectively grow and scale.
There are many very significant challenges involved in growing and
scaling a startup into a large, successful business. While it's an
extremely difficult challenge, it is, as we say, a good problem to have.
In addition to hiring lots more people, we need to figure out how to
replicate our earlier successes with new, adjacent products and
services. At the same time, we need to grow the core business as fast as
possible.
In growth stage, we typically have somewhere between about 25 and
several hundred engineers, so there are many more people around to help,
but the signs of organizational stress are everywhere.
Product teams complain that they don't understand the big
picture---they don't see how their work contributes to the larger
goals, and they're struggling with what it means to be an empowered,
autonomous team.


[CHAPTER 4][Growth-Stage Companies: Scaling to Success]


Working at a startup---racing toward product/market fit---is usually
stressful, exhausting, and risky. But it can also be an amazingly
positive experience, and if things go well, a financially rewarding one
too.


Nothing else much matters until you can come up with a strong product
that meets the needs of an initial market.


In the technology world, we generally have three stages of companies:
startups, growth-stage, and enterprise companies. Let's briefly
consider how we characterize each one of these stages, and the
challenges you are likely to face in each.
I loosely define startup as a new product company that has yet to
achieve product/market fit. Product/market fit is an extremely important
concept that I'll define in the pages that follow, but for now, let's
just say that the startup is still trying to come up with a product that
can power a viable business.
In a startup, the product manager role is usually covered by one of the
co-founders. Typically, there are fewer than 25 engineers, covering a
range of from one product team up to maybe four or five.
The reality of startup life is that you're in a race to achieve
product/market fit before you run out of money. Nothing else much
matters until you can come up with a strong product that meets the needs
of an initial market, so most of the focus of the young company is
necessarily on the product.
Startups usually have  a
limited amount of early funding, intended to determine if the company
can discover and deliver the necessary product. The closer you come to
running out of money, the more frantic the pace and the more desperate
the team and the leadership becomes.
While money and time are typically tight, good startups are optimized to
learn and move quickly, and there's normally very little bureaucracy to
slow them down. Yet the very high failure rate of technology startups is
no secret. The few that succeed are usually those that are really good
at product discovery, which is a major topic of this book.


[CHAPTER 3][Startups: Getting to Product/Market Fit]


Technology-powered  products do
not need to be purely digital. Many of the best examples today are
blends of online and offline experiences---like finding a ride or a room
for the night, getting a home loan, or sending an overnight package.
It's my belief that most products today are transforming into
technology-powered products, and the companies that don't realize
this are rapidly being disrupted. But, again, I'm only focused here on
technology-powered products, and those companies that believe they must
embrace technology and consistently innovate on behalf of their
customers.


My focus is on the unique issues and challenges associated with
building technology-powered products, services, and experiences.


[CHAPTER 2][Technology-Powered Products and Services]
There are many kinds of products out there, but in this book, I
concentrate exclusively on products that are powered by technology.
Some of what we explore in this book may help you if you're building
non-tech products, but there are no guarantees in that case. Frankly,
there are already a wide variety of readily accessible resources for
non-tech products such as most consumer packaged goods, and for product
managers of these non-tech products.
My focus is on the unique issues and challenges associated with building
technology-powered products, services, and experiences.
Some good examples of the sweet spot that we explore are
consumer-service products, such as e-commerce sites or marketplaces
(e.g., Netflix, Airbnb, or Etsy), social media (e.g., Facebook,
LinkedIn, or Twitter), business services (e.g.,
Salesforce.com, Workday, or Workiva), consumer
devices (e.g., Apple, Sonos, or Tesla), and mobile applications (e.g.,
Uber, Audible, or Instagram).


The product  manager role is
usually very much a full-time assignment. I don't personally know many
who are able to do what they need to do in less than 60 hours a week.
It's great if you're a designer or an engineer who also wants to serve
as a product manager---there are some real advantages to that. But
you'll find out pretty quickly that you're taking on an immense amount
of work. If you're up for that, however, the results can be impressive.
A product team is comprised of at least a product manager and usually
somewhere between 2 and 10 engineers. If you're creating a user-facing
product, you would expect to have a product designer on your team as
well.
In this book, we explore the situation wherein you might have to use
engineers or designers in a different location or from an agency or
outsourcing firm. But regardless of how you assemble your team, this job
and this book assume you have a team assigned to work with you to
design, to build, and to deliver a product.


It is my strong belief, and the central concept driving this book, that
behind every great product there is someone---usually someone behind the
scenes, working tirelessly---who led the product team to combine
technology and design to solve real customer problems in a way that met
the needs of the business.


It is my strong belief, and the central concept driving this book, that
behind every great product there is someone---usually someone behind the
scenes, working tirelessly---who led the product team to combine
technology and design to solve real customer problems in a way that met
the needs of the business.
These people usually have the title product manager, but they might be
a startup co-founder or CEO, or they might be someone in another role on
the team who stepped up because they saw the need.
Further, this product management role is very distinct from the design,
engineering, marketing, or project manager roles.
This book is intended for these people.
Within modern technology product teams, the product manager has some
very specific and very challenging responsibilities. It's a
tremendously difficult job, and anyone who tries to tell you otherwise
is not doing you any favors.


[CHAPTER 1][Behind Every Great Product]


I realized that the state of the art was very different from the state
of the practice.
Most companies were still using old and inefficient ways to discover and
deliver products. I also learned that there was precious little help
available, either from academia, including the best business school
programs, or from industry organizations, which seemed hopelessly stuck
in the failed models of the past---just like the one I worked in at HP.
I have had some great rides, and I am especially thankful that I have had the chance to work
for and with some of the best product minds in the industry. The best
ideas in this book are from these people. You will find a list of many
of them in the acknowledgments. I have learned from them all, and I am
grateful to each one of them.
I chose this career because I wanted to work on products that customers
love---products that inspire and provide real value. I find that most
product leaders also want to create inspiring and successful products.
But most products are not inspiring, and life is too short for bad
products.
My hope in writing this  book
is that it will help share the best practices of the most successful
product companies and that the result will be truly inspiring
products---products that customers love.


I discovered that there was a tremendous difference between how the
best companies produced products and how most companies produced
them.


In the mid-1980s, I was a young software engineer working for Hewlett
Packard on a high-profile product. It was a time (the first time) when
artificial intelligence was all the rage, and I was fortunate enough to
be working at what was then one of the industry's best technology
companies, as part of a very strong software engineering team (several
members of that team went on to substantial success in companies across
the industry).
Our assignment was a difficult one: to deliver AI-enabling technology on
a low-cost, general-purpose workstation that, until then, required a
special-purpose hardware/software combination that cost more than
$100,000 per user---a price few could afford.
We worked long and hard for well over a year, sacrificing countless
nights and weekends. Along the way, we added several patents to HP's
portfolio. We developed the software to meet HP's exacting quality
standards. We internationalized the product and localized it for several
languages. We trained the sales force. We previewed our technology with
the press and received excellent reviews. We were ready. We released. We
celebrated the release.
Just one problem: No one bought it.
The product was a complete failure in the marketplace. Yes, it was
technically impressive, and the reviewers loved it, but it wasn't
something people wanted or needed.
The team was of course extremely frustrated with this outcome. But soon
we began to ask ourselves some very important questions: Who decides
what products we should build? How do they decide? How do they know that
what we build will be useful?
Our young team learned something very profound---something many teams
have discovered the hard way: It doesn't matter how good your
engineering team is if they are not given something worthwhile to
build.
When trying to track down the
root cause of our failure, I learned that the decisions about what to
build came from a product manager---someone who generally resided in the
marketing organization and who was responsible for defining the products
we built. But I also learned that product management wasn't something
HP was particularly good at. I later learned that most companies
weren't good at this either, and, in fact, most still aren't.
I promised myself that never again would I work so hard on a product
unless I knew the product would be something that users and customers
wanted.
Over the next 30 years, I have had the very good fortune to work on some
of the most successful high-tech products of our time---first at HP
during the rise of personal computers; then at Netscape Communications
during the rise of the Internet, where I worked as vice president of
platform and tools; later at eBay during the rise of e-commerce and
marketplaces, where I served as the senior vice president of product and
design; and then as an adviser to startups working with many of what
have become today's most successful technology product companies.
Not every product effort has been as successful as others, but I am
happy to say that none were failures, and several became loved and used
by millions of people around the world.
Soon after I left eBay, I started getting calls from product
organizations wanting to improve how they produced products. As I began
working with these companies, I discovered that there was a tremendous
difference between how the best companies produced products and how
most companies produced them.


[PART I] [Lessons from Top Tech Companies]


When I first considered publishing an update to the first edition of my
book INSPIRED, I estimated that maybe I would modify something like
10--20 percent of the content. That's because there was very little of
the first edition that I wished I could change.
However, once I got started, I quickly realized that this second edition
would require a complete rewrite. Not because I regretted what I had
written, but because I believe I have much better ways of explaining
these topics now.
I had no idea that the first edition would be as successful as it has
been. Thanks to the book, I have made friends all over the globe. The
book has been translated into several languages, and despite being
nearly 10 years old as of this writing, sales continues to grow, all by
word of mouth and reviews.
So, if you have read the first edition, I thank you, and hope you enjoy
the second edition even more. If you are new to INSPIRED, I am hoping
this new edition accomplishes its objective even better.
When I wrote the first edition, it was before Agile was well established
in product companies, and before Customer Development and Lean Startup
nomenclature became popularized. Today, most teams have been using these
techniques for several years and are more interested in what's beyond
Lean and Agile, which is what I focus on here.
I have kept the basic structure of the book intact, but the techniques I
describe have improved significantly over the past decade.
Beyond changing how I explain the topics and updating the techniques,
the other major change to the book is that I now go into detail on what
I refer to here as Product @ Scale.
In the first edition, I focused more on startups. In this edition,
however, I wanted to expand the scope to look at the challenges of
growth-stage companies and how product can be done well at large,
enterprise companies.
There's no question that scale introduces serious challenges, and over
the past decade, much of my time has been spent coaching companies
through rapid growth. Sometimes we call that surviving success, if that
gives you an indication of how hard it can be.
I've received a lot of great feedback from readers of the first
edition, and there are a couple of important things I've learned that I
would like to address here.
First, there really is a critical need to focus on the specific job of the product
manager. In the first edition, I talked a lot about product management,
but I tried to speak to product teams more broadly. Today, there are
many excellent resources for product designers and engineers, but
precious little available specifically for product managers who are
responsible for technology-powered products. So, in this edition I
decided to concentrate on the job of the technology product manager. If
you are a product manager at a technology company, or if you aspire to
be one, I am hoping this will become your go-to resource.
Second, there are many people looking for a recipe for product
success---a prescriptive guide or framework to how to create products
customers love. While I understand the desire, and I know I'd likely
sell many more copies if I positioned this book that way, the
unfortunate truth is that's just not how great products are created. It
is much more about creating the right product culture for success, and
understanding the array of product discovery and delivery techniques so
that you can use the right tool for the specific issue you are facing.
And, yes, this means that the job of the product manager is not in any
sense easy, and truth be told, not everyone is equipped to succeed in
this job.
All that said, the tech product management job is today one of the most
desired jobs in our industry, and is the leading source---the proving
ground---of startup CEOs. So, if you've got the desire and are willing
to put in the effort, I'd like nothing better than to help you succeed.


Preface to the Second Edition


Marty Cagan


The lean startup


My first Workspace