Talking publicly about a product before it ships is normal and often useful — it lets early users follow along, builds an audience, and can surface interest before the product exists in finished form. It also creates an easy failure mode: describing planned work in language that makes it sound already available. This article covers how to keep public communication honest while a product is still in development.
The core distinction
There is a meaningful difference between "we are building X" and "X does Y." The first is a statement about intent and current status; the second is a claim about existing functionality. Public product pages, especially, tend to drift from the first into the second over time as marketing copy gets polished — a roadmap item quietly becomes a present-tense feature description without anyone deciding that on purpose.
Practical guardrails
- State status explicitly. A clear "in development" or "available" label next to a product name removes ambiguity that vague marketing language otherwise creates.
- Avoid describing unreleased UI or workflows. Screenshots, feature lists, and workflow descriptions for something not yet shipped are easy to get wrong (the product might genuinely ship differently) and easy to misread as a completed feature.
- Separate the roadmap from the product page. If a roadmap is published at all, it should be clearly labeled as forward-looking and kept apart from the page describing what a product currently does.
- Update claims when status changes. A page that says "in development" needs to be revisited and corrected the moment that's no longer true, in either direction.
Why this matters beyond honesty for its own sake
Overstating a product's current state has concrete downstream costs: it damages trust with early users who discover the gap firsthand, and it can create real compliance problems — advertising and publisher policies commonly restrict monetizing pages that misrepresent under-construction content as finished, and that risk is avoided by simply describing status accurately in the first place rather than trying to make an unfinished product look complete.
A minimal, defensible pattern
A short, clearly labeled status line ("In development" or "Available"), a link to the product's own site for anyone who wants to follow it directly, and no invented feature descriptions in between, is enough. It doesn't need to be elaborate to be responsible — it needs to be accurate and kept up to date.
Related reading: How we build and Products for how this is applied in practice on this site.