Chapter 9. Presenting and Sharing Your Roadmap
What you’ll learn in this chapter
Why to share internally
Why to share externally
Risks of sharing
Whether to develop multiple roadmaps
How to present your roadmap to stakeholders
Every stakeholder will benefit from a view into what’s coming, and an opportunity to contribute
One of the chief functions of a product roadmap is to get everyone excited about the future. To accomplish that, you have to tell the story.
By now you know a product roadmap is not a release plan, nor a backlog, nor a list of features. The components we’ve presented give you all the raw materials in place to develop a good roadmap
If you have been following this book chapter by chapter, you now have all the raw materials in place to develop a good roadmap. This chapter will walk you through the process of sharing and presenting it. Once you’ve shared the first cut of your roadmap, as with most iterative processes you will probably need to revisit and revise parts of it, so we’ll also cover what to expect from that step.
The Risks of Sharing
Overpromising and Underdelivering
A lot of folks worry that anything they share on a roadmap will come back to bite them later—fearing that, as Drift CEO David Cancel, puts it, “I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.”
But Janna Bastow, CEO of ProdPad, argues that “as long as we’re open and honest about our priorities, customers are actually very forgiving. We hold onto the feedback we get and reach back into it to guide the way we approach their problems—and our customers know that. Roadmap conversations have helped us understand what resonates with people, and that helps us position our launches down the line.”
“The reason the product team has a roadmap is partly because it’s a sales tool, a communication tool to help customers understand what’s coming so that they can plan for it. We actually could not land contracts without some level of comfort developed in the customer around that.
“What we put on the roadmap is: we’re going to have an initial version of this thing ready to use. That did a couple of things. For us, it prevented us from needing to build the whole thing up front and figure out the entirety of it. For them, it let them look at a timeline and say, April 1st they’re gonna have something we can look at. And it prevented either of us from having to agree that this thing will solve all future problems.
“So what’s the purpose of the roadmap then?” she asks. “For us it was to allow the customer internally to align around the idea that we’d given them the date, without actually tying the delivery of something to that date.”
This is very similar to the idea of themes, presented in Chapter 5. You want to communicate your direction and intent clearly without committing to deliverables that may not be achievable or may not even be the right solution to the problem in question.
The Osborne Effect
Announcing future plans too early can also slow down current sales as people may decide to wait for the next version or upgrade. This is more prevalent with hard goods that can’t upgraded with a simple software update, increasing the perception that the current product will soon be obsolete. This phenomenon became known as the Osborne Effect after sales of the Osborne 1 computer fell sharply in 1983. Founder Adam Osborne had pre-announced new models that would outperform the existing model and dealers canceled existing orders for the first model in anticipation. The new models did not appear quickly enough and the company soon declared bankruptcy.
Competition
And what about the competition, you ask? Isn’t it risky to tell the market what’s coming? Sure, there may be good reasons not to put everything on your roadmap, especially if some of those themes can indicate a product direction that may further differentiate you, but if you’re simply making existing product areas more robust, it may be OK or even necessary.
For example, imagine you are a component manufacturer for the mobile device industry. You sell specialized chips for phones, tablets, watches, and the like. Your customers—the makers of these devices—plan their products out many months or even years in advance, including the performance specs, price points, and unit volumes. If you want to win their business, you have to be open about those kinds of details with them on their timeframe. To quote Sasha Dass, Technical Program Manager at Analog Devices, “In our business, you better not show up to a customer meeting without a detailed roadmap.”
This example has less to do with the pace of change in the electronics industry (which is accelerating all the time), and more to do with the commitment a customer is making to your product and to your company when they buy. The electronic device makers in question here need to be able to count on your company to deliver on your roadmap over time, or they risk missing their own launch dates and sales forecasts. Millions of dollars are at stake, and they want to know you will be there for them.
Samuel Clemens, VP of Product Management for InsightSquared, says, “The roadmap is never ever allowed outside the building. However staff can use the roadmap to respond to a customer that, ‘yes, something is on our short-term roadmap; or: our PMs are looking for more input on that so would you mind doing a call with one of them?’”
If you want your sales team to focus on selling what’s in the warehouse right now, but you also want to position things properly for changes you know are coming, Bill Allen, former Product Manager for Bose, has some sage advice. If someone asks about, for example, support for an emerging standard, tell them, “It’s a great thing. It’s fantastic. You’ve all heard it, you’ll all love it. But let’s really look at the reality of this. Right now, the ability to use this feature is a rare occurrence. The chances of you actually being able to enjoy it are maybe 5%. Do you really want to say that that’s a must have feature just yet?” You may still choose not to discuss future products, but you’ve established that you’ll be ready when and if this new standard becomes important, while removing the customer’s fear of buying something without it now.
So there are advantages and risks in sharing a roadmap externally. Given that, how do you decide what, if anything, you should share? Janna Bastow created a neat chart that illustrates, by role, how much detail and which initiatives you should share (see Figure 9-1). In general, the further away from your core product development team you get, the less detail about features, functions, and dates you should provide, and the less you probably want to share about brand-new product directions and internal infrastructure work. (Refer back to Jeff Bussgang’s story at the beginning of the preceding section, though, for an exception!)
Who should see your roadmap?
Figure 9-1. Janna Bastow’s chart showing how much detail and which initiatives you should share, by role
Multiple Roadmaps? Not So Fast!
As we’ve outlined, most organizations have multiple stakeholders who would benefit from a view into your direction and strategy. The trouble is, each has different things it cares about most.
So do you need to prepare a different roadmap to present to each group? And if you did, wouldn’t that defeat your efforts to align the organization around a common cause? The answer is to build the specifics each group wants to see on top of the common foundation of your vision, strategy, and themes.
If your roadmap is expressed in a slide presentation (as many are), this might mean the first four slides apply to all audiences, but there is one additional slide dedicated to each group. This is where the complementary information that provides additional context and detail to the roadmap itself comes in. Keeping these separate but including them in the same document makes a clear and direct link from the overarching story to the details a particular stakeholder group cares most about.
With this modular approach, it’s not a question of whether to share your roadmap, but of which portions you show to whom.
Presenting the Roadmap to Stakeholders
OK, you’ve shared your vision, your strategy, and some vague ideas about themes, timing, and so on. Terrific. But then come the questions. What features are you actually going to ship? What are the release dates?
What can the sales team demo at the next big trade show? What are the revenue projections? The dependencies? Risks? The channel strategy?
You’ve piqued your audience’s interest, and now they are hungry for details. Can you answer them? Should you? The level of detail you give in the answers to these questions depends on who is asking and your confidence in your information.
It also depends on a good collaborative back-and-forth between you as the responsible product person and each stakeholder. We outlined the primary components of the roadmap in Chapter 2 and described the secondary components as optional. Next, we describe which stakeholders care most about what optional data and how much detail to provide. We also outline a third group of complementary information that, while not formally part of a product roadmap, can provide important context to your discussions with these stakeholders. We’ll discuss ways to incorporate or at least acknowledge the information that will help drive alignment across your organization and with customers and partners.
Sharing outside your core team may sound risky. We’ve found, though, that as you get into these discussions, your roadmap will change for the better. It will mesh symbiotically with stakeholder needs, leverage serendipitous events, generate new ideas, and most important, drive alignment by getting all the groups on the same page (literally, if you print out your roadmap!).
What the Development Team Needs in a Roadmap
In a software company, your development team consists of the engineers, designers, testers, and operations people who will actually build and deploy your product. (We would generally include your technical support team in this bucket as well with regard to information needs.) In a hard-goods organization, the design and manufacturing teams perform a similar function. These sorts of folks need concrete information on which to base project schedules, resource plans, technical architectures, and supply chains.
Your high-level thematic roadmap is great context for them, but it is not enough by itself. These teams want something that begins with your high-level story but then embellishes it with details including likely features, stage of development, scalability expectations, dependencies and risks, and even information about the technical underpinnings of the work they will be executing on (see Figure 9-2).
Bill Allen, former product manager at Bose says, “Engineering cares about your product roadmap because, oh we’re moving into Bluetooth? We’d better do some research into Bluetooth. Oh speakerphone? We know about microphones, and we know about speakers, but we don’t really know about speakerphone or how to integrate them together in a speakerphone. There’s going to be a new disc formats? Is it going to be Blu-ray or is it going to be HD DVD? How do we decide? When do we need to make that choice? Technology roadmaps and decisions are always informed by the product roadmap.”
Figure 9-2. Product Roadmap for Engineering
Secondary Components
Features and solutions
Though we avoided committing to specific features for most audiences in Chapter 6, the development team needs some idea of what they will be building in order to plan their work. A short list of features you believe will effectively address the market problems laid out in your themes will add the necessary level of concreteness to your roadmap, while allowing the development team to ballpark the effort involved and negotiate with you over scope and timing.
When you first show this roadmap to your team, you are looking for their feedback about what is feasible, not dictating what must be complete by certain deadlines. For example, you may have seven ideas for features that you believe will help with your “time savings” theme. However, the team may come back after scoping each and tell you that there is room for only the first four in the next quarter. You can then have a productive discussion about whether to hold the release until the following quarter to get all seven, have two releases, or ship those four and move on to another theme.
Stage of development
As we discussed in Chapter 6, the stage of development your product is in dictates certain things about your priorities, so being clear about the product’s stage in your roadmap sets helpful context and expectations for the development team.
In the earliest stages, the product is under active development and may not have any users outside the company while the basic capabilities are being laid down. Later, the roadmap may be changing rapidly as early customers provide feedback on unmet needs. Custom features for large customers may become necessary in the growth stage, and the later stages may focus entirely on compatibility updates and bug fixes.
Armed with information on what stage you expect the product to be in at various points in time, your development, operations, and/or manufacturing teams can plan resource allocations accordingly.
Product areas
In addition to ensuring coverage across the key parts of the product as described in Chapter 6, development teams often use product areas as an organizing principle for their internal teams. One team may focus on the administration UI, for example, while another focuses on search, and a third on transactions.
Including this information on your roadmap in the form of tags, colors, or swim lanes makes it easy for your development team to map your roadmap to their organization, facilitating collaboration.
Complementary Information: Platform Considerations
Scalability
Engineering, operations, and manufacturing teams need a good understanding of the volumes you expect and when you expect them. This is obvious in manufacturing, where plant capacity can be a gating factor to growth. In software, however, the ability to accommodate a certain volume of users—known as scalability—is often overlooked by product people.
Think about it this way. A prototype of your product can probably be produced very quickly. It will look great and perform well as long as there are only a few users on the system at a time. On the other hand, a system can theoretically be designed to support almost any number of users, but it will take proportionately longer to design and develop. If you are specific about how much usage you expect at what stage of the product’s life, you and your development team can find the right balance between those two extremes for each stage, reducing the risk of failure without overengineering the solution.
Technology and infrastructure
As the product grows in popularity, it also usually becomes more complex with the added features and functionality demanded by its expanding customer base. This puts strain on the underlying technical infrastructure as it is asked to support features and functions for which it was not originally designed.
Imagine you buy a starter house with one floor, one bathroom, and no garage. Over time, as your family grows, you begin adding rooms, but eventually your lot is full, and you can no longer expand outward. You need to add a second floor, but you discover that your foundation wasn’t designed to handle the additional weight. You need to make some changes below ground before you can expand upward.
In manufacturing, changes in volume, design, or materials may require retooling at the plant. In software, this situation is sometimes referred to as technical debt, and may require rewriting or refactoring parts of the code. And if the problem is more extensive, it may require a rearchitecture or replatforming before more features or more users can be added effectively.
This sort of work is hidden entirely from the customer but may sometimes require a large percentage of the resources available for roadmap work. It’s best to work with your internal team to identify this technical and infrastructure work and build it into your plans along with the more visible work it supports. Some teams create a separate row on the roadmap for this supporting work, assigning them their own themes or concrete deliverables, while others create a separate slide or document for it.
Complementary Information: Project Information
As we stated in Chapter 1, a roadmap is not a project plan. When you’re working with the team in charge of the actual project, though, it can pay to surface key project elements such as schedule, resources, dependencies, risks, and even status. We recommend working with a partner from your development team (a project manager, team lead, engineering manager or someone with similar responsibilities) to develop and present this information briefly after you’ve set the stage with the primary and selected secondary components.
Schedule and resources
The lines, arrows, and connectors of a Gantt chart do not form a good roadmap. Nor do the burndowns, burnups, and velocity trackers of an agile release plan. Your development team may use these or other tools, however, to manage and communicate about the projects that will eventually allow you to deliver on your roadmap. Working back and forth together between the roadmap and the project or release plan will allow you to check your assumptions and be more realistic about dates while challenging the team to deliver the most value.
Dependencies and risks
If an item cannot be solved for or built until something else is solved for or built, you must factor it into your sequencing. For example, imagine you’re building an application that helps youth athletes keep track of their progress in a sport. One theme on your roadmap might be “Record practice performance” and another one might be “Measure performance over time.” A user would not be able to see a report on their performance over time without first having recorded their performance for each individual training session, so the sequence is dictated by this dependency.
In addition, dependencies among teams are the most common sources of delay in project schedules. It’s therefore important to identify those that could affect your ability to deliver on your roadmap as early as possible so they can be prioritized, and so contingency plans can be developed.
Other sorts of risks include resources that may be in short supply, unproven technologies or materials, untested suppliers, unpredictable usage patterns, even unproven assumptions about the market.
The example roadmap slide in Figure 9-2 has a single row for this, but many roadmaps include an entire slide on risks and mitigation plans.
Status
On-track or behind schedule; green, yellow, or red: these sorts of status updates on the projects related to your roadmap should be the subject of frequent discussion with your development team. They are not part of the product roadmap, but as it becomes clear over time what solutions will be delivered when, they do inform it. Dates may shift or the list of six features for the next important theme may become four. Depending on how detailed you’ve been about dates and features, these changes may or may not need to be reflected on the roadmap—but you as the product person must understand their implications.
What Sales and Marketing Need in a Roadmap
Whereas your development team wants hard details about what they have to build, your sales and marketing teams have their own sorts of planning to do—usually around generating revenue. After you’ve set the stage at a high level, your roadmap should help them understand what advantages your product will provide in terms of increased value, tied to critical dates on their calendar (see Figure 9-3).
Secondary Components
Stage of development
Just as the development team benefits from understanding the stages of your product’s development, so too do the sales and marketing teams. This principle was brought home to Bruce McCarthy very strongly when a sales VP he worked with surprised him by asking to delay the launch of a new product.
Bruce had assumed that the revenue opportunity presented by the new product would provide a welcome boost to the VP’s efforts to make his numbers as the end of the year drew close. This VP had the experience to know, however, that an untried product, no matter how well conceived, was bound to go through some rough patches as the sales pitch, pricing, packaging, and materials were refined. He also knew that a new product required an investment in training for his people, which meant time away from closing deals.
In the critical year-end period, this savvy manager wanted to maximize the output of his team by focusing their time on selling proven products with an established sales methodology. He was happy to launch a new product in the first quarter when the pressure was off and the team would be going through annual training anyway.
Leading up to that January launch, Bruce was able to convince his sales VP to let him work with one sales specialist on an early access, or beta, program for the new product. Marketing and sales teams usually care about a product when they can begin talking about it, and with a beta program this actually comes before a full launch.
Even a rough idea of the timing of these milestones will allow your sales and marketing teams to plan promotion and sales training calendars with your product in mind. Later stages of the product’s life may inform sales quotas and campaigns designed to open up new markets.
Many products take months or years to generate significant traction because the sales and marketing teams are not prepared to generate or convert demand when the product first becomes available. Collaborating with these teams on launching activities plans starts with the roadmap.
Figure 9-3. The roadmap you share with your sales and marketing teams starts with the same timelines and themes as all views of the roadmap, then adds details of interest to them, including stage of life, success metrics, how particular steps in the roadmap affect them, and external events that coincide with releases
Target customers
As your product’s capabilities grow, you may be able to expand into new markets and serve new types of customers. In fact, once you have a product out the door (as we explain in Chapter 4), expanding your addressable market is one of your most effective growth levers.
The roadmap you share (and codevelop) with your marketing and sales teams should describe when the problems you’re solving will allow you to effectively serve new customers. “Prosumer features” or “Localized for China” are the sorts of things your internal go-to-market partners will view as opportunities, and you will want to give them time to prepare to take maximum advantage
Confidence
Salespeople are speaking directly with customers every day, and they are eager to please. You can easily imagine how something on the roadmap could work its way into a sales conversation, so it’s important to provide context about how firm the information is. As described in Chapter 6, you can easily manage these expectations (and keep casual conversations from becoming promises) by adding a confidence percentage to the items (or timeframes) on your roadmap, indicating how likely they are to be delivered in that timeframe (or at all).
Marketing teams planning for the next quarter’s campaigns will also benefit from an indication of how certain you are about what’s coming in that timeframe. They’ll know not to book an expensive spokesperson for a special event built around something on your roadmap until your confidence is above 80%.
Features and solutions?
Your marketing and sales teams may have good intelligence on what it will take to meet these market segment or competitive positioning needs. So it makes sense to involve them early and give them at least a little visibility into what features you have in mind to fulfill those needs. Just be careful about how specific you are. Although these teams are internal to your organization, it is their job to speak to customers, and you don’t want them to get ahead of your certainty. Use words like likely, probable, and tentative, and make liberal use of your confidence percentages.
Complementary Information: External Drivers
While you want to reserve as much flexibility as you can for your development schedule, there are many types of external events over which you have little or no control. Regulatory changes may drive compliance requirements, industry events may be opportunities for new product announcements, user conferences may require demos of forthcoming enhancements, and competitor announcements may drive changes to your priorities.
Mapping these sorts of events out as well as you can in advance can help ensure the best timing for items on your roadmap. Again, they are not part of the roadmap itself, but including them as supplemental information can help the marketing and sales teams prepare for these events. (They can also help you prioritize roadmap items.)
What Executives Need in a Roadmap
Executives and members of the organization’s board of directors are generally concerned with the investments the company is making and the expected return on those investments. Their interest in and tolerance of the more operational details of all of this are inversely proportional to their trust in the team’s ability to execute. In other words, if they are digging into the details, it’s because they think something is wrong.
Generally, then, you want to limit the roadmap information you provide to these stakeholders to the high-level initial material on vision, strategy, and problem-solving themes. It is smart, of course, to have all of the details on hand for those occasions when an inquisitive board member develops some concerns. Even better, you can anticipate those concerns by previewing your high-level material with these stakeholders and asking for feedback or questions in advance. (This is another use of shuttle diplomacy, discussed in Chapter 8.)
Complementary Information: Financial Information
Market opportunity
Some of the most compelling internal roadmaps describe how each step along the journey brings them closer to success in capturing their market, driving up their revenues, and generating profits.
This might take the form of a target customer, as in the sales and marketing version of the roadmap, or it might include explicit revenue and profit targets. (See the Contactually roadmap in Figure 9-4 for an example of an objectives-driven roadmap.)
Profit and loss
Some product people act more like general managers for their particular product, carrying profit and loss responsibilities they must report on regularly. Even where this is not the case, executives and board members often want to understand the general magnitude and timing of anticipated revenues that will pay back the investment they’ve made in a particular product development effort.
Business plan pro formas are not part of a roadmap, but adding rough revenues and a projected break-even timeframe can be useful to help this audience understand what you feel is required to reach a certain level of financial results.
Figure 9-4. A roadmap for your executives or your board will help you make the case for investment in your product by showing how your planned enhancements will expand your market opportunity
What Customers Need in a Roadmap
We’ve discussed the pros and cons of sharing, including disappointments, competitive concerns, and Osborning, but it’s worth a final note here on what customers really need from you in a roadmap. They might ask for details about features and dates, but in most cases that’s not what they really need.
Bruce enjoys recounting the story of a dashing Spanish customer who challenged him to reveal whether a particular feature would be included a particular release. One of the themes on Bruce’s roadmap at the time suggested that possibility but, in full fencing stance, this reseller demanded a commitment in front of a group of other customers from around the world. He didn’t quite throw a glove on the floor, but things did go a little quiet in the room as Bruce considered his answer.
“I understand why that feature is important to you and to your users,” he said, projecting his voice a little for the crowd. [This was true. He’d had conversations with many such end users.] And it’s one of the things we’re looking into as a way to allow you to [solve a particular problem] as I mentioned in my roadmap presentation. However,” he went on as more and more people halted their conversations to listen in, “we want to solve the problem in the best way possible for everyone, and I don’t want to limit the team’s options by specifying a particular approach too early.”
This got a general murmur of approval, but it did not completely satisfy Bruce’s challenger. “When will you commit?” he demanded after a beat. Fortunately, Bruce knew they could be pretty confident about the content of a particular release a quarter ahead of time, so he was able to provide a general answer along the lines of “most likely by the end of the year.” As others went back to what they’d been doing, he spoke to the man individually and offered to help manage expectations with his executives and users.
Customers and prospects can be this demanding, and much more at times. Many prospects will refuse to sign—and long-time customers will refuse to renew—if certain features are not committed to. How you handle this depends on your business, but we encourage you to ask what your stakeholders are really wanting you to commit to. Is it really a particular feature or a specific date? Or is that they want to know you have skin in the game, too? Or that you are listening to them? Or that you’ll give them more information when you have it? Offer to help them with their real need as Bruce did here, and maybe they’ll give you some slack on the roadmap.
And remember that the more commitments to specific deliverables you make on the roadmap, the less flexibility you have to adjust course when the winds change—and lack of flexibility is not in your customer’s interest either.
Figure 9-5. The roadmap you share with customer will be greatly simplified. It should not include the details internal stakeholders need but instead focus exclusively on the value these customers should anticipate you will deliver to them in the future. And if you have more than one type of customer, you will want to divide up the roadmap along those lines, showing only what’s relevant to the group you are presenting to at the moment.
The Roadmap Presentation
You’ve done your homework, and now it’s time to present your roadmap. If you’ve developed your guiding principles, uncovered and solved for customer needs, and prioritized your ideas, you probably have something pretty great at this point, but now it’s showtime.
How do you ensure a good reception for your ideas?
Preparation
Here’s a short roadmap presentation prep checklist:
Identify your audience: Peers? Executives? Have they seen the roadmap before? If so, what input have they had?
Clarify your goals for the presentation: What do you need from this meeting? Are you looking for input on an early draft? Alignment on a particular aspect? Or just informing people of what’s coming?
Determine what your audience cares about: What level of detail is necessary? Do you need to summarize the roadmap details to only the high level? Are you presenting a portfolio of products?
Assemble your components: Pull your product vision, business objectives, themes, and timeframes all together. Consider which secondary and complementary components are necessary based on your audience (#1) and what they care about (#3).
For your presentation, the following sequence might be useful:
Start the presentation with the why, and be sure everyone is on board with the product vision before you move on to details. Cover recent progress—what’s been completed since last time? Don’t forget to include emotion! Use quotes or anecdotes from customers on how the changes to the product positively impacted them.
Show what’s in the near term and clarify what critical needs justified the prioritization and aligned with the business objectives. Add stories of sales, support, and customer requests to help humanize the product and give meaning to why you’re doing this—beyond making some chart continue to move up and to the right (emotion + data + stories = win).
Propose what’s in store for a longer term and continue to reinforce how this will align with the company’s objectives.
Case Study: Chef.io’s Roadmap Presentation
Dropping Like a Lead Balloon
In 2013, when Chef.io CEO/founder Jesse Robbins presented a roadmap to his team with a phrase akin to “Here’s what we’re going to build this year,” he expected the team to get working and execute on the initiatives he’d laid out (see Figure 9-5).
As the company grew and hired more staff to define, build, and deliver the product to market, as well as respond to changing market conditions, however, they struggled to match what was laid out on the roadmap. In a few years, the product and engineering team realized that they would not meet those expectations and deadlines. They wouldn’t be able to deliver what was on the roadmap for the upcoming quarters. Further, Chef.io customers weren’t happy: one thought they were getting feature X and another thought they were getting feature Y, resulting in a lot of missed expectations and disappointment.
When a team is small and the product direction is very top-down, this phenomenon is quite common. It makes sense in theory: those who started the company and established the initial product vision lay out the roadmap for the future versions. In practice, though, those now-executive-level CEOs, CTOs, and CPOs have become more removed from the specific details and challenges of the product team, so they overestimate what can be accomplished and by when. The roadmap needs to account for this growth.
Figure 9-6. Chef.io’s 2013 roadmap
Making Changes
Julian Dunn, the Chef.io product manager, convinced the team to make some changes. Like any smart team, they revised their roadmaps and changed both the internal as well as external versions. Using ProdPad to manage their internal roadmap, they arranged the themes on cards, relating each theme to a business objective, in a Current–Near Term–Future layout (see Figure 9-6). Clicking into the card reveals more detailed information, but the theme level works well for the team. For example, the card that reads Minimum Configuration Installation essentially is a way of asking, “How can we make our products easier for the cloud?” The related objective is to make a more cloud-based product (though, as of this writing, Chef Automate is an on-premise software requiring on-site installation).
To address the customer’s missed expectations, the product team turned over the ProdPad-based roadmap to the product marketing team, who pulled information from that to create a slide-based artifact suitable for presentation that offers up some framing of the roadmap to the audience (likely customers and partners).
Figure 9-7. Chef.io’s revised, theme-based product roadmap Chapter
CASE STUDY: Chef.io’s Roadmap Presentation
Slide 1 has an introduction and, more important, qualifiers and a disclaimer (Figure 9-7).
Slide 2 shows some of the metrics and recent progress, as well as defining three product development cycles: “Considering,” “In development,” and “Released” (Figure 9-8).
Slide 3 then shares information from the ProdPad internal roadmap. It collapses some of the “Near term” and “Future” time horizons, and while this exposes features the team is considering, it does not offer too much detail and is framed in a way that avoids a firm commitment on delivering these particular feature sets (Figure 9-9).
This portion of the roadmap can be used to get feedback from customers and prospects. If every customer reacts to a roadmapped theme (or feature!) negatively, the team may reconsider. To reiterate what we’ve said many times in the book: a roadmap is not a promise or commitment for a set of features.
(Slides 4 and 5 containing features “In development” and “Released” are not shown.)
Figure 9-8. Slide 1 of Chef.io’s roadmap presentation includes an introduction, qualifiers, and a disclaimer
Figure 9-9. Slide 2 shows key metrics, recent progress, and product development cycles
Figure 9-10. Slide 3 shares information from the ProdPad internal roadmap without overcommitting or giving too much detail
Summary
Sharing your roadmap helps obtain buy-in from a variety of stakeholders, even customers. Different stakeholders will look for different information on a product roadmap. A slide-based presentation can help you tell the story of your roadmap clearly and effectively. As with any good presentation, know your audience so you can frame and tailor the content to them, be clear about your goals, and assemble the components of your roadmap to get your key points across and the decisions and/or buy-in you need. A presentation flow that starts with why, covers recent progress, and then gets into the how, frames up the roadmap details effectively. You’re fast on your way to product greatness...until something changes, and of course, things always change.