INSPIRED

by Marty Cagan

  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.

  CHAPTER 23

  The Alternative to Roadmaps

  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:

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

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

  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.

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

  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:

  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.

  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 cul
tural and motivation implications to the team.

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

  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.

  Product Vision

  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.

  CHAPTER 24

  Product Vision and Product Strategy

  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.

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

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

  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.

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

  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.

  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.