Roadmaps and promises

I’ve just replied to a thread in our General Discussion forum that I think is worthwhile bringing to a wider audience here. The backstory is that a customer is pointing out that a particular feature promised in the roadmap didn’t make it into DXperience v2011.1 and this omission has compromised his plans for the release of his software application in the summer. Whereas I am totally sympathetic to his predicament – “WTF am I going to do now?” is what I’d be saying for sure – there’s part of me that is less so. Let me repost my reply:

photo © 2008 Howie Le | more info (via: Wylio)Every time I write a roadmap, I insert language to say that although we hope to complete everything we describe in it, in reality some things won't get done, others will get done early or late, and yet others, previously undefined, will suddenly get done instead. Every time we publish a roadmap, someone gets upset that feature X (for some value of X) didn't make the mix during the year, and so every time I resolve that the next roadmap I write will contain stronger language pointing out the caveats. Here's the paragraph from the 2011 roadmap:

And what are those caveats? As is usual I have to sound my standard note of caution. These plans are our best estimate at this point in time for what we should be able to do in 2011, given our resources and our understanding of the technology landscape in which we operate. Any dates given are estimates. Any functionality we describe in this roadmap, especially the further out it is, may be postponed or cancelled altogether. We strongly advise our customers not to make firm plans based on what they see here: in an industry such as ours, things can change very quickly and we have to react just as rapidly to new opportunities that may present themselves.

Although I am sorry that the lack of X in our v2011.1 release has thrown off your plans, I honestly don't know how to make this language any clearer. The roadmap is a guide only. It's a way of communicating what we envision doing over a period of 12 months, not a set of features on engraved stone tablets from which we won't deviate.

I firmly believe that a roadmap -- despite these caveats -- is a worthwhile document to produce for our customers. It gives them a idea of what to expect and reassurance that, heck, DevExpress is planning and executing on some great new features. It's also beneficial for us: it lays down a development path for our programming teams (so they don't go off on wild "wouldn't it be cool" tangents), and it gives strong goals for our marketing teams (booking ad space in magazines requires 3 months or so, for example), and evangelists. The alternative -- no roadmap at all -- is unacceptable to me.

We’re all developers, right? We know that drawing up set-in-stone software development plans for a full twelvemonth is silly: there will always be events and circumstances beyond our control that will alter those “best laid plans”. However, having the guidance of those plans, although they should be treated as being more nebulous, is still valuable. I mean what I say: I believe spending the time discussing and writing a roadmap is more constructive for you, our customers, and for us than the alternative, staying quiet until we do the sneak peeks.

We just have to be careful in how we interpret a roadmap. It’s a guide, not a set of promises.

What do you think? Do you like the roadmap? More provocatively: Do you produce a yearly roadmap for your customers? Do you stick to it no matter what? Or are you more “event-driven”?

Free DevExpress Products - Get Your Copy Today