Daniel Smith

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.

Checked our automated signup emails today and realized half of them were talking about old features we removed months ago.

New users get these right away, so sending outdated instructions creates a terrible first impression.

It was a quick fix, but made me realize how fast lifecycle messages get stale.

It s so easy to fall into the habit of constantly changing things on your site just because you looked at a competitor or got bored of your own UI.

I used to jump straight into the code every time a flow felt slightly imperfect to me.

I slowly realized I was wasting tons of hours solving non existent issues instead of focusing on actual user pain points.

What filter or rule helps you pause and decide if a problem actually impacts real users before you start changing it?