The OKR technique has enjoyed considerable success, especially inside
technology product organizations, from large to small. And there have
been some very important lessons learned as teams and organizations work
to improve their ability to execute.
OKRs are a very general tool that can be used by anyone in the
organization, in any role, or even for your use in your personal life.
However, as with any tool, some ways of applying them are better than
others.
Throughout this book, I emphasize the importance of a product team.
Recall that a product team is a cross-functional set of professionals,
typically comprised of a product manager, a product designer, and a
small number of engineers. In addition, there are sometimes additional
people with specialized skills included on the team, such as a data
analyst, a user researcher, or a test automation engineer.
Also recall that each product team typically is responsible for some
significant part of the company's product offering or technology. For
example, one product team might be responsible for mobile apps for
drivers, another for mobile apps for riders, another might be
responsible for secure payment handling, and so on.
The key is that these people with their different skill sets usually
come from different functional departments in the company, but they sit
and work all day---every day---with their cross-functional team to solve
hard business and technology problems.
It's not unusual in larger organizations to have on the order of 20 to
50 of these cross-functional product teams, each responsible for
different areas, and each product team with its own objectives to work
on.
For companies using the OKR system, the problems these teams are asked
to tackle are, as you might expect, communicated and tracked through the
product team's OKRs. The OKRs also help to ensure that each team is
aligned with the objectives of the company.
Moreover, as an organization scales, OKRs become an increasingly
necessary tool for ensuring that each product team understands how they
are contributing to the greater whole, coordinating work across teams,
and avoiding duplicate
work.
The reason this is so important to understand is that when organizations
first start with OKRs, there's a common tendency to have each
functional department create their own OKRs for their own
organization. For example, the design department might have objectives
related to moving to a responsive design; the engineering department
might have objectives related to improving the scalability and
performance of the architecture; and the quality department might have
objectives relating to the test and release automation.
The problem is that the individual members of each of these functional
departments are the actual members of a cross-functional product team.
The product team has business-related objectives (for example, to reduce
the customer acquisition cost, to increase the number of daily active
users, or to reduce the time to onboard a new customer), but each person
on the team may have their own set of objectives that cascade down
through their functional manager.
Imagine if the engineers were told to spend their time on
re-platforming, the designers on moving to a responsive design, and QA
on retooling. While each of these may be worthy activities, the chances
of solving the business problems that the cross-functional teams were
created to solve are not high.


[CHAPTER 29][Product Team Objectives]


