Navigating Pathways to the Future: Product Roadmaps Lead Their Readers in Multiple Directions

By Peter Longini August 10, 2007

Not only do product roadmaps fundamentally differ from one another in their appearance, scope, time span, and topic, they also differ in their audiences, their applications, and in their relationship to various company functions. Even so, extolling the value of product roadmaps has become a mantra of strategists and developers throughout the technology sector. At a recent invitation-only Pittsburgh Product Strategy Network Roundtable, a group of product strategists shared their benefits as well as their frustrations with the technique.

During the past ten years, roadmapping--the planning discipline involved in formulating tasks and timelines for product development and market launch--has become an integral part of the tool set for technology product management. Today, its value, both as a process and as a deliverable product, is uniformly acclaimed in the business community. It is only when the awkward question arises of exactly what a roadmap is and what its actual value may be, that the uniformity breaks down.

At a recent Pittsburgh Product Strategy Network invitational Roundtable, those divisions became clear as 20 experienced product strategists traded definitions, perceptions, advantages, and misgivings about roadmapping based on personal experience. The variations cited were exceeded only by the value each claimed to attach to the end result.

Map legends

Everyone affected by new technology has their own view of what a product roadmap ought to be, Innovation Works associate Jim Jen acknowledged during an opening presentation. Customers, investors, developers, sales teams, and other interested parties each have distinctive needs and business interests for knowing what the future holds. So there is no consistent format for roadmaps--they vary in essentially every dimension--and the processes by which those maps are formulated and revised vary as well.

Even so, Jen pointed out, roadmaps are powerful business tools. For example, they help ensure that the right product gets delivered to the appropriate target market with the right value proposition. They help to build confidence among key constituents, both within and outside the organization, affecting the company and its products. And, by pulling key people together inside the producing company, they improve efficiency and help ensure alignment among different functional areas.

Roadmaps are also dynamic--subject to revision in light of experience. In a previous assignment with a Silicon Valley software vendor, Jen recalled the evolution of the product roadmap in which release dates for various features of the product migrated from one quarter to another in response to market interest, technology sequencing, and development effort. But there were lessons learned. For example, customer experience with adoption and use would alter the priorities reflected in the roadmap; roadmaps which focused solely on development could lead to a trap affecting the product's service aspects, and too much selling based on the roadmap alone could be symptomatic of serious problems in the field.

The key, Jen noted, is for the roadmap to pass several litmus tests. For example, is the roadmap consistent with the company's overall business and product objectives such as market penetration, new segment entry, servicing current customers, and reducing business costs? Is there a clear basis for prioritizing the sequence of steps? Is the product actually delivering in terms of the company's business objectives, value propositions, and user experience? And who, exactly, is the roadmap's audience and how well is it communicating to them?

Side roads

'A product roadmap can't realistically go out much more than three or four years because the markets change,' Cellomics product marketing director Judy Mascucci noted. 'But it should align with what do you want to be when you grow up. Your vision isn't to be a perfect company next year; your vision is to be a perfect company in 20 years. This is what we think it will look like in five years and in ten years,' she said.

'When you lay out the roadmap, it relieves some of the short-term pressures to build it all now,' Jim Jen replied. 'If you don't have a roadmap, people are going to ask why a particular feature isn't going to be in the next version. If you show them the plan, and they say they really want that particular feature, you can ask them: what would they want to trade off?'

Focusing on the problem rather than the solution can also be advanced by roadmaps. 'A lot of stakeholders jump right to the application model they want,' Jim Taylor, director of platform strategy with Strategic Management Group observed. 'Try to elevate the discussion. Instead of saying 'I need that report module,' it would be more edifying to say 'I really need to identify the contract price variance. How are we going to do that?''

But who, exactly, should that conversation take place with? According to IBM's program director Mark Sherman, a lot of people find a key application for roadmaps is communication with customers. But to Judy Mascucci, a company's sales force, despite its frequent customer contact, should not be part of the conversation at all. Why? Because in those conversations, they may incline toward selling something the company later decides not to develop.

