Do you actually publish a public roadmap, or just hope users don't hold you to timelines?
Been thinking about this a lot lately. Every time we plan the next quarter, there’s an internal debate: do we put our feature plans out in the open, or keep them internal until code actually hits production?
Do you think early-stage products need a public roadmap—even a simple Trello board? Or does that only backfire the moment priorities shift and a promised feature gets delayed?
Should it live on a public page like Canny or Notion? Be sent out in monthly newsletters? Or is sharing upcoming plans just setting yourself up for unnecessary pressure?
In our case, we’ve started realizing that being brutally honest about why something got delayed actually builds more trust than making shiny timeline promises.
There’s also a bigger question here. Some companies hire dedicated DevRel teams just to manage public expectations and feature requests. Feels like over-engineering on the surface, but maybe it’s necessary if users start feeling ignored the second a deadline slips.
So, curious how others handle this. Do you treat roadmaps as a real commitment, or more of an internal wishlist you keep to yourselves?
Replies
The trap is thinking a public roadmap is a project schedule not a vision board. drop quarters. use simple statuses like in Development or Explorinng. Be upfront when priorities change. but being honest about why there is a delay builds way more loyalty than hit or miss release dates
I see a roadmap more as a guide than a promise. If priorities change i'd rather explain it and move on
I wouldnt put every little feature on it . Some things change before you even get a chance to build them.
I'd share what were planning but leave out exact dates.
we keeps our pretty simple. people can see what's coming without seeing deadlines.
if i plans chnage i think being honest about it is enough.