A Public Roadmap

Hey there @evan and everyone.

As a first suggestion, I would really love a public Roadmap and a more complete changelog on a distinct page.
This would allow me to work on my documents with a perspective of changes if needed.
Actually I sometimes walk a bit in the dark, even if Coda already have everything I need, and thanks to the awesome Coda team, they always give me answers.
A Roadmap would be great :slight_smile:


Second this!

Although the mystery of the “New Features” reload toolbar is always fun—a quick hide and seek, almost!

I love that Chris!

I’d love to know from you both what your ideal roadmap would look like. Do you want the nitty gritty details, or just bigger thoughts around features? Share your wishlist!

1 Like

I’m a big fan of the technical details, because it helps me think about what’s possible and what’s difficult. It also helps me improve the performance of my own documents. I’m often working with large tables, so knowing what similar functions perform better does make a difference (similar to the VLookup/Index-Match debate!).

But even knowing what’s on the horizon for next week vs. next month helps me plan out what documents I want to build in Coda next. We’ve a number of Google Sheets at the breaking point that I would love to bring into Coda, save for auto-import/export or cross-doc features, and knowing what could come next helps me plan a little more.

@tomavatars, is that how you’re thinking too?


Yes, I also think like that. I like details in a changelog because there are always many little improvements and bug fixes that would help me a lot.
And on a Roadmap I both need big plans, to have a kind of motivation along the use of a product and also to plan changes, and short planned improvements that I know would save me some time and problems.
Here is an example which I find absolutely gorgeous : https://community.amazingmarvin.com/roadmap
Their changelog is always filled with new updates and they have 3 levels of roadmap scheduling. By the way, I recommend the use of this website for personal task managing and procrastination beating ^^


Great feedback @tomavatars @chris_homburger - really appreciate it! Will chat with our product team about the best way to implement a version of what you’re describing. We’ve been moving to a more regular cadence of “Release Notes” which will highlight big features updates and smaller refinements (how have those worked for you?), but definitely want to create a more forward-looking view for our customers.

Note we’ve also been storing some of these updates in our Gallery, but to your point they are historical releases vs. future work: https://coda.io/gallery/VvT36aABX_/Coda%20Product%20Updates

1 Like

@evan Those are good, but as said above, add more info! I’ve been checking in quite often but seldom see changes.

Why not use the power of Coda to meet everyone’s wishes?

  • You could have a checkbox to only show “Major Feature Releases”. When checked, this would display about what you have displayed in that doc right now. When unchecked, it could also display each change, sort of like a changelog.
  • Add in future changes into the same table, and make them distinct. Mabe group by approximate release on the left? You could use this to encourage community participation in the features that you are unsure of how to solve, maybe by linking to a thread on that feature here.

I’m a fan of themes versus specifics. It will be helpful to know the product direction and the types of problems you are currently working on versus a monolithic backlog.


Hey there!
Not much news from the Coda team here!

I’m a bit lost because I love Coda, but your concurrency are very quick to add awesome features to their products : see Notion and their big 2.0 version which is definitely your main opponent and as I already told here, Airtable.
I don’t really have an idea of where you are leading with Coda. There are many fields that needs improvements (both UI and UX) and as beta testers and in my case, everyday user, I would really love to know why I should keep using Coda instead of migrating to other products.
Again, I’m very sorry for this :japanese_ogre: :imp: :no_good_man: :skull: :confused: commentary, but I feel that I’m slowly loosing my hype with Coda :sob:


Hey everyone!

Nothing makes me happier than talking roadmap with our enthusiastic users :smiley:. Just did a fun meetup in NY with a few of you and got great reactions and feedback to some of our upcoming demos.

We’ve heard your feedback on a more public roadmap and are discussing a few patterns for how and when to do it. Stay tuned. In the meantime, I thought I could share a few thoughts here.

As you know, we have a lofty vision that people can build docs as powerful as apps. As we’re in our Beta stage, we’re very interested in listening and hearing what you think is most important - we watch this forum in particular quite carefully.

