A Methodology for Roadmapping Public Blockchain Networks
Roadmap format included
The blockchain industry is still in its discovery phase, progress and innovation often come in bursts. As with all research driven fields, the environment is often highly entropic and incongruent to expectations of steady progression.
The truth: it’s a paradox for us to message the entropy of the environment, then present a concrete and opaque timeline that gives the impression of concrete, steady progression. This practice, followed by many in the industry promote unrealistic expectations about how a research and discovery-oriented industry works and signals more to ambitions than realism.
So, how can we promote the truth, keep the community (you) informed, and keep our mindsets clear for the next year?
Some context before an answer
We’ve taken inspiration from mainstream and mature open source projects. They’ve got it figured out as their developer teams demand and rely on this being true.
Time spent in this field acclimates you to the rate at which technologies that blockchains are dependant on oscillate in progression. To observe this effect we first need to split the scope of projects within the blockchain space between:
- Tinkerers: Those that innovate use-cases on top of a blockchain platform, using existing tools that are available.
- Tool Builders: Those that seek to expand the toolbox.
For Tinkerers, timelines are often dictated by the time it takes the iron out the use-case, assemble the required components (Smart Contracts, off-chain storage & computation source, user frontend) in various configurations to match the user requirements. In projects like these timelines are often feature based, predictable and based on the scope and feature set of the use case. This is in contrast to timelines of tool builders, which seeks to expand the toolbox, to enable use-cases that would not exist without the expanded toolbox.
We believe this is the true nature of progression in the blockchain industry; discoveries that suddenly and fundamentally change the ideas and assumptions of what is possible. A good example of this is the tried and true use-case that Ethereum enables, leading to wide adoption of blockchains for a variety of use-cases. Another upcoming example is that of Algorand, with the introduction of VRFs that is quickly being adopted into other projects and impacts the way on-chain randomization is viewed.
In fact, a lot of the most important discoveries are being made by various teams around the world within the last year. The right people, right place, right time make the biggest changes to the industry.
If you believe this, then the idea of roadmaps as a list of bullet point and timestamps is jarring and incongruent. In truth, diving into a research field and signalling as such while also providing a concrete roadmap is paradoxical but common within the industry. Too often, the hardest parts of a project get hidden under a relatively mundane grouping. The consequence: the reader is often misled about the complexity of a project and then confused when items don’t come to fruition.
The best roadmaps are ones from projects that have a statistically viable sample to draw requirements from, ones that must be diligent and organized about roadmaps for their impact to downstream dependencies. We found similarities within roadmaps for these projects that convinced us of their effectiveness:
Roadmaps should convey clearly an overall theme that guides the overall motivation behind each item within the roadmap. It should be very clear to the reader how each item feeds into this overall theme. This conveys a sense of priority for the audience and encourages a healthy convergence of expectations throughout the year.
A Logical Breakdown
Following on from the theme is a logical breakdown of items within the roadmap as they concern different elements of the system and different parties. This grouping naturally creates a more detailed context about the tasks themselves, who would be performing them and how their scope (from our perspective) relative to the global.
Clarity of content
It should never be difficult for a reader to understand what is being worked on. While predicting the future can often be an impossibility, what is being worked on now and our predictions for future targets should always be conveyed in an easily digestible manner. In fact, the system that worked best for our teams internally is one that conveyed a good sense of progression through the breakdown of items into logical tasks and checkpoints and assigning them priority and perceived difficulty/risk of these items.
Secondly, descriptions should account for an increasing level of emergence, depending on the depth the reader is willing to go. This amounts to providing simplified “here’s the gist” descriptions to all users, and providing more in-depth details, examples, and reference content to those interested. Where applicable, readers should be notified how this change impacts them. This is critical to downstream dependencies that may be dependant on changes to the network.
Beyond the principles mentioned above, here is a structural format we believe is a good representation of what should be included in a roadmap.
The Roadmap Format
In the coming weeks we will be releasing our roadmap to the public with this format as our guide. The roadmap takes into account work being undertaken across the Foundation from research, to production development, to ecosystem funding, documentation and more. From all the things we looked at, arguably the most important was “Recommendations”, a roadmap feature we only saw from the React project. This roadmap feature is philosophically in line with how we think about this document in that it is “real talk” aimed at letting you know what this milestone means for you, given you’re developing on the platform. Stay tuned for updates on this in the coming weeks!
A Methodology for Roadmapping Public Blockchain Networks was originally published in Aion on Medium, where people are continuing the conversation by highlighting and responding to this story.