I was recently invited to the community (thanks!) and, having been closely involved with public roadmap development for G Suite, will humbly offer my $0.02.
To begin, I’d like to share one of my favorite memes with the Coda team: “You can’t please everyone. You’re not a Nutella jar.” This certainly resonated with me over the course of many roadmap iterations to meet the needs of our customer base. What follows is more my POV than where we were with the roadmap when I left Google.
A couple of dimensions already mentioned on this thread are timing and level of detail, and I believe they’re interrelated. That is to say, the closer a feature set moves toward release, the less likelihood of significant change by the engineering team, and hence more detail can be shared with customers. Let’s see what this might look like in practice (i.e. using a dated, already public Google example).
Assume three levels of scheduling for features: short-term (current quarter or next), long-term (2-3 quarters away), and directional (no timing). As customers need to understand where you’re planning to invest, posit a list of themes - or better yet, use cases - in the directional bucket (e.g. eDiscovery support will be added for Google Drive).
As scoping for a particular use case proceeds and it moves from directional to long-term, your quarterly roadmap update will expand to include the components of eDiscovery to be supported (e.g. retention, legal hold, export). As development continues and you gain feedback from trusted testers, the feature set moves from long-term to short-term and the next roadmap update includes screenshots showing UI/UX attributes. Considering the competition, the nitty gritty details only come post-release in Help Center articles.
While Coda enjoys the luxury of beta status today, eventually it will launch. From that point forward, your product roadmap (for all intents and purposes) IS your product. And I can’t wait to see where you take it. Keep up the great work!