Customers and prospects frequently ask us about our roadmap. While it’s a good question, it’s tricky to answer….not because I feel we have a ‘roadmap problem’ at Graphical Networks, but because, if I have to explain our stance and the reasoning behind it, it would lend itself to a long philosophical debate on the nature of ‘what is a software company’ (and, perhaps, a disappointed customer).
We don’t really have a roadmap per-se. Well, at least not in the grand ‘wave-your-hands-in-the-air-big-power-point-24-month-grand-plan’ type of way (…if you know what I mean).
In general, sales people love roadmaps, and love to throw everything at them plus the kitchen sink. Then want to tell prospects what they want to hear. After the prospect buys the tool, however, who cares if it’s actually delivered, right? Perhaps I am being a bit sarcastic here, but I have seen this exact scenario play out at other companies in the past.
A careless sales person would say yes to any request coming from a prospect: a recipe for disaster for so many reasons that I hope I don’t need to explain. The truth is that even if we wanted to say yes to everything, the reality of finite resources would prevent us from delivering most requests…creating false expectations and, ultimately, disappointing the customer or prospect and setting a bad precedent.
Why are so many roadmaps problematic?
Roadmaps tend to be these long-term, vague, and barely-tested laundry lists of cool-to-have ideas. 20 years of software product management have mostly persuaded me that those types of fantastical roadmaps are little more than wishful thinking. I’ve seen it in action: when you have to present them at monthly meetings, they keep changing like a chameleon.
In a previous blog about feature requests and netTerrain, I discussed the process for collecting feature requests — our roadmap is not a compilation of those feature requests either. If it were, we’d end up with a random laundry list of disjointed pet features from everybody — implementing all of these features would ruin the software for 90% of the citizenship. When everything is important, nothing is: as it is impossible to add every feature, you’re forced to prioritize and then certain people feel dissed while you miss deadlines and it’s all one giant mess. We are not aware of any successful software company that does this.
With all that said, do we here at Graphical Networks have a roadmap?
Yes, one that is far more realistic and achievable: it includes the list of improvements for the next release and an overall direction in which we want to go as a software company.
Here’s an example: our current roadmap is release 8.6 which includes many features for network mapping, DCIM and fiber plant documentation, such as: port-to-port network topology mapping, improved outside plant performance, simplified device catalog management and so on.
After that, we have a list of candidate features for the next release (version 9.0).
And that’s about it. And we like it this way. Anything beyond that, I believe, would be akin to wishful thinking. You simply cannot go much further than a few months.
Beyond that, there are simply too many variables in the IT visualization market and demands from existing and future customers to keep that long-term roadmap anywhere near predictable.
Want to request the roadmap?
We are always happy to share what’s in store — so much so that we constantly discuss it in our blogs. However, if you request some fancy-schmancy PowerPoint you won’t get it. Our roadmap can be explained in three simple slides: upcoming release, candidate features for next release, long-term vision. This is the same roadmap we share with our customer advisory board as well as with our partners around the world.
Happy documenting!