Product Roadmaps Relaunched

Chapter 1. Relaunching Roadmaps

What you’ll learn in this chapter

A few definitions, including:

• Product

• Customer

• Stakeholder

Where product roadmaps came from

Requirements for a roadmap relaunch

What is a product roadmap?

Properly done, a product roadmap can steer your entire organization toward delivering on the company strategy.

It is your vision for how your products will help achieve your organization’s strategic goals. A good roadmap inspires buy-in and over-delivery from your entire organization.

It’s easy to think of a roadmap as a fixed and detailed plan—etched in stone almost—and this is where product people often find frustration sets in. A traditional roadmap is not flexible enough for the lean and agile methods many teams have adopted, and it is often light on the strategic context necessary for teams to understand the overall vision. This is why a re-launch is necessary.

A good roadmap is not so much a project plan as a strategic communication tool, a statement of intent and direction. In this chapter, we describe the key requirements for relaunching roadmaps as effective treasure maps for the value you’ll deliver to your customer and your organization. Get out your spyglass and compass, and let’s get started.

What Is a Product Roadmap?

In our view, a product roadmap describes how you intend to achieve your product vision.

It focuses on the value you propose to deliver to your customer and your organization in order to rally support and coordinate effort among stakeholders.

It’s that simple. And that simplicity is critical to success. Remember, however, that simple does not always equal easy.

Figure 1-1. Product roadmaps can take many forms, and aren’t necessarily a single artifact or document. In fact, it’s really not about creating artifacts at all—it’s about creating a shared understanding of where you’re going and why.

Figure 1-2. Roadmap examples in different shapes and sizes, from a single page to a multipage document

Key Terms and How We’re Using Them

Product

Before we define a product roadmap in detail, let’s first describe what we mean by a product. A product is how you deliver value to your organization’s customers. We usually think of a product as an artifact, like a smartphone or a toaster, but our broader definition includes services like pizza delivery, a Netflix subscription, or even an experience like a Broadway play. To keep it simple, throughout this book we’ll refer to whatever you deliver to your customers as your “product.”

Stakeholder

We use the term stakeholder to refer to all the internal and external colleagues and partners who are involved with the product being developed, marketed, sold, and serviced. Internally this could range from sales, marketing, user experience, engineering, research, finance, and even human resources; externally this could imply partners such as suppliers, technology partners, vendors, resellers, or brokers.

Customer

We use the term customer to refer to the recipient of the value your product provides, so let’s define that as well. Within that term, we include the buyer and the user of your product. (We’ll talk more about the differences in Chapter 3.) In many consumer products, the buyer and the user are the same person. I buy a cup of coffee and I drink it to help me wake up and focus (and because I like the taste). You buy a watch and you strap it on each morning to help keep you on schedule.

However, I might buy a watch for you as a present, separating the role of buyer from that of user. This split is very common in business, where someone in the IT department selects and buys the computers, phones, and other equipment and software that all of the employees use. We’ll call out the difference when important; otherwise, we will refer to both buyer and user as the “customer.”

It’s also worth noting that customers may receive value without payment, per se. Some products are free or supported by advertising, like Gmail or broadcast TV. And some products are created and used within the same organization, for example a corporate intranet where employees can learn about benefit programs and company events.

Where Did Product Roadmaps Come From?

It all starts with the bicycle. In the 1890s, bicycles were a key form of transportation within cities, and some of the first roadmaps were created to show how to bike from one part of New York City to another. With the rise of the automobile, travel between cities becomes more common, and flourishing organizations like the American Automobile Association (AAA) provided printed roadmap directions for travelers. Even today, we are still using roadmaps in electronic form, like Waze and GPS navigation, to direct us to our destinations.

In the 1980s, Motorola began using the term roadmap to align technology and product development. Technology roadmaps became widely accepted in the 1990s across the semiconductor industry and were eventually adopted by many other technology-driven organizations, including Microsoft, Google, and Oracle. These roadmaps were created to inform stakeholders of when major upgrades were coming so they could plan their purchases many months in advance. This is still important when you are manufacturing the chips for millions of electronic devices that themselves have long manufacturing lead times. Planning was and continues to be essential in such businesses.

