A product or portfolio roadmap is a key tool in planning, looking beyond your current product deliverables to months and years ahead. But a roadmap can also be a helpful tool with sales people, prospects, and customers.

I once saw a presentation with a clever logic diagram for sharing the roadmap:

  • Do you want to delay your sale? If yes, then show the roadmap.
  • Do you want to delay the next release? If yes, then show the roadmap.
  • Anything else? Don’t show the roadmap.

Some companies do not share roadmaps. They want you to buy what they have now. They don’t want you to defer your purchase waiting for the “next big thing.” Apple is particularly closed-mouthed about future plans so journalists, bloggers, and analysts try to guess, as shown here:

image kuo_2013_apple_roadmap

(I like the logos on the left, don’t you? And I can just see their sales people saying, “Hmmm, iPhone 5s shows in the beginning of 3Q, so that’s sometime in May, right?”)

Companies like Apple keep their internal plans internal.

But many companies, particularly startups, find sharing the roadmap is a great way to promote and validate their innovation plans. Obviously you cannot do everything at once so a roadmap shows your market that you’re thinking beyond the current development iterations.

Existing customers want to know where you’re going so they can make their own plans. Which technologies and major capabilities can they expect this year and next? How will changes in your architecture affect their own plans? The same is true for potential clients; they want to see you’re in sync with their plans.

However, be very cautious of guarantees. Plans change; commitments change; market conditions change. And resources get reallocated. So the more your colleagues and your clients think the roadmap is committed, the more frustration you cause for product management, development, sales and marketing.

A roadmap isn’t a substitute for delivery. Many times, sales teams are frustrated by the slow pace of development so they sell “futures” hoping to persuade clients to buy now instead of waiting. They sell the roadmap as a commitment, not a plan. A roadmap, just like a sales forecast, is a plan that will likely change.

Most product leaders ultimately conclude the need for two roadmaps: one for internal use, shared with executives and development teams, and the other for external use, shared with sales people, analysts, and clients. The internal roadmap has more detail and more specific dates; the external roadmap offers major themes spread across quarters or half-years.

Even more ambiguous is the “now and later” roadmap. For example, this “roadmap” reveals current projects, near-term projects, and future projects. (Nice!)

image no dates roadmap
Source: http://www.prodpad.com/2013/01/roadmapping-without-dates/

The likelihood of change increases as plans move beyond the current set of work. Agile teams can be fairly confident in what’s in the current iteration or sprint, and perhaps the next few iterations, but next year? Who knows? But for your current plans to have any meaning, you have to know where you’re going with a rough idea of how you’re going to get there.

The roadmap is a planning tool that blocks out the next 18-36 months.  Give a summary in some form to your external audiences so they can see your plans. Or you’ll find your sales people and customers making stuff up (and that won’t be good!).


Join the conversation! 2 Comments

  1. Great stuff Steve!

    I would reinforce the fact that sometimes you just have no choice. You must share that “future” — and you gave some good direction about how to format and package it.

    Maybe some direction on how to analyze the product line and market and customer profiles and level of maturity of the account team and advise on how you’d forge ahead (or not) on creating a roadmap artifact to share.

  2. I’ve even been in places where we had 3 roadmaps: one for development (with lots of detail and aggressive dates), one for sales to use with prospects (with broad themes and no hard dates), and one for use with executives and current customers.

    The purpose of this third roadmap was to provide a bit more insight to people who need to know. Execs need to know so they can approve plans and coordinate across departments. Current customers, at least in enterprise software, need to know so they can plan their next upgrade.

    Neither of those two groups, though, can be trusted with the full details of features and planned dates because, as you say, these are subject to change and neither of those groups copes well with change. So they get an in-between level of detail.

    There is another reason why prospects and the general public should not get even the medium level of detail. Accounting rules say (or at least my accounting firm says) that if the customer signed a contract relying on anything specific you revealed in your roadmap, you cannot recognize the revenue from that contract until you deliver that thing.

    The only way around that is is to be sufficiently vague about specific features and/or dates that no one could reasonably call it a commitment.🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s