When will this feature be available? Haven’t we all been in the situation, where you either asked or received such a question? Moreover, do you remember how easy it was to find trusted information to answer the question? Probably not that easy, which is one of the reasons why the internet is full of assumptions or even leaks about the next iPad, Tesla or even the mysterious Surface Phone.
Effective communication between product development and customers using the products is always challenging. However, is it the right way to keep everything a secret? Alternatively, could a roadmap even be made available to the public? Let’s investigate in this article the purpose of a roadmap and how to leverage it in the best way.
About the Roadmap
Let’s start with the basics – A roadmap is a strategic plan that defines a goal or desired outcome and includes the major steps, activities or milestones needed to get to this stage. A roadmap serves as a communication tool to inform stakeholders, external stakeholders (customers and investors), internal field personnel (sales, consulting, marketing, etc.) and Support Services about the short- and long-term strategy.
A roadmap is not limited to product development only; it can be used for various other scenarios. As a high-level document, the roadmap does not capture all of the plans in detail. This leads me to a necessary add-on, what a roadmap is not. As a strategic document, it does not replace a backlog or project plan and therefore should not be used as such. Neither should it be just a simple list of features, nor epics.
Why you should have a Public Roadmap
When I started at Microsoft back in 2009, roadmaps for products like Windows Server and System Center were kept a secret. Access was only granted to people with a non-disclosure-agreement (NDA) – only people who signed the special contract were part of the inner circle and trusted. Even then, the information gained couldn’t be used for anything, not internally and for sure not externally. Often the roadmap has been set and wasn’t changed for the average 18 months of product development.
Moving to the cloud, things are handled a bit different now. In the age of agile development, a roadmap has become much more of a living document, with far shorter timeframes (compared to 18 months or longer before). Priorities or adjustments can be made more frequent which allows a company also to better react to marked trends/opportunities.
Let’s have a look at the pros and cons of having a public roadmap, the pros:
- it’s known what is currently worked on;
- customers/stakeholders know what to expect, less sharing of “wish lists”;
- published features add pressure to deliver (it’s a pro and con);
- transparency on priority or timeline changes;
- company-wide alignment for different development teams;
- customers can express expectations while things are still in development.
- there can be communication about prioritization of multiple work items.
Now the cons of publishing the roadmap:
- loss of flexibility of changing the plan;
- competitors would have access as well;
- debates and questions on priority, missing items;
- Potential dissatisfaction of customers when a product slips.
From a solutions architect perspective, I believe that focusing on customers should be a higher priority than overthinking potential competitor’s actions. Knowing what’s ahead could help customers to plan their IT Strategy for the upcoming 12-24 months. However, I see a point in number three (debates and questions), where everyone has a different preference and opinion. This might be difficult to manage and requires a robust communication plan. To be fair, we need to be honest to ourselves how much we really need to know, and what we just want to know…
Florian, as a program manager in Microsoft Engineering, has an additional thought on this. What is the product group looking after? What kind of feedback is beneficial to improve a product or feature. Maybe a feature is targeted to a very special customer base.
What about Microsoft Azure?
As mentioned earlier in this article, Microsoft wasn’t eager to share details on Windows Server and System Center with the broad public. What about Azure – has the cloud changed this strategy? Indeed, as mentioned already in a previous article, there is a public roadmap available for Azure with integration into UserVoice. However, details on when a new service or feature will be available are still not published – to protect the development team and ensuring they can do their work. When a feature slips, surely that sucks, but usually, there are reasons for that.
The keys to achieving are not only about only to listen but also how a company responds. Public roadmaps were born for that, one of the most transparent ways to communicate and keep customers up to date on the new features or improvements of a product/feature. Microsoft uses UserVoice to collect feedback from their customers and manages the communication over this channel.
Some other good examples where companies have published their roadmap:
Is there Middle Ground?
Releasing a roadmap to the public is probably a big step or mind-shift for many companies, and still takes time. How can the pros and cons be balanced out, for the good of the company and the good of the users/company? Clearly, that’s hard. However, more and more companies are openly engaging with their customers and ask for feedback/suggestions. User Voice, as mentioned above, is broadly adopted. You might also want to think of a scenario where…
- … short term (3-6-12 months) release plan is shared and the general 12 months+ plan is kept within the company?
- … disclose features to trusted customers/partners a few months before anticipated release happens to get structured and valuable feedback.
- … introduce different rings for different types of audiences, based on the feedback and anticipated test/validation you seek.
The most complicated thing – and this touches on the point about “effective communication” – is the mutual benefit in publicly discussion the roadmap. This is a fine balance; from a vendor’s perspective, you want to communicate your plans and get customer’s feedback, priorities and insights into how a product or feature area will become more valuable and competitive on the market. On the other hand, you don’t want to over-communicate and have customers make plans for features that not yet exist.
There is also a point in selectively communicating the roadmap – and distribute the right insights to a few handpicked customers and partners you can expect valuable feedback from. Communicating and keeping a roadmap is usually not a one-way-street.
There’s just one more Thing…
Did you know, even a blogger can have a public roadmap? A former colleague of mine – Ray Maker – runs a top-rated sports blog, dcrainmaker.com where Ray also is publishing his roadmap/queue of articles. With this strategy, he keeps his readers informed about upcoming articles/tests and also the sponsors know what to expect in the upcoming months. Without adding strict timelines, it still allows him to react on trends.
To manage the queue for our blog cloudelicious.net, we started to use Trello as it’s light, free and supports what is needed to begin with a public or private roadmap:
- Visibility and transparency of the progress
- Easily update and keep track
- Allow authors to add new topics for articles or vote for their favorite ones
In case you plan to have your roadmap published – There are many ways how a roadmap can be published to the public. Tools like Roadmap, Trello, UserVoice or even just a simple (Excel) spreadsheet are an optimal starting point.