The ever-increasing pace of change in technology, however, coupled with adoption of lean and agile practices that leverage rapid release cycles, learning, and data-driven product decisions, has made the traditional roadmap an unwieldy instrument. Dates slip, technologies become obsolete, priorities shift, customer preferences evolve, the competition gains ground.... As a result, product people increasingly have found themselves caught between breaking promises and staying the course on a plan made months ago that seems increasingly out of touch.

The mismatch between traditional roadmaps and the reality of most product development efforts has gotten bad enough that many product teams have abandoned the practice altogether or restricted access to the roadmap to a few trusted team members.

Few are satisfied with this state of affairs, however. Agile and lean methods have not filled the strategy gap created when roadmaps are left behind. If anything, agile teams complain they spend so much time focused on the next few weeks that they lose sight of the reasons they are doing all this work.

So let’s define what it would take to make a good roadmap today.

Requirements for a Roadmap Relaunch

As we outlined in the preface, the product people we’ve talked to are looking for certain things from a roadmap.

A product roadmap should:

• Put the organization’s plans in a strategic context

• Focus on delivering value to customers and the organization

• Embrace learning as part of a successful product development process

• Rally the organization around a single set of priorities

• Get customers excited about the product’s direction

At the same time, a product roadmap should not:

• Make promises product teams aren’t confident they will deliver on

• Require a wasteful process of up-front design and estimation

• Be conflated with a project plan or a release plan (we cannot stress this enough)

Let’s take a closer look at each of these requirements, what problem each is intended to solve, and a little about how a relaunch of roadmapping can solve it. We’ll also guide you to chapters that explore each of these concepts in more detail along the way.

A Roadmap Should Put the Organization’s Plans in a Strategic Context

Problem: Nobody understands why things are on the roadmap

The traditional roadmap was so focused on deliverables that it often left out the critical context of why the organization is focused on these specific things at all. Product people spend enormous amounts of time sifting through market data and customer input; they prioritize, estimate, design, architect, and schedule, but then too often forget to clearly explain their thinking to the people involved in execution.

This is a problem within the product development team itself because without a sense of the big picture, the many decisions engineers, designers, and production people must make on their own are not united by a common vision. The same lack of vision hampers efforts to coordinate with other departments such as marketing, sales, finance, and support.

The roadmap is a critical—and frequently missed—opportunity to articulate why you are doing this product, why it’s important, and why the things on it are absolutely vital to success.

Symptoms of this particular problem include:

• Your product doesn’t get the funding, shelf space, or marketing support it needs.

• You get lots of questions about the details (features, dates) on your roadmap.

• You get lots of ideas for things to add to the roadmap that don’t fit with your vision (the one you haven’t clearly articulated).

“We suffer from ‘shiny object’ syndrome.”

“No one knows what our end goal should be.”

Solution: Tie the roadmap to a compelling vision of the future

“This is our vision of why we’re here and what we’re trying to accomplish for clients, and here’s the roadmap that’s going to help us progressively get there.”

Matt Poepsel, Vice President, Product Development, The Predictive Index

Before you get into the details of what you and your team are working on, take a moment to explain the big picture. Why are you doing this product in the first place? What will it mean if you are successful—to the customer, to the company, to the world?

Maybe your company has a mission statement, a vision, or a purpose. A good place to start in defining your product vision is to link it to your organization’s reason for being.

Then, if everything on your roadmap is clearly there to support that mission, the “why” becomes much more evident. Conversations change from “Why are we doing that?” to “Would decision A or B help us achieve our vision sooner?” Steve Blank, author of The Startup Owner’s Manual, reminds us to start with the mission, strategic intent and only then devise the plan from there. “Let’s take Airbnb. The mission is, ‘We want to change how people view temporary housing. Okay. What’s our goal? We want to have 5 million users, 16 million places to rent, how do we do this? We need to deliver software that allows people to do this. OK, what kind of features do we need?’”