It is fundamentally a question of how confident the company is in delivering the product envisioned on its roadmap, she noted, and the answer varies.'We actually launched something last September that will be delivered in June because we had very high confidence we'd be able to add it to the existing product,' she said.'But there are other things where we don't want anything in public until we are more confident that it would actually become a product.'

Jim Taylor's company, SMG, shares its roadmaps with industry analysts, and in rare cases, with specific partners or clients. But those conversations only occur at the company's most senior levels. Internally, however, it's a different story.'For me, it's been a powerful tool because we have an organization that's been through a merger. And with clashing cultures of old and new, it helps everybody say 'no, no, no; this is what we're doing.' It's a powerful internal communication tool.'

Likewise, Mark Collins, senior product manager for Cellomics, acknowledged that in the past, his company had used roadmaps to solicit feedback from key customers, but only on select portions of the roadmap.

'The customer probably has a roadmap of his own,' Union Switch & Signal's Brian Cornish observed. 'If what you're showing doesn't at least go in the same direction as theirs, you may not be able to support them going forward.'

'In three or five years, a roadmap really becomes a positioning tool,' Rich Haverlack noted. 'Think of it in terms of where your competition is going to be at that point in time and where your customers are going to be.'

The voyage

Perhaps symbolically, all of IBM's roadmaps climb sharply up and to the right along their timeline.'But it's not necessarily the document itself that's interesting,' according to Mark Sherman, 'The journey is more interesting than the destination. It's the process by which you got that document: Am I serving the right market? Am I delivering at the right time? What are my tradeoffs? Is that where we'd like to go? What questions do I want answered in order to build a product roadmap? Features vs. usability? Market needs vs. what I need to accomplish internally? Have I done the segment selection appropriately so I know that when I build a roadmap, I'm going to the right place? What's the relative priority of various streams of revenue? What's my market competitive position? What are the gaps in features, functions and usability so I can close those gaps? What themes do I have associated with different phases of the journey? What time frame should I be talking about as I carry out this thought process?'

Another benefit, according to Jim Taylor, is that a roadmap can help you avoid revisiting decisions you've already made, second guessing yourself can paralyze an organization. But to Cathy Brennan, IngMar Medical's product manager, it's a matter of using scarce resources more efficiently.'When you have one person that wears multiple hats, you need to make sure he's focused on what really needs to happen for this next release, not the one he'd really like to work on,' she said.

However don't expect too much from a roadmap, Don DeLauder, Medrad's director of product innovation, cautioned. 'The map is not the territory; they are just maps. There are a bunch of different roads to get someplace. You create this map and maybe it's a way to get there, maybe it's not. You should also do a competitors roadmap and predict what their roadmaps are; you might be able to say 'hey, these guys are going to be here in 2006 or whatever, and what are we doing?''

At Medrad, in addition to product roadmaps, a separate type of roadmapping process has emerged during the past two years, according to DeLauder. 'Technology roadmaps that tell us, outside of our own products, what's going on in the world of technology that could be interesting. We predict which ones are going to be viable and in what time frame. Then we take those technologies and use them as opportunities to satisfy certain predicted market needs.'

'Five or six years ago, our roadmapping was simply sales forecasting: how much of that product is going to be selling in five years? Now, roadmapping has evolved to: where are the markets headed? And what are we going to do about that?' DeLauder said. 'The world of technology can leverage opportunities for you. That's how we started down the path of doing technology roadmapping.'

Copyright (c) 2004 Pittsburgh Product Strategy Network. All rights reserved.

Categories: Working with Development
Peter Longini

Peter Longini

Peter Longini is Managing Editor of Inside Product Strategy, published by the Pittsburgh Product Strategy Network. The PPSN was founded in 2002 and serves nearly 800 technology product commercialization managers and executives in the Pittsburgh region. Contact Peter at plongini@nauticom.net.

Looking for the latest in product and data science? Get our articles, webinars and podcasts.