There's a great post about dysfunctional product roadmaps at Product Beautiful. I'll add a couple of other types to the list:

  • The Hatch: Much like the TV show Lost, the roadmap hints vaguely about big amazing things to come. Don't believe a word of it. There's no grand design, just someone using these portentious-sounding pseudo-revelations to disguise their uncertainty about where the plot is headed (i.e., nowhere). Similar to "the Zen Master," but more intentionally misleading.
  • The Enabler: The roadmap is just an attempt to mollify "stakeholders," which in this context means people with such an aggressive, unbalanced sense of self-importance that you could imagine them waving a sharpened piece of wood under the noses of anyone who dares tell them "Boo." These "stakeholders" could be internal (i.e., bigwigs) or external (customers and partners who earned the label "strategic" through unrelenting pushiness). There is no chance that the company can deliver on these promises, but no one has the cojones to do anything beyond pretending that everything will work out in the end, so please stop all the yelling.
  • The Vendetta. The competition defines the roadmap, which is a series of projects designed to counter whatever the competition is doing, or more accurately, may be doing. Anyone paranoid enough to define their roadmap in this fashion is likely to exaggerate competitive threats, far beyond what other vendors are actually contemplating, or even capable of delivering. Nevertheless, if customers are susceptible to the competition's guile and trickery, whatever countermeasures you build into the roadmap are, ipso facto, something that customers already want to hear. If a particular customer asks for something not contemplated as part of this slow-motion St. Valentine's Day Massacre, you need to find some way, any way, to make it sound as though it's on your hit list.

Whatever the species of dysfunctional roadmap, they're all counterproductive. As Product Beautiful says, the core problem is an unwillingness or ineptitude at telling people what they don't want to hear: "Depending on the political dynamics of your organization, it can be hard to push back on stakeholders who aren’t used to hearing 'no,' even for the right reasons."

Unfortunately, you do have to say no, quite frequently. Plus, you're not the only person who has to say no. Salespeople have to manage expectations. Support needs to give sensible answers about plans to fix, add, or simplify functionality. And so on. 

Most importantly, you have to make it clear what business you're in, and by extension, not in. I have a lot of respect for companies who are willing to say, "No, that's not what we do," instead of, "Well, maybe, if the money's right." For example, doesn't create vertical versions of its products. The money might be extremely attractive, but understands the larger cost of diluting its value proposition and its ability to deliver. Better to stay on track with the roadmap that they have, instead of forking it several times.

Admittedly, it's hard to say no, especially given the twists and turns of fate. Who knows how things will turn out? The uncertainty of the future aside, lack of total foresight is not a justification for creating a useless or misleading roadmap. In fact, your customers and partners will be happy if you're honest about the elements of the roadmap you can't predict, as long as you're clear about the general direction in which you're headed.

From the customer's or partner's perspective, the roadmap is important for two reasons:

  1. Ensuring projects stay on track. In every project plan, there's some amount of time in which to fold in technology that's not initially available. Some of it may be of secondary importance, so there's no problem adding it later. Other technology may be needed ASAP, but clever project leaders can manage around these gaps for a limited time. 
  2. Getting return on the technology investment. Customers want to know that the investment in a product or service will continue to pay off, long after the project is officially completed. Partners want to know that it was worth their while to add your products or services to their portfolios. 

To address both priorities, you don't need to promise too many specifics. You need the aspirational roadmap that describes where, over the course of the next couple of years, the company is headed, and how its product and service portfolio fits into that vision. You also need a somewhat more specific roadmap that gives a greater level of detail about releases, but not too much detail. The goal of the release is the crucial element, since it makes sense of the projects that are included, as well as the ones that are excluded (or may be cut). And, of course, there's the very short-term roadmap, describing what you're working on now, and how you're implementing these projects.

Imagine that your company is part of your circle of friends. Pick one of those individuals, and you know what type of friend someone is, from close confidante to passing acquaintance. You also know generally what you can count on them to do, such as the friend who's always a good person to include in weekend plans. Finally, there are the specific events scheduled for the near future, such as the skiing trip next weekend. Obviously, whenever you make plans like these, you're going to invite the stalwart friend who only cancels at the last minute when there's a damn good reason, over the flaky friend who always says yes, but shows up only half the time.

Now, imagine what customers want from you, when the stakes are a lot higher than canceling one of the room reservations at a ski lodge.  Keep that image in mind for the next time you revisit the roadmap. Segment it into the different levels of specificity, and be honest about what you don't know, or don't plan on doing. 

[Ultimately, we're talking about the roadmap as an offshoot of the company's portfolio: What business are we in? How will we deliver value in that market, now and in the future? But that's a big, big topic for a later post.]