Your product roadmap should slot right in between your company vision and your more detailed development, release, and operational plans.

Chapter 4 goes into much more detail on creating a product vision and measurable goals.

A Roadmap Should Focus on Delivering Value to Customers and the Organization

Problem: You are shipping a lot but not making progress

“A lot of people think a feature release schedule and roadmap are synonymous, right? You’ve probably heard that a hundred times. In fact, if you look at any of the software programs I’ve seen out there for product roadmapping, they’re a graphical version of this feature x on with a delivery date. In my mind, a roadmap is a series of statements that communicate WHAT you’ll help customers accomplish and WHY those goals are important to their success.”

John Mansour, Managing Partner, Proficientz

The traditional product roadmap is really more of a project plan focused on efficient use of resources, maximizing throughput, and hitting dates. Many highly detailed roadmaps, however, entirely leave out discussion of what is expected as a result of all this effort.

Many teams have begun measuring the actual effect of additions or changes to their product on customer behavior and business results, but this is usually absent from the roadmap. The only criteria left for management to judge success of product development efforts, then, is whether the team shipped on time—but does being on schedule make any difference if you have no effect on customer behavior or business results?

Symptoms of this particular problem include:

• Releases happen on time but don’t change any of your business KPIs (key performance indicators).

• Implementing customer requests doesn’t increase customer satisfaction.

• Features meet the specs without solving the problem for the customer.

“I have no insight into how my team’s work affects the bottom line.”

“I never really talk directly to our customers.”

Solution: Focus the roadmap on delivering value

After you’ve described the product vision and what everyone’s there to accomplish, the next level down in detail should not be a laundry list of features, functions, and fixes with dates. Instead—even if you are pretty certain about some of the specifics—we recommend starting with the chunks of value you intend to deliver that will build up over time to accomplish your vision.

Often this is a set of high-level customer needs, problems, or jobs to be done, which we call themes. To borrow an example from the next chapter, the most basic job a garden hose needs to do is to transport water from the spigot to the garden. All hoses do that well enough, but many present the customer with problems like kinks and leaks that prevent all the water from reaching its destination. The garden hose product roadmap might, then, include a statement of the customer’s need for (i.e., a theme of) “indestructibility.”

This makes the goal of the next version, variation, or feature of the product very clear to all stakeholders, including the people responsible for designing and manufacturing it. David Cancel, CEO of Drift, says, “We wanted as much autonomy down at the engineering and product team level as possible. Of course, there were some of what we call guardrails and goalposts. Within those guardrails, they could decide what that product looked like or how we were going to go to market.”

Critically for the roadmap, these guardrails also provide a means of judging when you are done that is separate from the due dates. To return to our earlier example, you are done when you have an indestructible hose you can manufacture and sell at a profit.

Ben Foster, an advisor to product-driven startups, expands on the idea that uncovering themes to deliver value is more important than simply hitting deadlines: “I prefer to keep dates as vague as possible in order to maintain flexibility. If I don’t have sufficient confidence an item on the roadmap will be delivered by a specific date then, I don’t want to commit to it. The roadmap should clarify plans, but without providing false precision that someone else might be banking on.”

In Chapter 5, we’ll delve further into what themes are and how to develop them for your roadmap.

A Roadmap Should Embrace Learning

Problem: Executives and customers demand commitments

“I think the biggest challenge a roadmap has is that it’s sort of your expectation of how your production is going to happen. If the salesperson gets a little bit aggressive with it because they think it’s going to help them win a deal, I think that’s the classic mistake. It becomes a commitment, and if something changes in your business and it’s not in the best interest of the company to go down that path, that’s when it blows up in your face.”

Matt Poepsel, Vice President, Product Development, The Predictive Index

These high-level themes and broad date ranges we describe are fine, you might be thinking, but what happens when the customer says they won’t sign the big contract without a commitment to a specific feature this year? Or the CEO feels that extracting blood oaths is the way to ensure everyone is working hard enough?

