by Marty Cagan
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.
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:
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).
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.
CHAPTER 25
Principles of Product Vision
These are the 10 key principles for coming up with an effective product vision.
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.
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.
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.
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. Fall in love with the problem, not with the solution.
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.
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.
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.
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.
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.
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.
CHAPTER 26
Principles of Product Strategy
As we discussed previously, there are any number of approaches to product strategy, but good strategies have these five principles in common:
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.
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.
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. Obsess over customers, not over competitors.
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.
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.
CHAPTER 27
Product Principles
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.”
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.
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.
Product Objectives
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:
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.
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 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.
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.
CHAPTER 28
The OKR Technique
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.
Objectives should be qualitative; key results need to be quantitative/measurable.
Key results should be a measure of business results, not output or tasks.
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.
Find a good cadence for your organization (typically, annually for an organization's objectives and quarterly for a team's objectives). Key results should be a measure of business results, not output or tasks.
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).
It's critical that every product team track their active progress against their objectives (which is typically weekly).
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 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.
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.
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.
Be very transparent (across the product and technology organization) on what objectives each product team is working on and their current progress.
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.
CHAPTER 29
Product Team Objectives
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 engineer
s. 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.