Why you should have a public roadmap
Public roadmaps are used by organisations to show users and customers what they are working on now and in the future. They are a great way to show openness and transparency to build trust with an audience that is interested in their work, and to demonstrate commitment to listening to customers and improving products and services now and in the future.
If a product is a promise of value then a roadmap is a promise of a product increasing in value over time, but customers only gain that value if the roadmap is public.
Why have a public roadmap
A public roadmap is a sign of internet-era thinking and ways of working. Almost more important than what is on it, its existence is an indicator of a modern digital organisation. It shows customers, potential and actual, suppliers and others in the same industry or sector, or in fact anyone interested, that the traditional boundaries between a company and everything outside of it are becoming more porous and that it is a positive thing.
As yet, I haven’t found any example of an organisation making the actual roadmap that they use to prioritise and manage product work public. They all seem to have created separate versions of roadmaps in order to make those public whilst using other internal tools, but its still a step in the right direction.
Some product leaders caution against public roadmaps as revealing to competitors what the organisation is working on, or making commitments to customers that they might not be able to keep. These seem to suggest other issues that organisations need to resolve rather than reasons to not have a public roadmap, but it is important to understand the positives and negatives of a public roadmap before going ahead but then do it anyway.
Benefits of public roadmaps
Clarity
Encourages you to make your roadmap clear enough for a wider audience to understand. Anyone looking at your roadmap should be able to make assumptions about your organisational priorities by the work you have in progress and coming up. This forces you to establish those priorities clearly enough internally in order to express them clearly enough externally.
Commitment
Shows your audience and customers that you are committed to continuing to meet their needs over the long term. Customers wanting a long-term, ongoing relationship with your products can look at a public roadmap showing them how they can get increased value over time to help them decide whether to invest time and money in it.
Community
Builds a community around your products. Only those people who are really interested in the product and its development will be interested in its roadmap. These are your thousand true fans. Nurturing them, understanding what problems they have and how your product solves them better than anything else, will help to keep your product direction true.
Examples of public roadmaps
Github
Organised by what is expected to ship in each quarter, Github uses a Github Project Board (unsurprisingly) for their roadmap. The items are described in technical language but given that Github’s users are technically-minded they are likely to understand what ‘Audit log API on GHAE and GHES’ means, this seems appropriate. Each item on the board can be opened to see more details, including ‘Intended outcome’, which is a nice way of bridging between the timeline view of the board and the outcome-focused drivers of the work. Each item also has labels which are clickable to show all items tagged with, for example, ‘Security and compliance’. A user that has a particular interest in all the features that are related to security and compliance can get a view of all the work Github is doing about that.
Microsoft
Microsoft uses an in-house tool for their public roadmap. Not surprising given the complexity of a single roadmap for displaying information about more than forty products across ten platforms and twelve release phases. The roadmap tool allows users to filter the whole view to see items about specific products and what status that item has; ‘In development’, ‘Rolling out’, or ‘Launched’. The roadmap seems aimed at admin business users of Microsoft products who are responsible to understanding when a new feature is released so their organisation can adopt it, which makes the information in the roadmap more logistical than serving to express the vision and direction of the products.
Buffer
Buffer’s public roadmap uses Trello and includes four columns of ‘Exploring’, ‘In progress’, ‘Done’ and ‘Leaving it for now’. People are allowed to comment and vote on the feature, perhaps as a means of validating the need and prioritising the work. The labels suggest some strategic themes to link work together with users being able to use them to filter the board. Buffer’s use of Trello, a simple tool that most digital knowledge workers will be familiar with, shows that they want to be more transparent with their customers and inform them about the product development work.
RNID
RNID’s public roadmap is organised by quarters and with sections ‘We’re discovering’ and ‘We’re delivering’ in each quarter. The work described is phased as outcomes for people using their products and services, for example ‘People can check their hearing online and find next steps to get support.’ but doesn’t connect that work to strategy, most likely because that isn’t the purpose of the roadmap which seems to be more about showing progress.
GOV.UK
The UK Government’s public roadmap, underpinned by it’s tenth design principle, Make things open: it makes things better, shows work across six programmes and in three columns, ‘Recently shipped’, ‘Working on now’ and ‘Exploring’. The items on the roadmap describe work at a level that would be given to a cross-functional team that would be able to, ‘Design and test a new design for the GOV.UK homepage’, rather than breaking the work down functionally or describing a feature.
Roadmap
Roadmap builds roadmap software, which they also use for their public roadmap. The roadmap section is divided into ‘In progress’, ‘Soon’, and ‘Future’, but also has sections for Launched and Ideas. The tool has functionality to allow customers to vote on features but doesn’t seem to include any detailed information or connect to outcomes or strategy.
Trends in public roadmaps
There are two clear trends in the above examples; tools and text. Four of the examples use a tool for managing and displaying their roadmap which allows viewers some functionality such as filtering. All four of these examples are providing software products so perhaps their audience is more technical and more interested in which features are shipping when. The two text based roadmaps are arguably easier for viewers to read and understand, which fits with the expected (non-technical) audience for a charity or a government.
All of the roadmaps attempt to present a picture of the product work in a ‘past’, ‘present’, ‘future’ way, but don’t seem to tackle the problem of representing the current state of the product. Perhaps that’s just the nature of how we approach roadmaps or perhaps the expectation is that the live product does that itself.
Should you have an open roadmap?
For your organisation? For your projects? For yourself? Yes. Yes. Yes. Public roadmaps are a good thing. They make us consider what we put out into the world, and how others will understand it. They help us think big about what we want to achieve, and act specifically in order to achieve it. They clarify our thinking and show our commitment to making things better.