Again, the traditional roadmap tries so hard to predict an unpredictable future that it invites these kinds of conversations. It would be much better to have a conversation about value, wouldn’t it? About goals? About why the features the customer is demanding are important and what problems are driving their thinking and priorities?

If you’ve done a good job articulating the value you intend to deliver, the details of how you will deliver it are certainly less important. In fact, they are not just a distraction, they’re actually an impediment to delivering the most value. By committing too early to a single solution to a problem, you are constraining your options and stifling your team’s creativity.

Symptoms of this particular problem include:

• Salespeople write commitments into contracts to win a deal.

• Customers extract promises before they will sign.

• Executives feel that date commitments are the only way to get results.

“We have a lot of data but we don’t know how to use it.”

“Our process is broken but we avoid fixing it.”

“I have no idea how other teams or other companies roadmap.”

Solution: Commit to outcomes rather than output

When a customer (or a CEO, or really any stakeholder) asks about whether a particular feature or design or other detail will be part of the solution, rather than answer the question, experienced product people have learned to turn it around. They ask “Why?” Why is that feature important to you? What is it about that date? The smartest product people are trying to understand what problem that stakeholder is trying to solve. This helps them understand their customers’ needs better, of course, but it also raises the level of discussion.

With an understanding of the real goal, a product person can then ask the customer, “If I commit to solving this problem for you the best way I can, then do we have a deal?” Or, as Drift’s David Cancel suggests, “Rather than try to predict the future, why don’t I invite you into our process? If you are a key strategic customer, then when we get close to a possible solution for the thing that is of concern to you, we’ll bring you into a design review and let you give us feedback about whether it meets your needs.”

When customers and other stakeholders make these demands, it’s because they don’t know how else to influence product direction. And some of them really do have hard dates or specs that must be met; for example, to make a production schedule or meet regulatory standards. If you can create a relationship of trust, though, by being really honest about what you know and what you don’t, customers will understand when you have to change directions or priorities on the roadmap.

Alex Kohlhofer, Director of Product for UserVoice, says, “Prospects do sometimes ask for things in the contract, but we’ve never done it. We might learn things that would trump that request in importance. We sometimes lose deals based on customer asks we cannot guarantee, but we have lots of customers, and I need to do what’s best for most of them, not just a few of them.”

Matt Poepsel adds that the customer must “be a responsible consumer of the roadmap to understand that things that are far out in that roadmap, you just can’t take them as strictly, exactly what’s going to happen. These aren’t commitments so much as they’re intentions.”

Chapter 9 describes ways to decide how frequently to update your roadmap and how to communicate change.

A Roadmap Should Rally the Organization Around a Single Set of Priorities

Problem: Marketing and sales are not selling what you are making

“I think that in recent years, it’s become generally recognized that having the right strategy only matters if there’s total alignment around it. When marketing is telling one story, sales is selling something different, and engineering is building something different still, then product management’s strategy is hollow and irrelevant. The roadmap must align all the stakeholders around a common product plan.”

Ben Foster, advisor to product-driven startups

Foster’s point reiterates the starring role your product vision must play in your roadmap, and how important it is to explain the value of each component on it to the customer and to the organization.

But even if you’ve done a good job with all of that, the challenge you’ll face next is setting priorities. The fact is, there are just too many good ideas for any team—of any size—to implement. You can’t do everything at once, so you have to pick and choose.

Getting alignment on priorities is not easy, but it’s critical to execution. Organizations that don’t align well around the roadmap miss market opportunities because it takes months for marketing and sales to catch up to what the product team is putting out there. In some organizations, products perform poorly because the marketing and sales teams never had the opportunity to buy in and achieve this alignment.

Symptoms of this particular problem include:

• Marketing doesn’t know how to explain your product to the market.

• Sales continues selling last year’s products.

• You receive lots of ideas for the roadmap, none of which make the cut.

“What are our other product teams doing?”

“We see the same roadmap items again and again.”

Solution: Align everyone around common goals and priorities