To answer your question, we are currently working on a mix of large shape-shifting features as well as a long list of the fixes and refinements that seem small individually but large in aggregate. On the larger side, we’re actively working on two primary features. You may have heard about a concept we call cross-doc, where docs can connect to other docs. We’ve also heard a ton of feedback about getting data in and out of Coda so we’re working on an API to get data in and out of Coda (some of you are probably beta-testing it right now). These are large initiatives, and we’re taking the time to get them right.

We’re also knocking out some of the smaller but impactful user-requested features. Last month we focused on launching the new gallery and rounding out tables with “minimalist” controls, wrapping text in column headers, selective sharing, and a bunch of international fixes. For this month: we heard you wanted a better writing experience so you’ll notice a new H3 format in the toolbar with indent, spellcheck, and markdown following close behind. All the while, we’re continually sanding down cornersーpolishing our interfaces and squashing bugs.

In terms of the next-up ideas, we’ve built out some (pretty awesome) designs for our upcoming mobile work, thinking about forms and buttons, and also where to take API and cross-doc next. We’d love to hear your ideas on other ways to make docs as powerful as apps.



Thank you very much @shishir for those awesome projections!

Cross doc and api will be fantastic!

My personal feeling is that there should be a way to make views more customisable. I’m especially thinking of card views as I already told in another thread. So overall polishing, polishing of views and customisation is for me the high priority.

But all the smaller additions you told us are great! Markdown ? Yay !
And mobile app is also very very exciting.

Actually, mobile app is very much needed :slight_smile:
I don’t want to write ideas in evernote anymore.
It doesn’t make sense as all my protects are in Coda.
So I’m really looking forward a mobile app! And very curious of what you already designed!!!


One last thing, I’m projecting on using Coda as a public workspace, to let people view the process and advancement of a video game production.

I’m thinking of using Coda rather artistically, as an artist would use a sketchbook to prepare paintings. For a video game process, it would be a mix of researches and brainstorm canvas (need free layout to make things fun!), design documents and backlog/sprints.

I believe Coda has a real power for fancy public workspace and I can’t wait to be able to do this!!


@tomavatars I love this idea of a public workspace. Since Kevin Rose shared his development process of his Oak App in a facebook group with everyone who was interested, I’m obsessed with the idea of giving real and lifeinsights of a production/development/design process. But instead of “posting updates” you could just let people visit your planning & controlling tool.


This is what I want to do, let people visit the whole Coda space, from a link in the Steam page.
The design sections would be shared as well.
Updates would be referenced in the Steam page by the game updates itself. And a section in coda would be filled with different views corresponding to updates. This is also why I need bookmarks.

@tomavatars Awesome idea. I see what you described happening a lot with blockchain/cryptocurrency projects where the developers will open up their internal Slack channels to the public. This way you can see all the issues, bugs, and features being worked on by the core team. Additionally, you can follow commits and pull requests on GitHub, but this is not as freeform as a document surface.

More importantly, getting creators to share their projects has multiple benefits:

  1. Public Knowledge - Your video game project would be like contributing to Wikipedia, and since it’s public, anyone would be able to @reference that project to use in their doc. Let’s say the name of your game is “Tom’s Adventures.” One could then write something like @Tom's Adventures to get the full record of your game or =[Tom's Adventures].[Release Date] to get a specific field about your game. (Excel is rolling out new data types this year which is similar to this concept).

  2. Open Source - More innovation comes from projects that are shared to the public with multiple contributors.

  3. API - Building off of public knowledge, creating an endpoint for your data makes it easier for others to incorporate your knowledge and resources into their own projects (hint hint: Zapier integration) :wink:.


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!


I think that this would be a great way to get community feedback on what you all are currently working on.


So is there still no public roadmap for Coda? Would be useful


@Al_Chen_Coda , @Angad, @Helena_Jaramillo Any update on this?