Should You Publish Your Product Roadmap?

Should You Publish Your Product Roadmap?

Publish the direction, not the dates. A public roadmap that names themes and statuses builds trust and reduces support load. A public roadmap with quarters attached becomes a list of promises you will break, and your sales team will be the ones explaining why.

We build the websites and content systems B2B software companies run on, so we end up in this conversation whenever a company plans a changelog, a wishlist or a trust page. It is framed as a transparency question and it is really a commitment question.

Here is the case on both sides and where we would land.

What Is Actually Being Asked?

Three different things get called publishing a roadmap. Telling customers what you are working on now. Telling them what you plan next. And telling them when.

The first is nearly always worth doing. The second is usually worth doing with care. The third is where companies get into trouble, and it is the version most people mean when they say roadmap.

Separating the three makes the decision much easier, because the answer is different for each and you do not have to choose one policy for all of them.

What Does the Case For Look Like?

Four real benefits. Customers stop asking your support team whether a feature is coming. Prospects with a missing requirement can self-qualify instead of churning after a trial. Your champion has something to show their boss. And you get feedback before you build rather than after.

The self-qualification point is the strongest and the least discussed. A prospect who learns in week one that the integration they need is not planned is a prospect who did not waste your sales team's quarter.

There is also a competitive effect worth naming honestly. A visible roadmap makes it harder for a competitor to claim you will never build something, because the answer is public.

What Does the Case Against Look Like?

Three real costs. You tell competitors what you are doing. You create expectations you may not meet. And you constrain your own ability to change direction, because changing a published plan now requires an explanation.

The competitor concern is the one executives raise first and it is usually the weakest. Anything on a roadmap that a competitor could copy quickly is probably not a durable advantage, and by the time they have shipped it you have too.

The expectation cost is the real one. A customer who renewed partly because of a roadmap item and did not get it has a grievance that is entirely your doing.

How Do Companies That Do This Handle Dates?

By publishing status rather than schedule, mostly. The Microsoft 365 Roadmap uses three status categories: in development, meaning currently being tested, rolling out, meaning deployment has begun but is not universal, and launched, meaning fully released and generally available.

It also carries an explicit disclaimer. Microsoft states that all information is subject to change, and that as a feature becomes generally available, or is cancelled or postponed, information will be removed from the website.

That is the pattern worth copying. Status describes where something is, which is a fact. A date describes where something will be, which is a forecast, and forecasts about software are wrong in one direction almost always.

Is a Wishlist a Roadmap?

No, and the distinction is useful. A wishlist collects and prioritises requests. A roadmap states intent. Companies often ship the first and describe it as the second, and customers notice.

Webflow runs a public wishlist, and one of the most telling things on it is an idea asking Webflow to publish a roadmap. The request asks for at least a vague roadmap of upcoming features, described as a quarterly or yearly overview, to help users plan and manage client expectations. A commenter adds that knowing the likely outcome, such as whether an idea will be backlogged or rejected, would itself be valuable.

That second comment is the insight. What customers want most is not a date. It is a decision. Knowing something will not be built is more useful than a permanent maybe.

What Should the Statuses Be?

Four, in our view, and they should include a negative one. Shipped. Building now. Planned, meaning committed but not started. And not planned, meaning we have considered this and decided against it for now.

The fourth status is the hardest to publish and the most valuable. It is also the one that reduces support load the most, because it ends conversations rather than deferring them.

What does not belong is a generic considering bucket that everything falls into and nothing leaves. A bucket like that is a way of appearing responsive without being accountable, and customers work it out.

Are There Claims Risks?

There can be, and it is worth keeping in view even for a small company. The US Federal Trade Commission's guidance for businesses states that before running an ad you must have a reasonable basis for its claims, and distinguishes express claims, which are stated directly, from implied claims, which are suggested by inference, with both requiring substantiation.

A roadmap on your marketing site sits close to that line when it is used in a sales process. Saying a capability is coming in Q3, in a document a buyer relies on, is a different thing from describing your current direction.

The practical protection is the same as the good product practice. Publish status rather than dates, state clearly that plans can change, and never let a roadmap item become the reason a deal closes without it being written into the contract.

Where Should It Live?

On your own site, next to the changelog, not in a third-party voting tool bolted on at a subdomain. The roadmap and the changelog are the same story in two tenses, and putting them together makes both more credible.

The changelog does most of the trust-building work, because it is evidence rather than intent. A company with two years of shipped entries has earned the right to be believed about what is next. We went through the build in building a changelog page.

Make it a real page that can be indexed and linked. A roadmap behind a login is invisible to the prospects who would benefit from it most.

Who Should Decide What Goes On It?

Product, with a veto from sales on timing rather than on content. Sales knowing something is coming before customers do is reasonable. Sales deciding that an item should be hidden because it is inconvenient is how a roadmap stops being honest.

Set a review cadence and hold it. Monthly is enough. A roadmap that was last updated seven months ago does more damage than no roadmap, because it advertises that nobody is paying attention.

And plan for the removals. Microsoft's disclaimer includes removing information when something is cancelled or postponed, and having that rule in advance makes the awkward conversation routine.

What Would We Recommend?

Publish a page with four statuses, no dates, a plain sentence saying plans change, a monthly review, and a changelog sitting next to it. Say no out loud on the things you have decided against.

That version gets you most of the trust benefit and almost none of the commitment risk. If you later find you want to add dates, you can. Removing them once customers have planned around them is much harder.

If you are building a roadmap or changelog page and want help getting the structure and the wording right, we are happy to walk through it. Find us at phoenix.studio.