As Carol Meyers, CMO of Rapid7, puts it, “At some point, you need to start talking with the sales force about, ‘Hey, we think we’re going to be bringing this new product to market. What’s the best way to go to market? Can our current reps sell it, or should we have specialized reps? How do we get everybody trained up to understand the customer’s problem and the solution we’re bringing to market?’”

The best way we’ve found to rally these people is to involve them in the decisions that will affect them. This requires that you share some of your thinking early, before the relevant parts of the roadmap are really concrete, to get their input. Emily Tyson, VP Product at NaviHealth, says: “Every product manager actually has their own stakeholder advisory group—cross-functional representatives that they work with to get input on: What are priorities for sales? What are priorities from the clinical team? What does security need in the roadmap? The product team is very much responsible for taking all of the different inputs and saying, ‘This is it.’”

Chapter 7 details a number of techniques for setting priorities based on your guiding principles.

Chapter 8 then goes on to explain in detail how to gain that critical buy-in and alignment from your stakeholders.

A Roadmap Should Get Customers Excited About the Product Direction

Problem: Customers aren’t excited about your new features

“How do product teams really know the right thing to build? Many products aren’t successful because teams haven’t done enough problem discovery and validation with customers. Those processes need to be a part of a product team’s culture.”

Jim Semick, Founder, ProductPlan

Just hitting your target dates and intended feature releases is no guarantee of market acceptance nor of business success. A healthy amount of experimentation can help establish what needs to be built and the metrics against which products will be measured prior to building and shipping. A roadmap has been called a prototype of your strategy, and allowing customers to view your roadmap allows them to offer feedback on and buy into your direction.

Sharing a roadmap with customers is scary for many product people. They naturally worry that anything they say will be held against them in the future if things change (and they always do). More courageously, Jim Kogler, VP of products at VT MAK, sees the advantage of sharing: “I use the roadmap as a lubricant for effective communication in front of a customer.” Experienced practitioners differ on this point, but more often than not the benefits of sharing early and often with customers outweigh the risks. The trick is in framing the conversation correctly.

Symptoms of this particular problem include:

• Customers don’t use the new features you’ve worked so hard on.

• Sales plateau (or decline) despite improvements and updates.

• A customer confronts you with a copy of last year’s roadmap and accuses you of breaking your promises (shiver).

“We don’t expose new ideas to customers.”

“We don’t validate needs before building things.”

Solution: Use the roadmap to reality-check your direction with customers

“A roadmap is a two-way communication device. When a customer sees a roadmap, when they see what I’m showing them, we start a dialog about business pain and priorities. They tell me, ‘Oh, that’s going to solve a problem for me.’”

Michael Salerno, VP of Product, Brainshark

A roadmap conversation with a customer is an opportunity for a product person to verify their understanding of market needs before actually building the product. If you’ve done a really great job in your customer discovery, then the roadmap (in Steve Blank’s words) is merely “confirming the mutual understanding” of these needs. It’s also an opportunity to discover where you might be wrong, of course, which is perhaps even more valuable as you still have the opportunity to change direction (not so once the product is built).

But how do you protect against broken promises? Bob Levy, CEO of Virtual Cove, explains to customers up front that roadmap change is inevitable. “That’s why we’re having this conversation in the first place,” he tells them. “We make our decisions based on input from people like yourself. You have the power to influence the roadmap, as do others, so of course it won’t be the same when it’s done. Customers are frustrated insomuch as they think a roadmap is a static thing.”

Chapter 8 provides advice on sharing your roadmap with customers and other stakeholders and on how to present to these groups to get their buy-in.

A Roadmap Should Not Make Promises a Team Cannot Deliver On

Problem: Your stakeholders and customer expect a firm commitment on dates for your product releases

In today’s fast-paced and constantly changing world, there is a natural desire for certainty and predictability. In the past, roadmaps often read like a Gantt chart, with specific dates and commitments of features. However, because we now live in an agile—arguably post-agile—world, such commitments and dates are often missed, leaving customers and stakeholders disappointed.

Symptoms of this particular problem include:

• The roadmap includes a list of features and dates that are frequently unable to be realized.