[Senior management (CEO and executive team) is responsible for the organization's
objectives and key results. The heads of product and technology are
responsible for the product team objectives (and ensuring they
deliver on the organization's objectives). The individual
product  teams are
responsible for proposing the key results for each objective
they've been assigned. It is normal to have a give-and-take process
each quarter as the OKRs are finalized for each team and for the
organization.]


[Be very transparent (across the product and technology
organization) on what objectives each product team is working on and
their current progress.]


[Establish very clear and consistent ways to indicate when a key
result is in reality a high-integrity commitment (described
earlier) rather than a normal objective. In other words, for most
key results, you may be shooting for that 0.7 score. But for a
high-integrity commitment, these are special, and it's more binary.
You either delivered what you promised or you
didn't.]


[Agree as an organization on how you will be evaluating or scoring
your key results. There are different approaches to this, and it's
in large part a reflection of your particular company culture.
What's important here is consistency across the organization, so
that teams know when they can depend on one another. It's common to
define a score of 0 (on a scale from 0 to 1.0) if you essentially
make no progress, 0.3 if you just did the bare minimum---what you
know you can achieve, 0.7 if you've accomplished more than the
minimum and have really done what you'd hoped you would achieve,
and 1.0 if you've really surprised yourselves and others with a
truly exceptional result, beyond what people were even hoping
for.]


[It's important that, one way or another, teams feel accountable to
achieving their objectives. If they fail substantially, it's worth
having a post-mortem/retrospective with some of their peers or
management.]


[The objectives do not need to cover every little thing the team
does, but they should cover what the team needs to
accomplish.]


[It's critical that every product team track their active
progress against their objectives (which is typically
weekly).]


[Keep the number of objectives and key results for the organization and for each team
small (one to three objectives, with one to three key results each
is typical).]


Key results should be a measure of business results, not output
or tasks.


[Find a good cadence for your organization (typically, annually for
an organization's objectives and quarterly for a team's
objectives).]


[The rest of the company will use OKRs a bit differently, but for
the product management, design, and technology organization, focus
on the organization's objectives and the objectives for each
product team, which are designed to roll up and achieve the
organization's objectives. Don't let personal objectives or
functional team objectives dilute or confuse the
focus.]


[Key results should be a measure of business results, not output
or tasks.]


[Objectives should be qualitative; key results need to be
quantitative/measurable.]


The Objectives and Key Results (OKR) technique is a tool for management,
focus, and alignment. As with any tool, there are many ways to use it.
Here are the critical points for you to keep in mind when using the tool
for product teams in product organizations.


[CHAPTER 28][The OKR Technique]


While the concept of team objectives might sound straightforward, there
are many ways to institutionalize this across product teams and
organizations, and it can take a few quarters before the organization
finds its groove.


The first principle is fundamentally about how to empower and motivate
people to get them to do their best work, and the second is about how to
meaningfully measure progress.


The first principle is fundamentally about how to empower and motivate
people to get them to do their best work, and the second is about how to
meaningfully measure progress.
So much has changed in our industry over the years, but these two
fundamental management principles are still at the foundation of how the
best tech companies and teams operate.
While there are several
workable systems and tools for managing these business objectives, in
this book, I'll focus on the OKR system technique. Most of the major
successful tech companies have been using it for several years now. It
seems to have hit some sort of tipping point and is now spreading
globally.


[The first can easily be summed up with the famous General George
Patton quote I mentioned earlier: "Never tell people how to do
things. Tell them what to do, and they will surprise you with their
ingenuity."]
[The second was captured by HP's tagline of that era: "When
performance is measured by results." The idea here is that you can
release all the features you want, but if it doesn't solve the
underlying business problem, you haven't really solved
anything.]


Overview
I was extremely fortunate to have started my career at HP as an engineer
during their heyday, when they were known as the industry's most
successful and enduring example of consistent innovation and execution.
As part of HP's internal engineering management training program called
The HP Way, I was introduced to a business objective--based system
known as MBO---management by objectives.
Dave Packard claimed: "No [tool] has contributed more to
Hewlett-Packard's success. [MBO] is the antithesis of management by
control."
The MBO system was refined and improved at several companies over the
years, most notably by the legendary Andy Grove at Intel. Today, the
primary business objective management system we use is known as the OKR
system---objectives and key results.
John Doerr brought the technique from Intel to a very young Google, and
a couple decades after Dave Packard attributed much of HP's success to
MBO, Larry Page said essentially the same thing about the importance of
the OKR process on Google's success.
The concept is straightforward and based on two fundamental principles:


[Product Objectives]


These are what principles are all about. You can imagine how this type
of principle would help with designing and building a marketplace and
how many issues could be resolved by simply keeping it in mind.
Whether you choose to go public with your
principles  depends on your
purpose. In many cases, the principles are simply a tool for the product
teams. But, in other cases, the principles serve as a clear statement of
what you believe---intended for your users, customers, partners,
suppliers, investors, and your employees.


Where the product vision describes the future you want to create, and
the product strategy describes your path to achieving that vision, the
product principles speak to the nature of the products you want to
create.


I always like to complement the product vision and product strategy with
a set of product principles.
Where the product vision describes the future you want to create, and
the product strategy describes your path to achieving that vision, the
product principles speak to the nature of the products you want to
create.
Product principles are not a list of features, and they are not tied to
any one product release. The principles are aligned with the product
vision for an entire product line.
A good set of principles may inspire some product features, but it's
more about what the company and product teams believe is important.
As an example, early on at eBay we found we needed a product principle
that spoke to the relationship between buyers and sellers. Most of the
revenue came from sellers, so we had a strong incentive to find ways to
please sellers, but we soon realized that the real reason sellers loved
us was because we provided them with buyers. This realization led to a
critical principle that stated, "In cases where the needs of the buyers
and the sellers conflict, we will prioritize the needs of the buyer,
because that's actually the most important thing we can do for
sellers."


[CHAPTER 27][Product Principles]


[Communicate the strategy across the organization. This is part
of evangelizing the vision. It's important that all key business
partners in the company know the customers we're focused on now and
which are planned for later. Stay especially closely synced with
sales, marketing, finance, and service.]


[Obsess over customers, not over competitors. Too many companies
completely forget about their product strategy once they encounter a
serious competitor. They panic and then find themselves chasing
their competitor's actions and no longer focusing on their
customers. We can't ignore the market, but remember that customers
rarely leave us  for
our competitors. They leave us because we stop taking care of
them.]


Obsess over customers, not over competitors.


[Product strategy needs to be aligned with sales and go-to-market
strategy. Similarly, if we have a new sales and marketing channel,
we need to ensure that our product strategy is aligned with that new
channel. A new sales channel or go-to-market strategy can have
far-reaching impact on a product.]


[Product strategy needs to be aligned with business strategy.
The vision is meant to inspire the organization, but the
organization ultimately is there to come up with solutions that
deliver on the business strategy. So, for example, if that business
strategy involves a change in monetization strategy or business
model, then the product strategy needs to be aligned with
this.]


[Focus on one target market or persona at a time. Don't try to
please everyone in a single release. Focus on one new target market,
or one new target persona, for each release. You'll find that the
product will still likely be useful to others, but at least it will
be loved by some, and that's key.]


As we discussed previously, there are any number of approaches to
product strategy, but good strategies have these five principles in
common:


[CHAPTER 26][Principles of Product Strategy]


[Evangelize continuously and relentlessly. There is no such
thing as over-communicating when it comes to explaining and selling
the vision. Especially in larger organizations, there is simply no
escaping the need for near-constant evangelization. You'll find
that people in all corners of the company will at random times get
nervous or scared about something they see or hear. Quickly reassure
them before  their fear
infects others.]


Be stubborn on vision but flexible on the details.


[Realize that any product vision is a leap of faith. If you
could truly validate a vision, then your vision prob ably isn't
ambitious enough. It will take several years to know. So, make sure
what you're working on is meaningful, and recruit people to the
product teams who also feel passionate about this problem and then
be willing  to work for
several years to realize the vision.]


[Be stubborn on vision but flexible on the details. This Jeff
Bezos line is very important. So many teams give up on their product
vision far too soon. This is usually called a vision pivot, but
mostly it's a sign of a weak product organization. It is never
easy, so prepare yourself for that. But, also be careful you don't
get attached to details. It is very possible that you may have to
adjust course to reach your desired destination. That's called a
discovery pivot, and there's nothing wrong with
that.]


[Skate to where the puck is heading, not to where it was. An
important element to product vision is identifying the things that
are changing---as  well
as the things that likely won't be changing---in the time frame of
the product vision. Some product visions are wildly optimistic and
unrealistic about how fast things will change, and others are far
too conservative. This is usually the most difficult aspect of a
good product vision.]


[Determine and embrace relevant and meaningful trends. Too many
companies ignore important trends for far too long. It is not very
hard to identify the important trends. What's hard is to help the
organization understand how those trends can be leveraged by your
products to solve customer problems in new and better
ways.]


[The product vision needs to inspire. Remember that we need
product teams of missionaries, not mercenaries. More than anything
else, it is the product vision that will inspire missionary-like
passion in the organization. Create something you can get excited
about. You can make any product vision meaningful if you focus on
how you genuinely help your users and
customers.]


Fall in love with the problem, not with the solution.


[Don't be afraid to disrupt yourselves because, if you don't,
someone else will. So many companies focus their efforts on
protecting what they have rather than constantly creating new value
for their customers.]


[Don't be afraid to think big with vision. Too often I see
product visions that are not nearly ambitious enough, the kind of
thing we can pull off in six months to a year or so, and not
substantial enough to inspire anyone.]


[Fall in love with the problem, not with the solution. I hope
you've heard this before, as it's been said many times, in many
ways, by many people. But it's very true and something a great many
product people struggle with.]


[Start with why. This is coincidentally the name of a great
book on the value of product vision by Simon Sinek. The central
notion here is to use the product vision to articulate your
purpose. Everything follows from that.]


These are the 10 key principles for coming up with an effective product
vision.


[CHAPTER 25][Principles of Product Vision]


These are typically the three dominant factors for prioritizing your markets, but others
can be important also. I typically suggest that the head of product,
head of technology, and head of product marketing sit down together to
work  out your product
strategy, balancing these various factors.


[The first is market sizing, usually referred to as total
addressable market (TAM). All things considered equal, we like big
markets rather than small markets. But, of course, they're not
equal. If the largest market would require two years of product
work, yet several of the somewhat smaller but still significant
markets are much closer in terms of time to market, most likely
everyone in your company from the CEO and head of sales on down
would prefer you to deliver on a smaller market
sooner.]
[The second factor concerns distribution, usually referred to as go
to market (GTM). Different markets may require different sales
channels and go-to-market strategies. Again, even if the market is
larger, if that market would require a new sales channel, then most
likely we would all prioritize a somewhat smaller market that can
leverage our existing sales channels.]
[The third factor is a (very rough) estimation of how long it will
take, referred to as time to market
(TTM).]


Prioritizing Markets
In terms of prioritizing markets, all I said above was to prioritize
your markets and focus on them one at a time. I didn't say how to
prioritize them. There is no one right way to do this, but there are
three critical inputs to your decision:


Let's get back to the concept of providing context to the product
teams.
For a product team to be empowered and act with any meaningful degree of
autonomy, the team must have a deep understanding of the broader
context. This starts with a clear and compelling product vision, and
the path to achieving that vision is the product strategy.
The more product teams you have, the more essential it is to have this
unifying vision and strategy for each team to be able to make good
choices.
And, just to be clear---the idea is not that every product team has its
own product vision. That would miss the point. The idea is that our
organization has a product vision, and all the product teams in that
organization are helping to contribute to making that vision a reality.
Of course, in very large organizations, while the mission statement
might apply to the full company, it's likely that each business unit would have its own product
vision and strategy.
The difference between vision and strategy is analogous to the
difference between good leadership and good management. Leadership
inspires and sets the direction, and management helps get us there.
Most important, the product vision should be inspiring, and the
product strategy should be focused.


The difference between vision and strategy is analogous to the
difference between good leadership and good management. Leadership
inspires and sets the direction, and management helps get us there.


For consumer-focused companies, we often structure each product/market
fit around a different customer or user persona. For example, an
education-related service might have a strategy that targets high school
students first, college students next, and then those already working
but who want to learn new skills.
Sometimes, the product strategy is based on geography, where we tackle
different regions of the world in an intentional sequence.
And, sometimes, the product strategy is based on achieving a set of key
milestones in some sort of logical and important order. For example,
"First deliver critical rating and reviews functionality to developers
building e-commerce applications; next, leverage the data generated from
this use to create a database of consumer product sentiment; and then
leverage these data for advanced product recommendations."
There's no single approach to product strategy that is ideal for everyone, and you can
never know how things might have gone if you sequenced your product work
differently. I tell teams that the most important benefit is just that
you decided to focus your product work on a single target market at a
time. So, all teams know we're tackling the manufacturing market now,
and that's the type of customers we are obsessing on. Our goal is to
come up with the smallest actual deliverable product that makes these
manufacturing customers successful. Ideas that come up that pertain to
other types of customers or markets are saved for future consideration.
Besides significantly increasing your chance of delivering something
that can power your business, the product strategy now gives you a tool
to align your product work with your sales and marketing organizations.
We want the sales organization to sell in the markets where we've
demonstrated product/market fit. As soon as we demonstrate
product/market fit for a new market (usually by developing an initial
set of reference customers), we want the sales force to go out and find
as many additional customers in that market as possible.


There's no single approach to product strategy that is ideal for
everyone, and you can never know how things might have gone if you
sequenced your product work differently. I tell teams that the most
important benefit is just that you decided to focus your product work on
a single target market at a time.


When done well, the product vision is one of our most effective
recruiting tools, and it serves to motivate the people on your teams to
come to work every day. Strong technology people are drawn to an
inspiring vision---they want to work on something meaningful.
You can do some amount of testing of the vision, but it's not the same
as the testing of specific solutions we do in product discovery. In
truth, buying into a vision is always a bit of a leap of faith. You
likely don't know how, or even if, you'll be able to deliver on the
vision. But remember you have several years to discover the solutions.
At this stage, you should believe it's a worthwhile pursuit.
The Product Strategy
One of the most basic of all product lessons learned is that trying to
please everybody at once will almost certainly please nobody. So, the
last thing we should do is embark on a ginormous, multi-year effort to
create a release that tries to deliver on the product vision.
The product strategy is our sequence of products or releases we plan
to deliver on the path to realizing the product vision.
I'm using the phrase "products or releases" here loosely. It might be
different versions of the same product, a series of different or related
products, or some other set of meaningful milestones.
For most types of businesses, I encourage teams to construct product
strategy around a series of product/market fits. There are many
variations on this (the strategy for the product strategy, if you will).
For business-focused companies, you might have each product/market fit
focus on a different vertical market (e.g., financial services,
manufacturing, automotive).


Its primary purpose is to communicate this vision and inspire the teams
to want to help make this vision a reality.


The Product Vision
The product vision describes the future we are trying to create,
typically somewhere between two and five years out. For hardware or
device-centric companies, it's usually five to 10 years out.
Note that this is not the same as the company mission statement.
Examples of mission statements are "organize the world's information"
or "make the world more open and connected" or "enable anyone anywhere
to buy anything anytime." Mission statements are useful, but they don't
say anything about how we plan on accomplishing that. That's what the
product vision is for.
Note also that the vision is not in any sense a spec. It's mainly a
persuasive piece that might be in the form of a storyboard, a
narrative such as a white paper, or a special type of prototype referred
to as a visiontype.
Its primary purpose is to communicate this vision and inspire the teams
(and stakeholders, investors, partners---and, in many cases, prospective
customers) to want to help make this vision a reality.


[CHAPTER 24][Product Vision and Product Strategy]


Overview
In this section, I discuss the importance of a compelling and inspiring
product vision, and how critical the role of product strategy is in
delivering on the product
vision.


[Product Vision]


So, what to do?
The key is to  understand
that the root cause of all this grief about commitments is when these
commitments are made. They are made too early. They are made before we
know whether we can deliver on this obligation, and even more important,
whether what we deliver will solve the problem for the customer.
In the continuous discovery and delivery model, the discovery work is
all about answering these questions before we spend the time and money
to build production-quality products.
So, the way we manage commitments is with a little bit of give and take.
We ask the executives and our other stakeholders to give us a little
time in product discovery to investigate the necessary solution. We need
the time to validate that solution with customers to ensure it has the
necessary value and usability, with engineers to ensure its feasibility,
and with our stakeholders to ensure it is viable for our business.
Once we have come up with a solution that works for our business, we now
can make an informed and high-integrity commitment about when we can
deliver and what business results we can expect.
Note that our delivery managers are key to determining any commitment
dates. Just because your engineers believe something might take only two
weeks to build and deliver, what if that team is already occupied on
other work, and they can't start on this work for another month? The
delivery managers track these commitments and dependencies.
So, the compromise is straightforward. The product team asks for a
little time to do product discovery before commitments are made, and
then after discovery, we are willing to commit to dates and deliverables
so our colleagues can effectively do their jobs as well.
Again, in good companies these types of commitments are minimized, but
there are always  some.
It's important for the organization to get comfortable with making
these high-integrity commitments and explain to the company that, while
they are not something we do frequently, when we do them, they can
depend on the product team delivering on these commitments.


It's a constant struggle between those executives and stakeholders who
are trying to run the business and the product team that is
understandably reluctant to commit to dates and deliverables.


High-Integrity Commitments
In most Agile teams, when you even mention the word "commitments" (like
knowing what you're going to launch and when it will happen), you get
reactions ranging from squirming to denial.
It's a constant struggle between those executives and stakeholders who
are trying to run the business (with hiring plans, marketing program
spend, partnerships, and contracts depending on specific dates and
deliverables) and the product team that is understandably reluctant to
commit to dates and deliverables. They're reluctant when they don't
yet understand what they need to deliver, and if it will work in terms
of delivering the necessary business results, in addition to not knowing
how much it will really cost because they don't yet know the solution.
Underlying all of this is the hard-learned lessons of product teams that
many of the ideas won't work as we hope and those that could work will
typically take several iterations to get to the point where they move
the needle enough to be considered a business success.
In a custom software environment, you might just be able to iterate
until the business is satisfied with the software (or they just give up
on it). In a product company, this won't fly.
Now don't get me wrong---you've just heard how I feel about the perils
of conventional roadmaps. Good product companies minimize these
commitments. But there are always some real commitments that need to be
made in order to effectively run a company.


It is all about outcome rather than output.
There are a few product teams out there that have modified their product
roadmaps so that each item is stated as a business problem to solve
rather than the feature or project that may or may not solve it. These
are called outcome-based roadmaps.
In general, when I see these, I'm pretty happy because I know the
product teams are stepping up to solve business problems rather than
build features. Outcome-based roadmaps are essentially equivalent to
using a business objective--based system such as the OKR system. It's
the format that's different more than the content.
There is a tendency,
however, with outcome-based roadmaps to put a deadline date on every
item, rather than only on the items with a true date constraint. This
practice can have cultural and motivation implications to the team.


[First, the teams are much more motivated when they are free to
solve the problem the best way they see fit. It's the missionary
versus mercenary thing again. Moreover, the teams are designed to be
in the best position to solve these
problems.]
[Second, the team is not off the hook just by delivering a requested
feature or project. The feature must solve the business problem
(as measured by the key results); otherwise, the team needs to try a
different approach to the solution.]
[Third, no matter where the idea for the solution comes from, or how
smart that person is, very often the initial approach doesn't work
out. Rather than pretending this is not the case, this model
embraces that likelihood.]


Earlier, I said we needed to acknowledge the two drivers for old-style
roadmaps, and  the first
driver is the desire to work on the highest business value items first.
In the model I'm describing, it is management's responsibility to
provide each product team with the specific business objectives they
need to tackle. The difference is that they are now prioritizing
business results, rather than product ideas. And, yes, it is more than
a little ironic that we sometimes need to convince management to focus
on business results.
The second driver is the occasional need for committing to a hard date.
We address this with the concept of high-integrity commitments, used
for those situations where we need to commit to a date or a specific
deliverable.
There are several benefits to this way of working:


It is management's responsibility to provide each product team with
the specific business objectives they need to tackle.


The idea behind business objectives is simple enough: tell the team what
you need them to accomplish and how the results will be measured, and
let the team figure out the best way to solve the problems.
Consider this example of a business objective and a measurable, key
result. Suppose your product currently requires 30 days for a new
customer to onboard. But in order to scale effectively, management
believes this needs to be reduced to three hours or less.
That's a good example of a business objective for one or more product
teams: "Dramatically reduce the time it takes for a new customer to go
live." And one of the measurable key results would be "Average new
customer onboarding time less than three hours."
I'll describe much more about product vision and strategy---and
business objectives---in the upcoming chapters. But for now I want to
emphasize how important it is for each and every product team to know
how their work contributes to the larger whole and what the company
needs them to focus on right now.


[The product vision and strategy. This describes the big picture
of what the organization as a whole is trying to accomplish and what
the plan is for achieving that vision. Each of our product teams may
have its own areas of focus (for example, buyer teams and seller
teams), but it's all supposed to come together to achieve the
product vision.]
[The business objectives. This describes the specific,
prioritized business objectives for each product
team.]


So, to be accepted in most companies, any alternative approach to
roadmaps must address these needs at least as well as they are addressed
today.
In the empowered product team model this book is predicated on, the
teams are themselves equipped to figure out the best ways to solve the
particular business problems assigned to them. But for this to happen,
it's not enough to have
strong people equipped with modern tools and techniques. The product
teams need to have the necessary business context. They need to have a
solid understanding of where the company is heading, and they need to
know how their particular team is supposed to contribute to the larger
purpose.
For technology companies, there are two main components that provide
this business context:


[The first purpose is because the management of the company wants to
make sure that teams are working on the highest-business-value items
first.]
[The second purpose is because---since they're trying to run a
business---there are cases where they need to make date-based
commitments, and the roadmap is where they see and track those
commitments (even though in most companies, they rarely trust the
dates anymore).]


In this chapter, I describe the alternative to product roadmaps. It's a
big topic, and it touches on issues beyond product roadmaps, such as
product culture, morale, empowerment, autonomy, and innovation. But my
hope is to lay the foundation here and provide the details in the
chapters that follow.
Before we jump into the alternative, however, we need to remind
ourselves that roadmaps have existed for so long because they serve two
purposes, and these needs don't go away:


[CHAPTER 23][The Alternative to Roadmaps]


And, sometimes the issue is that we encounter serious legal, financial,
or business constraints that block the solution from launch (the
business viability isn't there).
If that's not bad enough, the second inconvenient truth is that, even
with the ideas that do prove to be valuable, usable, feasible, and
viable, it typically takes several iterations to get the execution of
this idea to the point where it delivers the expected business value
that management was hoping for. This is often referred to as time to
money.
In my experience, there simply is no escaping these inconvenient truths.
And I've had the opportunity to work with many truly exceptional
product teams. The difference is how product teams deal with these
truths.
Weak teams just plod through the roadmap they've been assigned, month
after month. And, when something doesn't work---which is often---first
they blame it on the stakeholder that requested/demanded the feature and
then they try to schedule another iteration on the roadmap, or they
suggest a redesign or a different set of features that this time they
hope will solve  the
problem.
If they have enough time and money, they can eventually get there so
long as management doesn't run out of patience first (a big if).
In contrast, strong product teams understand these truths and embrace
them rather than deny them. They are very good at quickly tackling the
risks (no matter where that idea originated) and are fast at iterating
to an effective solution. This is what product discovery is all about,
and it is why I view product discovery as the most important core
competency of a product organization.
If we can prototype and test ideas with users, customers, engineers, and
business stakeholders in hours and days---rather than in weeks and
months---it changes the dynamics, and most important, the results.
It's worth pointing out that it isn't the list of ideas on the roadmap
that's the problem. If it was just ideas, there's not much harm in
that. The issue is that anytime you put a list of ideas on a document
entitled "roadmap," no matter how many disclaimers you put on it, people
across the company will interpret the items as a commitment. And that's
the crux of the problem,
because now you're committed to building and delivering this thing,
even when it doesn't solve the underlying problem.
Don't misinterpret this. Sometimes, we do need to commit to a delivery
on a date. We try to minimize those cases, but there are always some.
But we need to make what is called a high-integrity commitment. This
will be discussed in detail later, but the key takeaway here is that we need to solve
the underlying problem, not just deliver a feature.


The issue is that anytime you put a list of ideas on a document
entitled "roadmap," no matter how many disclaimers you put on it, people
across the company will interpret the items as a commitment.


Even with the best of intentions, product roadmaps typically lead to
very poor business results. I refer to the reasons for this as the two
inconvenient truths about product.
The first inconvenient truth is that at least half of our product ideas
are just not going to work. There are many reasons for a product idea to
not pan out.
Sometimes customers just aren't as excited about this idea as we are,
so they choose not to use it or buy it (the value isn't there). This
is the most common situation.
Sometimes they do want to use it, and they try to use it, but it's so
complicated that it's simply more trouble than it's worth, which
yields the same result---the users don't use it (the usability isn't
there).
Sometimes the issue is that the customers might have loved it, but it
turns out to be much more involved to build than we first thought, and
we simply can't afford the time and cost to deliver (the feasibility
isn't there).


[CHAPTER 22][The Problems with Product Roadmaps]


These are reasonable
desires. Yet, typical roadmaps are the root cause of most waste and
failed efforts in product organizations.
Let's explore why product roadmaps are such a problem, and then let's
consider the alternatives.


[First, they want to be sure you're working on the highest-value
things first.]
[Second, they are trying to run a business, which means they need to
be able to plan. They
want to know when key capabilities will launch so they can
coordinate marketing programs, sales force hiring, dependencies with
partners, and so on.]


Management has fair reasons for wanting product roadmaps:


Typical roadmaps are the root cause of most waste and failed efforts in
product organizations.


[Product Roadmaps]
Overview
Now that we've got some strong product teams, we need to answer this
fundamental question: What should our product team work on?
For most companies (especially those described in Chapter
6, "The Root Causes of Failed Product Efforts"), that's
not a question the teams have to worry much about because they are
usually handed down the things to work on in the form of a product
roadmap.
One of the key themes of this book is focusing on outcome and not
output. Realize that typical product roadmaps are all about output.
Yet, good teams are asked to deliver business results.
Most of the product world has the same definition for product roadmap,
but there are a few variations. I define product roadmap as a
prioritized list of features and projects your team has been asked to
work on. These product roadmaps are usually done on a quarterly basis,
but sometimes they are a rolling three months, and some companies do
annual roadmaps.
In some cases, product roadmaps come down from management (usually
referred to as a stakeholder-driven roadmap) and sometimes the roadmap
comes from the product manager. They don't usually include little
things like bugs and optimizations, but they do normally contain the
requested features, projects, and big, multi-team efforts often called
initiatives. And they typically include due dates or at least time
frames for when each item is expected to be delivered.
Management knows that many parts of the company need things from the
product organization; yet, we are rarely staffed to be able to do
everything that's needed. So, management may help mediate this battle
over the constrained resources. That's where stakeholder-driven
roadmaps are especially common.


[PART III] [The Right Product]
In Part Two, we considered the people---looking at the
structure and roles of strong product teams. In Part
Three, we explore how to determine what the product team
should be working on.


But Lea knew the market was changing, and the company needed to move
from the old desktop-centric, annual-upgrade model, to a
subscription-based model supporting all the devices designers were now
using---including tablets and mobile in all their many form factors.
More generally, Lea knew that the upgrade model was pushing the company
to take the product in directions that were not good for Adobe customers
and not good in the long term for Adobe. But change of this
magnitude---revenue from Creative Suite was roughly half of Adobe's
overall $4 billion in annual revenue---is brutally hard.
Realize that every bone and muscle in the corporate body works to
protect that revenue, and so a transition of this magnitude means
pushing the company far outside it's comfort zone. Finance, legal,
marketing, sales, technology---few in the company would be left
untouched.
You can start with the typical concerns:
The finance staff was very worried about the revenue consequences of
moving from a license model to a subscription model.
The engineering teams were worried about moving from a two-year release
train model to continuous development and deployment, especially while
assuring quality. They were also concerned that responsibility for
service availability was now going to be much higher.
The sales side expected that this transition would change the way the
Creative Suite products were sold. Rather than a large reseller channel,
Adobe would now have a direct relationship with their customers. While
many people at Adobe generally looked forward to this change, the sales
organization knew that this was risky because if things didn't work out
well, the channels would probably not be forgiving.
And don't underestimate the emotional changes---to both customers and
sales staff---of moving from owning software to renting access to
software.
With more than a million customers of the existing Creative Suite, Lea
understood the technology adoption curve and that a segment of the
customer base would strongly resist a change of this magnitude. Lea
understood that it's not just about whether the new Creative Cloud
would be better, it would also be different in some meaningful ways.
Some people would need more time to digest this change than others.
Realize also that the Creative Suite is, as the name implies, a suite
of integration applications---15 major ones and many smaller utilities.
So, this meant that not just one product had to transform, but the full
suite needed to transform, which dramatically increased the risk and
complexity. It is any wonder that few companies are willing to tackle a
product transformation of this magnitude?
Lea knew she had a tough job in front of her and her teams. She realized
that, for all of these interrelated pieces to be able to move together
in parallel, she needed to articulate clearly a compelling vision of the
new whole as greater than the sum of the parts.
Lea worked with Adobe's
then-CTO, Kevin Lynch, to put together some compelling prototypes
showing the power of this new foundation and used this to rally
executives and product teams.
Lea then began a sustained and exhausting campaign to communicate
continuously with leaders and stakeholders across the entire company. To
Lea, there was no such thing as over-communication. A continuous stream
of prototypes helped keep people excited about what this new future
would bring.
Because of the tremendous success of the Creative Cloud---as of this
writing, Adobe generated more than $1 billion in recurring revenue
faster than anyone else has---Adobe discontinued new releases of the
desktop-based Creative Suite to focus their innovation on the new
foundation. Today, more than 9 million creative professionals subscribe
to, and depend on, the Creative Cloud. Thanks, in large part to this
transition, Adobe has more than tripled the market cap it had before
the transition. The company today is worth roughly $60 billion.
It's easy to see how big companies with lots of revenue at risk would
hesitate to make the changes they need to not only survive but thrive.
Lea tackled these concerns and more head-on with a clear and compelling
vision and strategy and clear and continuous communication to the many
stakeholders.
This is one of the most impressive, nearly superhuman examples I know of
a product leader driving massive and meaningful change in a large
enterprise company. There's no question in my mind that Adobe would not
be where it is today without someone like Lea working tirelessly to
drive this change through.
And I'm very happy to say
that today Lea is a partner at Silicon Valley Product Group, helping
other organizations through the transformation to modern product
practices.


One of the absolute hardest assignments in our industry is to try to
cause dramatic change in a large and financially successful company.


For startups or smaller companies, often all it takes is a strong
product team with a strong product-oriented CEO or product manager. But,
in larger companies, it usually takes more than that. It takes strong
product leadership, in the very best sense of the word, including
providing a compelling product vision and strategy.
One of the absolute hardest assignments in our industry is to try to
cause dramatic change in a large and financially successful company.
It's easier in many ways if the company is in serious trouble, and it
is feeling big pain, because that pain can be used to motivate the
change.
Of course, great companies want to disrupt themselves before others
disrupt them. The difference between Amazon, Netflix, Google, Facebook,
and the legions of large but slowly dying companies is usually exactly
that: product leadership.
In 2011, Lea Hickman led product for Adobe's Creative Suite. Lea had
spent several years at Adobe helping them to build a very large and
successful business for itself---on the order of $2 billion in annual
license revenue---with its desktop-based Creative Suite.


[CHAPTER 21][Profile: Lea Hickman of Adobe]


We will discuss both of these key topics in the coming chapters.
Problems arise if the leadership does not provide clarity on these two
critical pieces of context. If they don't, there's a vacuum, and that
leads to real ambiguity over what a team can decide and what they
can't.
Note that while the product vision and the team-specific business
objectives are provided to the team by leadership as part of the
context, nothing is said about how to actually solve the problems they
are assigned. That's where the team has the autonomy and flexibility.


[The overall product vision]
[The specific business objectives assigned to each team]


In general, most teams would probably agree that there are some things
that are wide open for the team to do as they think best and other areas
that are part of the common foundation that all teams share.
As an example of the latter, it would be unusual for each team to select
its own software configuration management tool. If the engineering team
has standardized on GitHub, then that is usually considered part of the
foundation. Even if one team had a strong preference for a different
tool, the total cost to the organization of allowing its use would
likely far outweigh any benefits.
While this might be a straightforward example, there are many others
that are not so clear.
For example, should each team be able to approach test automation in its
own way? Should teams be able to select the programming languages they
wish to use? What about user interface frameworks? What about browser
compatibility? How about expensive features like offline support? How
about the flavor of Agile they wish to use? And does every team really
need to support several company-wide product initiatives?
As is so often the  case with
product, things boil down to a tradeoff---in this case between the
team's autonomy and leverage of the foundation.
I will also confess here that, while I love the core notion of
autonomous, empowered teams, I am also a big fan of investing in a
high-leverage foundation. This means building a strong foundation that
all teams can leverage to create amazing products and experiences much
faster than they would otherwise.
For the record, I do not believe that there is one answer to this
question. The best answer is different for each company, and even for
each team, and the best answer is also a function of the company's
culture.
Here are the key factors to consider:
Team Skill Level
There are roughly three team skill levels: (1) A team---an experienced
team that can be entrusted to make good choices; (2) B team---these
people have the right intentions but may not have the level of
experience necessary to make good decisions in many cases and may need
some assistance; and (3) C team---this is a junior team that may not
even know what they don't know yet. These teams can unintentionally
cause substantial issues without significant coaching.
Importance of Speed
One of the main arguments for leverage is speed. The logic goes that
teams should be able to build on the work of their colleagues and not
spend time reinventing the wheel. However, sometimes it's simply an
accepted and acknowledged cost of empowerment to allow teams to
potentially duplicate areas or proceed slower in the name of autonomy.
Other times, the viability of the business depends on this leverage.
Importance of Integration
In some companies, the portfolio is a set of related, but largely independent, products in
which integration and leverage is less important. In other companies,
the portfolio is about a set of highly integrated products in which
integration leverage is critical. This boils down to whether the team
should optimize for its particular solution or optimize for the company
as a whole.
Source of Innovation
If the main sources of future innovation are necessary at the foundation
level, then there will need to be more freedom for teams to revisit core
components. If the main sources of innovation are expected to be at the
solution level, then the company needs to encourage less revisiting of
the foundation and, instead, focus the creativity on application-level
innovations.
Company Size and Locations
Many of the problematic issues with autonomy arise because of issues of
scale. As companies grow, and especially as companies have teams in
disperse locations, leverage becomes both more important and more
difficult. Some companies try to deal with this with the center of
excellence concept in which leverage is focused on teams in a physical
location. Others try stronger holistic roles. Yet others add process.
Company Culture
It is also important to acknowledge the role that an emphasis on
autonomy versus leverage plays in team culture. The further on the
spectrum that the company pushes toward leverage, the more this can be
perceived by the teams as chipping away at their level of autonomy. This
may be acceptable for B- and C-level teams but more problematic for
A-level teams.
Maturity of Technology
One frequent problem is to try to standardize on a common foundation
prematurely. The foundation isn't yet ready for prime time, in the
sense of the leverage it is designed to provide. If you push too hard on leverage before the
foundation is ready, you can truly hurt the teams that are counting on
this foundation. You're building a house of cards that may collapse at
any time.
Importance to Business
Assuming the foundation is solid, there's likely more risk in a team
not leveraging that foundation. This might be fine for some areas, but
with products or initiatives that are business critical, it becomes a
question of which battles to pick.
Level of Accountability
Another factor is the level of accountability that goes along with the
empowerment and autonomy. If there's no accountability---and especially
if you don't have strong A teams---there's little reason for the teams
to stress about these tradeoffs. But you want the teams to stress over
these tradeoffs. If I believe the team is strong and they fully
understand the consequences and risks, and yet they still feel they need
to replace a key component of the foundation, then I tend to side with
that team.
As you can see, there are no lack of considerations in the tradeoff
between autonomy and leveraging the foundation. But, I find if you
discuss these topics openly, most teams are reasonable. Sometimes, just
a few key questions about some of the implications can help teams make
better decisions regarding this tradeoff.
If you find that teams are consistently making poor decisions in this
regard, you may need to consider the experience level of the people on
the team, but most likely, the teams are missing the full business
context.
The critical context is comprised of two things:


[In the first case, the team simply isn't trusted yet by
management, and management is reluctant to give too long of a rope
to the team.]
[In the second case, the team wants to change something that the
leaders had assumed was part of the
foundation.]


However, while most leaders tell me they have empowered, autonomous
teams, some of the people on those teams complain to
me  that they don't always
feel so empowered or autonomous. Whenever this happens, I try to get to
the specifics of just what it is that the team is not able to decide or
where they feel constrained.
Most of what I hear falls into one of two cases:


I attribute most of the benefits to the increased level of motivation
and true sense of ownership when teams feel more in control of their own
destiny.


Autonomy @ Scale
Most leading tech companies have jumped on the empowered,
dedicated/durable, cross-functional, collaborative product team model I
have described here, and I think they are much better for it.
The results speak for themselves, but I attribute most of the benefits
to the increased level of motivation and true sense of ownership when
teams feel more in control of their own destiny.


[Structure Is a Moving Target]
Realize that the optimal structure of the product organization is a
moving target. The organization's needs should and will change over
time. It's not like you'll need to reorganize every few months,
but reviewing your team structure every year or so makes sense.
I often have to explain to companies that there is never a perfect
way to structure a team---every attempt at structuring the product
organization will be optimized for some things at the expense of
others. So, as with most things in product and technology, it
involves tradeoffs and choices. My hope is that these principles
will help you as you guide your organization forward.


[Alignment with Business]
In larger companies, we often have multiple lines of business but a
common foundation for our products. If the technology is truly
independent across businesses, then we'd just treat them as
essentially different companies as we structure product teams.
However, mostly that's not the case. We have multiple lines of
business,  but all are
built on a common and often integrated foundation. This is roughly
similar to aligning by customer type, but there are important
differences. Our business unit structure is an artificial construct.
The different business units are often selling to the same actual
customers. So, while there are advantages to aligning with business
units, this usually comes after the other factors in priority.


[Alignment with User or Customer]
Aligning with the user and customer has very real benefits for the
product and for the team. If, for example, your company provides a
two-sided marketplace with buyers on one side and sellers on the
other, there are real advantages to having some teams focus on
buyers and others focus on sellers. Each product team can go very
deep with their type of customers rather than have them try to
learn about all types of customers. Even in marketplace companies,
however, they will invariably have some number of teams that provide
the common foundation and shared services to all the teams. This is
really a reflection of the architecture, so the point here is that
it is perfectly fine---and usual---to have both types of teams.


[Alignment with Architecture]
In practice, for many organizations the primary principle for
structuring the product teams is the architecture. Many will start
with the product vision, come up with an architectural approach to
deliver on that vision, and then design the teams around that
architecture.
That may sound backward to you, but in truth there are some really
good reasons for this. Architectures drive technologies, which drive
skill sets. While we'd love for every team to be a full stack team
that can work on any layer of the architecture, in practice that's
often not an option. Different engineers are trained in different
technologies. Some want to specialize (and, in fact, have in many
cases spent many years specializing), and some are years away from
having the necessary skills. Architecture does not change quickly.
It's usually easy to see when a company has not paid attention to the
architecture when they assemble their teams---it shows up a few
different ways. First, the teams feel like they are constantly
fighting the architecture. Second, interdependencies between teams
seem disproportionate. Third, and really because of the first two,
things move slowly, and teams don't feel very empowered.
For larger companies, especially, it's typical to have one or more
teams that provide common services to the other product teams. We
often label these teams common services, core services, or
platform teams, but they primarily reflect the architecture. This
is very high-high leverage, which is why so many companies have
these types of teams at scale. However, it is also a difficult type
of team to staff because these teams are dependencies (by design) of
all the other teams, as they are there to enable the other teams.
Be sure to staff these common services teams with strong and highly
technical product managers (often called platform product
managers).


[Team Size]
This is a very practical principle. The minimum size for a product
team is usually two engineers and a product manager, and if the team
is responsible for user-facing technology, then a product designer
is needed, too. Fewer than that is considered below critical mass
for a product team. On the other end, it's really difficult for one
product manager and product designer to keep more than about 10--12
engineers busy with good stuff to build. Also, in case it's not
clear, it's important that each product team have one, and only
one, product manager.


[Product Vision and Strategy]
The product vision describes where we as an organization are trying
to go, and the product strategy describes the major milestones to
get there. Many larger and older organizations no longer have a
relevant vision and strategy, but this is key. Once you have your
vision and strategy, ensure you have structured the teams to be well
positioned to deliver on them.


[Maximize Leverage]
As organizations grow, we often find common needs and the increased
importance of shared services. We do this for speed and reliability.
We  don't want every
team reinventing the wheel. Realize, however, that creating shared
services also creates dependencies and can impinge on autonomy.


[Ownership and Autonomy]
Remember that one of the most important traits of product teams is
that we want teams of missionaries and not teams of mercenaries.
This leads directly to the concepts of ownership and autonomy. A
team should feel empowered, yet accountable for some significant
part of the product offering. This is harder than it sounds because
large systems don't always slice up so cleanly. Some level of
interdependencies will always chip away at the sense of ownership.
But we work hard to try to maximize this.


[Minimize Dependencies]
A big goal is to minimize dependencies. This helps teams move faster
and feel much more autonomous. While we can never entirely eliminate
dependencies, we can work to reduce and minimize them. Also note
that dependencies change over time, so track them continuously and
always ask yourself how they can be reduced.


[Alignment with investment strategy]
It's remarkable to me how many companies I find in which the teams
are simply reflections of their ongoing investments. They have
certain teams because they have always had those teams. But, of
course, we need to be investing in our future as well. We can phase
out products that no longer carry their own weight, and we can often
reduce the investments in our cash-cow products so that we can
invest more in future sources of revenue and growth. There are any
number of ways to think about spreading out your investments over
time and risk. Some people like the three horizons model, while
others take more of a portfolio management approach. The point here
is that you need to have an investment strategy, and your team
structure should be a reflection of that.


I have personally worked with many product and technology organizations
as they considered the options, and for many of those, I've been able
to watch how things worked out over time.
I know that many people crave a recipe for structuring product teams,
but I always explain to them that there is no recipe. Instead, there are
some critical core principles, and the key is to understand those
principles and then  weigh
the options for your particular circumstances.


One of the most difficult issues facing every product organization at
scale is just how to split up your product across your many product
teams.


One of the most difficult issues facing every product organization at
scale is just how to split up your product across your many product
teams.
The need to split up your product starts to show up with just a few
product teams, but at scale---25, 50, more than 100 product teams---this
becomes a very substantial factor in the company's ability to move
quickly. It's also a significant factor in keeping teams feeling
empowered and accountable for something meaningful, yet contributing to
a bigger vision where the sum is greater than the parts.
If you are already at scale, then I'm certain you know what I'm
talking about.
What makes this such a difficult topic is that there is no one right
answer. There are many considerations and factors, and good product
companies debate the alternatives and then make a decision.


[CHAPTER 20][Principles of Structuring Product Teams]


These people might have the title project manager---or sometimes program
manager---but if that's the case, then we need to make sure these
people have defined the job like I did here and not in the old program
management sense.
If your company  does not
have delivery managers---by whatever title---then this work typically
falls to the product manager and the engineering managers. Again, if
your organization is small, then this is fine---and there are even
advantages. But if your organization is larger---on the order of at
least 5 to 10 product teams, then this role becomes increasingly
important.


In growth-stage and enterprise companies, many product managers
complain that they have to spend far too much of their time doing
project management activities.


In growth-stage and enterprise companies, many product managers complain
that they have to spend far too much of their time doing project
management activities. As a result, they have almost no time to address
their primary product responsibility: ensuring that the engineers have a
product worth building.
Delivery managers are a special type of project manager whose mission is
all about removing obstacles---also known as impediments---for the
team. Sometimes, these obstacles involve other product teams, and
sometimes they involve non-product functions. In a single day, they
might track down someone in marketing and press them for a decision or
an approval, coordinate with the delivery manager on another team about
prioritizing a key dependency, persuade a product designer to create
some visual assets for one of the front-end developers, and deal with a
dozen other similar roadblocks.
These delivery managers are typically also the Scrum Masters for the
team (if they have that role). They are all about helping the team to
get stuff live faster, not by cracking the whip but by removing
obstacles that get in the way.


[CHAPTER 19][The Delivery Manager Role]


There is one title, however, that is often a problem: the chief
information officer (CIO). The CIO role is very different from the CTO
role. In fact, if your technology organization reports to the CIO, that
is a warning flag for many of the pathologies discussed in Chapter
6, "The Root Causes of Failed Product Efforts."
The hallmark of a great CTO is a commitment to continually strive for
technology as a strategic enabler for the business and the products.
Removing technology as a barrier, as well as broadening the art of the
possible for business and product leaders, is the overarching objective.
To that end, there are six
major responsibilities of a CTO. We present them here in priority order
and discuss how each is typically measured.
Organization
Build an excellent organization with a strong management team committed
to developing the skills of your employees. We typically measure
effectiveness here by looking at development plans for all the
employees, the retention rate, and the evaluation of the managers and
the overall product and technology organization by the rest of the
company.
Leadership
Represent technology in the overall strategic direction and leadership
of the company, working with other company executives to help inform
direction, M&A activity, and build/buy/partner decisions.
Delivery
Make sure this organization can rapidly, reliably, and repeatedly
deliver quality product to market. There are several measures of
delivery, including the consistency and frequency of release vehicles,
and the quality/reliability of the delivered/launched software. The main
obstacle to rapid delivery is often technical debt, and it is the
responsibility of the CTO to ensure that the company is keeping this at
a manageable level and not allowing the problem to cripple the
organization's ability to deliver and compete, which is discussed next.
Architecture
Make sure the company has  an
architecture capable of delivering the functionality, scalability,
reliability, security and performance it needs to compete and thrive. In
companies that have multiple product lines or vertical business units,
the CTO needs to be the leader in a cohesive technology strategy looking
at the sum, and not just the parts. The CTO is the orchestrator of a
company-wide technology strategy. The measures for architecture will
vary based on your business, but in general, we look to ensure that the
infrastructure is continuously monitored and advanced to keep pace with
the growth of the business, and we measure outages that impact our
customers that are due to infrastructure or architectural issues.
Discovery
Make sure that members of the senior engineering staff are participating
actively and contributing significantly throughout product discovery. If
your engineers and architects are only being used to write software,
then you are only getting a fraction of the value from them you should
be. We encourage you to keep an eye on the participation of the
engineering organization in product discovery (both duration and
coverage) and follow the frequency of innovations credited to the
engineering participant.
Evangelism
The CTO will serve as the company spokesperson for the engineering
organization, demonstrating leadership in the community with developers,
partners, and customers. Leadership of this type can be measured by
establishing a university relations/recruitment program and sponsoring
or participating in several events per year in the developer community.
You may want to go to lunch
with your engineering counterpart and discuss what they see as their
biggest challenges and how you might be able to help from the product
side. Anything you can do to help each other out will go a long way to
creating a truly effective overall product organization, able to
discover and deliver winning products.


Even with the greatest product ideas, if you can't build and launch
your product, it remains just an idea.


Even with the greatest product ideas, if you can't build and launch
your product, it remains just an idea. So, your relationship with the
engineering organization is all important.
In this chapter, I describe the leader of the engineering organization.
I had the good fortune to collaborate on this chapter with one of
Silicon Valley's most successful CTOs, Chuck Geiger.
I have often said that, if as product manager you have a good working
relationship with your engineering counterpart, then this is a great
job. If you don't, you're in for some very tough days. So, in the
spirit of developing a better appreciation for what makes a great
technology organization, we offer this summary.
First, let's be clear which organization we're referring to. This is
the organization responsible for architecture, engineering, quality,
site operations, site security, release management, and usually delivery
management. This group is responsible for building and running the
company's products and services.
The titles vary but often include VP engineering, or chief technology
officer (CTO). In this chapter, we'll refer to the head of this
organization as the CTO, but feel free to substitute the term your
company uses.


[CHAPTER 18][The Head of Technology Role]


Some GPMs go on to become a director or VP of product management, some
go on to a principal product manager role, and some decide to stay on as
a GPM because they love the blend of hands-on working with their own product team, as well as
the ability to influence other teams and other product managers through
coaching.


This role is often called a player-coach role because of this dynamic
of leading your own team, in addition to being responsible for coaching
and developing one to three other PMs.


The Group Product Manager Role
There's a role in larger product organizations that I find especially
effective. The role is titled group product manager, usually referred
to as GPM.
The GPM is a hybrid role. Part individual contributor and part
first-level people manager. The idea is that the GPM is already a proven
product manager (usually coming from a senior product manager title),
and now the person is ready for more responsibility.
There are generally two career paths for product managers.
One is to stay as an individual contributor, which, if you're strong
enough, can go all the way up to a principal product manager---a
person who's an individual contributor but a rock-star performer and
willing and able to tackle the toughest product work. This is a very
highly regarded role and generally compensated like a director or even
VP.
The other path is to  move
into functional management of the product managers (the most common
title is director of product management) where some number of product
managers (usually somewhere between 3 and 10) report directly to you.
The director of product management is really responsible for two things.
The first is ensuring his or her product managers are all strong and
capable. The second is product vision and strategy and connecting the
dots between the product work of the many teams. This is also referred
to as holistic view of product.
But lots of strong senior product managers are not sure about their
preferred career path at this stage, and the GPM role is a great way to
get a taste of both worlds.
The GPM is the actual product manager for one product team, but in
addition, she is responsible for the development and coaching of a small
number of additional product managers (typically, one to three others).
While the director of product management may have product managers who
work across many different areas, the GPM model is designed to
facilitate tightly coupled product teams.
This is easiest to explain with an example.
Let's say you're a growth stage marketplace company, and you have
roughly 10 product teams. You may likely have those 10 teams split up
into three types: a platform/common services group, and then a group for
each side of the marketplace (e.g., buyers and sellers, riders and
drivers, or hosts and guests).
There might be one VP product and three GPMs---one for each of the three
groups, for example, a GPM of buyer side, a GPM of seller side, and a
GPM of platform services.
So now let's drill in on the GPM for buyer side, and let's say there
are three product teams comprising the buyer-side experience. The GPM of
buyer side would have one of those teams, and each of the other two
teams would have a product manager that reports to the GPM.
We like this because  the
buyer side really needs to be one seamless solution, even though there
may be multiple product teams working on different aspects of it. The
GPM works very closely with the other PMs to ensure this.
This role is often called a player-coach role because of this dynamic
of leading your own team, in addition to being responsible for coaching
and developing one to three other PMs.


There are two very bad situations you may encounter related to product
vision and strategy.
The first is when you  have a
CEO who is very strong at product and vision, but she wants to hire a VP
product (or, more often, the board pushes her to hire a VP product), and
she thinks she should be hiring someone in her own image---or at least
visionary like her. The result is typically an immediate clash and a
short tenure for the VP product. If this position looks like a revolving
door, it's very possible that's what's going on.
The second bad situation is when the CEO is not strong at vision, but
she also hires someone in her own image. This doesn't result in the
clash (they often get along great), but it does leave a serious void in
terms of vision, and this causes frustration among the product teams,
poor morale across the company, and usually a lack of innovation.
The key here is that the VP product needs to complement the CEO. If
you have a strong, visionary CEO, there may be some very strong VP
product candidates that won't want the position because they know that,
in this company, their job is primarily to execute the vision of the
CEO.
One situation that unfortunately happens is when you have a visionary
founder CEO, and she has a solid partner running product who is very
strong at execution, but the founder eventually leaves and now the
company has a problem because nobody is there to provide the vision for
the future. It's generally not something a VP product can easily turn
on and off, and even if they can, the rest of the company may not be
willing to consider the product leader in this new light. This is why I
generally prefer when the founders stay on at the company, even if they
decide they want to bring in someone else as the CEO.
If you're wondering what to do when you have a CEO who thinks she's
a strong visionary leader, but the rest of the company knows she's not,
you need a very special head of product, one that is a strong visionary,
but also has the ability and willingness to convince the CEO the vision
was all her idea.
Execution
No matter where the vision comes from, all the great vision in the world
doesn't mean much if you can't get the product idea into the hands of
customers. You need a product leader who knows how to get things done
and has absolutely proved her ability to do so.
There are many aspects  that
contribute to a team's ability to execute consistently, rapidly, and
effectively. The product leader should be expert on modern forms of
product planning, customer discovery, product discovery, and product
development process, but execution also means that they know how to work
effectively as part of an organization of your size.
The bigger the organization, the more critical it is that the person has
proven, strong skills---especially in stakeholder management and
internal evangelism. The product leader must be able to inspire and
motivate the company and get everyone moving in the same direction.
Product Culture
Good product organizations have a strong team, a solid vision, and
consistent execution. A great product organization adds the dimension
of a strong product culture.
A strong product culture means that the team understands the importance
of continuous and rapid testing and learning. They understand that they
need to make mistakes in order to learn, but they need to make them
quickly and mitigate the risks. They understand the need for continuous
innovation. They know that great products are the result of true
collaboration. They respect and value their designers and engineers.
They understand the power of a motivated product team.
A strong VP product will understand the importance of a strong product
culture, be able to give real examples of her own experiences with
product culture, and have concrete plans for instilling this culture in
your company.
Experience
The amount of relevant experience, such as domain experience, will
depend on your particular company and industry. But at a minimum, you
are looking for someone with the combination of a strong technology
background with an understanding of the economics and dynamics of your
business and your market.
Chemistry
Last but certainly not
least, everything previously discussed is still not enough. There is one
more thing: Your product leader must be able to work well on a personal
level with the other key execs, especially the CEO and CTO. It will not
be fun for any of you if there isn't that personal connection. Make
sure the interview process includes a long dinner with at least the CEO
and CTO and probably the head of marketing and head of design. Be open
and make it personal.


[Where there is a CEO or a founder who is the clear product
visionary]
[Where there is no clear product visionary---usually in situations
where the founder has moved on]


The single most important responsibility of any VP
product  is to develop a
strong team of product managers and designers. This means making
recruiting, training, and ongoing coaching the top priority. Realize
that developing great people requires a different set of skills than
developing great products, which is why many otherwise excellent product
managers and designers never progress to leading organizations.
One of the worst things you can do is take one of your poor-performing
people and promote them to this leadership position. I know that may
sound obvious, but you'd be surprised how many execs reason, "Well,
this person is not very strong, but he works well with people, and the
stakeholders seem to like him, so maybe I'll make him the head of
product and hire a strong individual contributor to backfill him." But
how do you expect this poor performer to help develop his or her team
into strong performers? And what message does this send to the
organization?
For this position, you need to ensure you hire someone who has proven
ability to develop others. They should have a track record of
identifying and recruiting potential talent, and then working actively
and continuously with those people to address their weaknesses and
exploit their strengths.
Product Vision and Strategy
The product vision is what drives and inspires the company and sustains
the company through the ups and downs. This may sound straightforward,
but it's tricky. That's because there are two very different types of
product leaders needed for two very different situations:


The single most important responsibility of any VP product is to
develop a strong team of product managers.


In this chapter, I use the title VP product to refer to this position,
but you'll also find titles ranging from director of product management
to chief product officer. Whatever the title may be, I am referring here
to your most senior product role in your company or business unit.
Organizationally, this role typically manages the product managers and
product designers, sometimes the data analysts, and generally reports to
the CEO. With some exceptions, it is important that this role be a peer
to the CTO and the VP marketing.
I'll say right up front that this is a difficult role, and it is
difficult to perform well. Those who do succeed in it make a dramatic
difference for their companies. Great product leaders are highly valued
and often go on to found their own companies. In fact, some of the best
venture capitalists only invest in founders who have already proved
themselves as great product leaders.
Competencies
Specifically, you are looking for someone who is proved to be strong in
four key competencies: (1) team development, (2) product vision, (3)
execution, and (4) product culture.
Team Development


[If you are a CEO or executive recruiter and you're looking for a
head of product, this chapter will give you a deeper understanding
of what kind of person you should be
seeking.]
[If you are currently leading a product organization, I'd like to
offer this up as your key to success.]
[If you have aspirations of one day leading a product organization,
this is a frank discussion of the skills you'll need to
acquire.]


I've written this chapter for three specific audiences:


[CHAPTER 17][The Head of Product Role]


For a startup, there's typically just one or two product teams, so
it's not too hard for everyone to keep in their heads a holistic view
of the product. However, this quickly becomes much tougher as the
company grows---first to a larger product and soon to many product
teams.
One of the big challenges of growth is knowing how the whole product
hangs together. Some people like to think of holistic view as connecting
the dots between the teams.
The three distinct but critical elements to the holistic view of product
are described next.
Leaders of Product Management
To ensure a holistic view of how the entire system fits together from a
business point of view (product vision, strategy, functionality,
business rules, and business logic), we need either the leaders of the
product management organization (VP product, directors of product), or a
principal product manager.
This person should regularly
review the work of the various product managers and product teams,
identifying and helping to resolve conflicts.
For large-scale organizations, some companies prefer this to be an
individual contributor role (e.g., a principal product manager), but let
me be clear that this is a very senior role (usually equivalent to a
director-level manager). Since the head of product is first and foremost
responsible for building the skills of the product managers, a dedicated
principal product manager is able to focus on the product itself and
is readily accessible as a critical resource to all the product
managers, product designers, engineers, and test automation staff.
If you use a principal product manager for this, he or she should be a
direct report to the head of product so that everyone understands the
importance of the role and the responsibilities of that person.
Whether this role is covered by the head of product or a principal
product manager, this is a critically essential role for companies with
large and complex business systems, especially with many legacy systems.
Leaders of Product Design
One of the most important roles in a company is the person or people
responsible for the holistic user experience. These leaders must ensure
a consistent and effective user experience systemwide. This is sometimes
the leader of the product design team, sometimes one of the managers or
directors of design, and sometimes a principal designer reports to this
leader. In any case, it must be someone very strong in holistic product
design.
There are so many interactions and interdependencies---and so much
necessary institutional knowledge of the business and the users and the
customer journey---that at least one person must review everything going
on with the product that is going to be visible to the user. You can't
expect any individual product manager or designer to be able to have
this all in their head.
Leaders of Technology Organization
Finally, to ensure a holistic view of how the entire system fits together from a technology
point of view, we have a technology organization leader (often titled
CTO or VP engineering). In practice, that person is often helped by a
group of engineering managers and directors and/or software architects.
The CTO, managers, and architects are responsible for the holistic view
of the system implementation. They should be reviewing the architecture
and systems design of all the software---both systems developed by your
own staff, as well as any systems designed by vendors. They should also
have a clear strategy for managing technical debt.
Again, this is a critically essential role for companies with large and
complex business systems, especially with many legacy systems, and
should be placed in the organization somewhere that makes these people
visible and available to the entire technology organization (this is
usually a direct report to the head of technology).
Holistic View Leadership Roles
The larger the company gets, the more critical these three roles are,
and their absence is usually all too obvious. If the product or site
looks like it was created by half a dozen different outside design
agencies, with conflicting user models and poor usability, you're
probably missing a head of design or principal designer.
If projects are constantly getting stuck because product managers don't
understand the implications of their decisions or product managers are
constantly asking developers to look at the code to tell them how the
system really works, then you're probably missing a principal product
manager.
And if your software is a big mess of spaghetti and it takes forever to
make even simple changes, you're probably suffering from significant
technical debt.
You might ask what happens
if one of these people gets hit by a bus or leaves the company? First
and foremost, don't lose these people! Take care of them and don't
give them any reason to want to leave or feel like they need to become a
manager to make more money.
Second, you should always be trying to develop more of these people, and
each of them should have at least one person they're working to develop
into a strong second. But they are a rare and incredibly valuable
commodity, as this learning does not happen overnight.
Some companies think the answer to this is to try to document the system
to the degree that everything is captured somehow in a way that members
of the organization can all go to get the same sorts of answers for
which they use the principal designer, principal product manager, and
software architect.
I know a few organizations that have tried hard to achieve this, but I
have never seen this succeed. The systems always seem to grow in
complexity and size much faster than anyone can document, and with
software, the definitive answer always lives in the source code itself
(at least the current answer---not usually the rationale or the
history).
One final note: These three holistic-view leaders---the head of product,
the head of design, and the head of technology---are obviously very
valuable individually, but in combination you can see their real power.
This is why my personal preference is to have these three people sit
very close to one another, sometimes in the same physical office.


One of the big challenges of growth is knowing how the whole product
hangs together. Some people like to think of holistic view as connecting
the dots between the teams.


The primary job of leadership in any technology organization is to
recruit, to develop, and to retain strong talent. However, in a product
company, the role goes beyond people development and into what we call
holistic view of product.


[CHAPTER 16][The Role of Leadership]


Overview
Most companies know that they need to double down on their efforts to
recruit very strong staff as they grow, but they don't always know what
other changes are important as they grow and scale.
What are the changes in the leadership roles? How do we maintain the
holistic view of product when we have many teams? How do we keep teams
feeling empowered and autonomous when they just own a small part of the
whole? How do we encourage accountability when the only person that owns
everything is the CEO? How do we deal with the explosion of
dependencies?
These are the topics we will tackle as we discuss how strong product
organizations scale.


[People @ Scale]


Jane led the product discovery work and wrote the first spec for
AdWords. Then she worked side by side with the engineers to build and
launch the product, which was hugely successful.
This is yet another example of how there are always so many good reasons
for products not to get built. In the products that succeed, there is
always someone like Jane, behind the scenes, working to get over each
and every one of the objections, whether they're technical, business,
or anything else.
Jane took a break to  start a
family and is now back at Google once again, this time helping out the
YouTube team.


This is yet another example of how there are always so many good
reasons for products not to get built. In the products that succeed,
there is always someone like Jane, behind the scenes, working to get
over each and every one of the objections, whether they're technical,
business, or anything else.


I'm sure you have heard of Google's AdWords, and you may have also
heard that this product is what fuels the Google empire. To be specific,
as of this writing, AdWords is currently 16 years old, and in the most
recent year alone, it generated well over $60B in revenue.
Yes, that's B as in billions.
What I'm guessing most of you don't know, however, is just how this
industry-defining product came to be. And especially how close this
product came to never happening at all.
The year was 2000, and the hardest part about the AdWords project was
simply getting an agreement to work on it. The core idea had support
from Larry Page, but the idea immediately encountered some pretty strong
resistance from both the ad sales team and the engineering team.
Jane Manning was a young engineering manager asked to serve as product
manager for this effort to try to get it off the dime.
The new sales team, under Omid Kordestani, was off to a strong start
selling keywords to large brands and placing the results at the top of
the search results. These results were highlighted as an ad but still
very prominent---much in the style that had been done in search results
at other companies, including at Netscape where Omid came from. Sales
was nervous that this idea of a self-service advertising platform would
diminish the value of what the sales team was trying to sell (known as
cannibalization).
And the engineers, who had been working so hard to provide highly
relevant search results, were understandably very worried that users
would be confused and frustrated by ads getting in the way of their
search results.
Jane sat down with each of these people to get a deeper understanding of
their concerns. Some were just plain uncomfortable with advertising.
Others were worried about cannibalization. And yet others were concerned
about potential  user
unhappiness.
Once Jane understood the constraints and concerns, she had the
information she needed to advocate for a solution that she believed
would address the issues, yet enable countless small businesses to get a
much more effective advertising solution. Jane also was able to persuade
one of Google's earliest and most respected engineers, Georges Harik,
of the idea's potential, and he helped to bring along other engineers.
The product solution they ended up with placed the AdWords-generated ads
to the side of the search results, so they wouldn't be confused with
the salesperson-sold ads, which were displayed on the top of the
results.
Also, instead of determining placement based solely on the price paid,
they would use a formula that multiplied the price paid per impression
with the ad's performance (click-through-rate) to determine placement,
so that the best-performing ads---the ones most likely to be most
relevant to users---would rise to the top, and the worst ads would be
unlikely to be displayed at all, even if they were sold at a higher
price.
This solution clearly differentiated for the sales team and ensured
quality search results, whether paid or organic.


[CHAPTER 15][Profile: Jane Manning of Google]


If your company does not have any data analysts, then responsibility for
this typically falls on the product manager. If this is the case,
you'll probably need to plan to spend significant time diving deep into
the data to understand your situation and make good decisions.
Test Automation Engineers
Test automation engineers
write automated tests for your product. They have largely replaced the
old-style manual quality assurance (QA) people.
Now, it's very possible that your engineers are responsible both for
writing software and for writing these automated tests. If that's the
case, then you probably won't have many test automation engineers. But
most companies have a blended approach in which the engineers write some
of the automated tests (e.g., the unit level tests), and the test
automation engineers write the higher-level automated tests.
Whichever model your company has is typically up to the engineering
leadership, which is fine. However, what's not okay is if your company
doesn't have test engineers, and your engineers don't do the testing
either, and they are looking to you as product manager to do the quality
testing.
While it's true as product manager you want to make sure things are
generally as you expect before things go live (acceptance testing),
that's a far cry from being able to release with confidence. The level
of test automation necessary
to release with confidence is significant and a big job. It's not
unusual in complex products to have multiple test engineers dedicated to
each product team.


Data analysts help teams collect the right sort of analytics, manage
data privacy constraints, analyze the data, plan live-data tests, and
understand and interpret the results.


So far, we've talked about your role as product manager, and we've
also talked about the designers, engineers, and product marketing
managers you'll be working with very closely every day.
But there are other people in supporting roles you'll also work with.
These people will probably not be dedicated solely to your team, as they
are typically assigned to a small number of other product teams.
Now, you might not have any of the people I'm about to describe
available to you. It really depends on the size and type of organization
you work at. If you're at a small startup, you very probably will have
none of these roles, and you will need to cover these activities
yourself. But if you're at a company that has some or all of these
roles, I want you to know why they exist and, most important, how to
make the best use of these people.
User Researchers
As you'll soon see when we talk about how we do product discovery, we
are continuously doing two kinds of rapid learning and experimentation.
One kind of learning is qualitative, and the other is quantitative.
Especially with the qualitative learning, some of our research is
generative, which is understanding the problems we need to solve; and
some of our research is evaluative, which is assessing how well our
solutions solve the problem.
User researchers are trained in this range of qualitative techniques
(and some of them are also trained on the quantitative techniques as
well). They can help you find the right type of users, craft the right
types of tests, and learn the most from each user or customer
interaction.
The key to tapping into the real value that these user researchers can
provide is to keep in mind
that the learning must be shared learning. You need to witness the
insights first hand. More on this when we talk about the principles of
product discovery, but while I want you to appreciate what user research
can help you with, I don't want you to think you can delegate to them
to do the learning and then send you a report.
If your company does not have user researchers, then your product
designer will typically pick up these responsibilities for your team.
Data Analysts
Similarly, for quantitative learning, data analysts help teams collect
the right sort of analytics, manage data privacy constraints, analyze
the data, plan live-data tests, and understand and interpret the
results.
Sometimes, data analysts go by the name business intelligence (BI)
analysts, and they're experts in the types of data that your business
collects and reports. It is well worth making friends with your data
analyst. So much of product work today is data driven, and these people
can be real gold mines for you and your organization.
In some companies, especially those with a lot of data---such as larger
consumer companies---this may be a full-time role dedicated to a
specific product team. In this case, the data analyst would be sitting
and working alongside the product manager and product designer.


[CHAPTER 14][The Supporting Roles]