Over the years, many of you have shared thoughtful ideas and feature requests across the community: in forum threads, comments, support conversations, Slack messages, and other places. That feedback genuinely helps shape how we think about the product, and we’re grateful for the time people take to share it.
One challenge, though, is that a lot of those ideas now live across older threads and scattered conversations. When feedback is spread out like that, great insights from the community can easily get buried instead of surfaced in a way that helps us advocate for them internally.
To help with that, we’ve created a single place to collect and track feature requests already raised in the community.
If you’ve asked for something before, feel free to add it here, even if it’s come up elsewhere in the forum. The goal isn’t to relitigate old discussions, but to bring those ideas together so we can better understand what’s resonating and make sure the right teams see them.
You’ll also be able to upvote requests that matter to you, whether or not you originally raised them. That helps us understand where interest is strongest across the community, not just who happened to ask first.
A couple of quick clarifications:
-
This isn’t a replacement for reporting bugs — those should still go through the usual channels.
-
This tracker is designed to consolidate existing community feature requests to make them easier to review and follow up on.
-
While we can’t promise every request will make it onto the roadmap, having them in one place helps ensure they’re visible and considered, and it allows us to give more realistic updates on where things stand.
Thanks as always for the thoughtful feedback you bring to this community. The ideas shared here genuinely influence where the product goes — this is one way we’re making sure they don’t get lost along the way.
Please bookmark this link and let me know if you have any questions.
4 Likes
Hi Ruggy, really appreciate you taking this on, having a central place for feature requests with better structure is a great idea.
My main concern is that we already have years of feature requests in the community with hundreds of votes on many of them. Asking people to re-enter them manually means starting from zero and losing all that existing signal. Realistically, only a fraction of what’s already been requested will make it into the new doc.
An alternative idea: use the Discourse API to pull in the existing feature requests automatically (titles, descriptions, vote counts, links back to the original threads) and keep them synced into the Coda doc. The doc could add real value on top: categorization, clustering related requests, letting people add use-case context, priority rankings, status updates from the Superhuman team (out of scope, exploring, planned, in progress, shipped, etc.) to name a few.
In this way the doc builds on the signal the community has already created rather than starting over. Users get richer ways to express what they care about and, also importantly, visibility into where each request actually stands.
Pablo
4 Likes
Hey @Pablo_DV — I appreciate you taking the time to lay this out so thoughtfully.
You’re absolutely right on the risk of losing the existing signal from some of these previous feature requests. There’s a ton of valuable context already living across the community, and the goal here is definitely not to reset that to zero.
Part of the challenge we’re working through is that there are ~17,000 posts across the forum, spanning multiple years, different teams, and significant change along the way (new org structure, acquisition, shifting ownership, etc.). So right now, this is less about creating a perfect system on day one and more about actively triaging and consolidating in a way that’s actually usable for the teams making decisions.
The doc is meant to be one pillar of that, not the source of truth on its own. We’ll also be surfacing insights through API-based approaches and other methods, as we’re very mindful not to ask the community to double up on work after already contributing so many great ideas over time.
The crowdsourcing ask is really about speeding up the aggregation process and pressure-testing what’s still relevant today, especially since some older requests may no longer apply or have evolved since they were originally posted.
Really appreciate the thoughtful comment here. It gives me a chance to better articulate our full approach to ensure these valuable insights don’t get lost.
2 Likes
I just checked and there are over 2,600 feature requests, a bit too much noise 
But I fetched the data from the API and there are only ~80 topics with more than 20 votes. I think that’s a manageable starting point, and if some of those have gone stale, that’s easy enough to flag once they’re in the doc. Happy to upload them if that’s useful.
6 Likes
For those curious, here are the top 20. Many of them have been already totally/partially implemented and for many others there are solid workarounds. Props to the coda team!
9 Likes
@Pablo_DV Yes, exactly. Appreciate you digging in at that level!
That signal vs. noise tension is something I’ve been working through too. There’s a lot in the system, and the goal is to surface what’s actually actionable and representative of what comes up most.
Your approach looks a lot like where my head’s been at, so good to see that alignment. Zeroing in on vote volume is a clean way to cut through the noise and get to something workable.
I’ve pulled together a consolidated view on my end that looks a lot like yours (~200 entries across sources over ~6 years on the forum).
One thing that’s become clear in the process: a lot of these have already been built, which is great! There’s real progress reflected in there. That said, there are still plenty of outstanding asks, and part of the goal is getting a clean, high-level view of what’s still most relevant.
I’ve been taking a triaged approach to gathering signal. Forum data (votes, replies, etc.) is a huge piece of the puzzle, but not the whole picture. Some of the biggest feedback over time has come through Slack threads, 1:1s with the product team, roundtables, and even the occasional text message or DM. Part of this effort is making sure that feedback doesn’t get lost just because it’s harder to track those. Which is why the crowdsourcing piece matters: less about starting from scratch, more about turning over as many rocks as possible, using both quantitative and qualitative approaches, to make sure we’ve got everything we need for this to be useful and accurate.
If you’re comfortable sharing what you surfaced, I’d love to compare notes and make sure I’m not missing anything obvious.
4 Likes
Hey Ruggy,
Here’s my experiment: Feature requests. I tried to make feedback both useful and painless to give (max 3 clicks per user). It also aggregates the feedback per feature to give a quick overview.
If you find the approach useful, I could help you set up something similar in your doc.
Cheers!
Pablo
4 Likes