• A product team is scrambling in the last few weeks/days toward product release.

“We always seem to overpromise and underdeliver.”

“It feels like we’re constantly playing catch-up.”

Solution: Prioritization is critical to deliver on your commitments

A roadmap is a strategic document that should offer guidance to your teams on what to focus on. If your team has a track record of missing commitments, there’s likely a prioritization and even an estimation problem—that is, the team cannot properly estimate what they can get done in a specific timeframe. Carol Meyers reiterates this point: “I think it’s really hard for people to know how long it’s actually going to take them, and I think it has led to a lot of discord among groups within companies about, ‘You said you would deliver,’ and then ‘Well, we found out that technically this was a lot harder than we thought.’”

When teams are building something new, regardless of their skill set, it’s a challenge to accurately predict the length of time it will take. But precise prioritization can help focus the team so they can make the most effective use of their time.

A Roadmap Should Not Require Wasteful Up-Front Design and Estimation

Problem: Time spent estimating design and development efforts takes time away from actually implementing them

Symptoms of this particular problem include:

• The roadmap includes a list of features that need to be “sized” or “estimated” for design and development.

• A product team is scrambling in the last few weeks/days toward product release.

“My engineers hate giving estimates.”

“We waste too much time arguing over how to solve something.”

Solution: Let the teams determine the solutions, and allow them to solve the problem

While we realize that some teams need to clearly define the product specification and deliver on it in a specific timeframe, the roadmap is intended as a strategy document. A project plan or a release plan may be better suited to outlining specific dates.

A Roadmap Should Not Be Conflated with a Release Plan or a Project Plan

Problem: Your team looks at the roadmap as if it were a project plan listing when features will be released

A roadmap is a strategic artifact, whereas a release plan is a tactical artifact about execution.

Symptoms of this particular problem include:

• Your release plan looks like a Gantt chart with specific delivery dates.

• Your roadmap consists of a list of features and dates.

“I try to keep my roadmap at a high level, but Sales always demands dates.”

“I don’t know how detailed my roadmap should be.”

“How does my roadmap fit into our Agile methodology?”

Solution: Commit to outcomes rather than output

If you’re paying attention, you’ll notice this is the same solution to a different problem mentioned earlier. We find that inexperienced product pros often jump to the solution. After all, we’ve been acculturated to have “the answer” since we were in kindergarten. It’s a natural bias we all have—we want the answer and we want to be problem solvers. The issue is that we go right to the solution (output) rather than do what experienced product pros do, which is focus on the problem (outcome). To take it a step further, the smartest product pros ask what outcomes they’re seeking and drive toward those.

Note

A roadmap is not a project plan.

Figure 1-3. A roadmap begins with a vision of where you’re going and helps lead you there, with iterations and stops along the way

Summary

Properly done, a product roadmap can steer your entire organization toward delivering on the company strategy. A good roadmap, though, is not so much a project plan as a strategic communications tool, a statement of intent and direction.

For many product people, product roadmaps have become a painful exercise in futility. The pace of change; lack of clear vision, goals, and internal alignment; and an excessive focus on feature and date specifics quickly obsolete their painstaking work, and this leaves them asking why they should invest the time in a roadmap at all.

In this chapter, we’ve laid out requirements for relaunching product roadmaps for a lean and agile world, including providing strategic context, focusing on value, embracing learning, rallying the organization, and getting customers to buy in. And all of this without making promises we can’t keep, spending excessive time in up-front planning, or conflating the roadmap with more specifics-oriented documents like release and project plans.

Is this heroic feat possible? We’ve seen it in action at dozens of organizations around the world.

By first establishing guiding principles (including a product vision tied to your company vision and goals that will help measure your progress), by focusing on outcomes rather than features and dates, by prioritizing based on return on investment (ROI) in meeting your goals, by using input from all of your stakeholders to drive alignment, and by planning for and clearly communicating ongoing change, it’s possible to set clear direction and simultaneously embrace the uncertainties inherent in product development today.

With that in mind, let’s take a look at the components of a great roadmap and how they can help you make great products.