Roadmap for customers: what to show and what to hide

Start with the thing this page can’t fix. A customer-facing view isn’t your roadmap with columns turned off — the items themselves are written in the wrong language, and no amount of hiding changes that. The external roadmap isn’t the internal one with fields hidden is the fuller version of that argument. Rewrite first. Then the field list below is worth having. Once the items in the master file are named as problems, the customer view is a filter and a field list like any other view.

Three stages, and no fourth

Now, Next and Later is enough. It answers when without producing a date, and the three buckets carry a decay in confidence that customers already read correctly: they believe the first, discount the second, and treat the third as intent.

Add a fourth horizon and the far end stops meaning anything. What you have built then is a public backlog, and a public backlog invites requests to move items up it, which is a queue you now appear to be managing on somebody else’s behalf.

Dates are the field that generates work forever

No quarters. This is the one audience where even the coarsest date is worse than nothing, and the reason is upkeep, not secrecy.

A quarter on a public page is a claim with a deadline attached. When it slips, and one in four will, you’re choosing between changing it quietly, which somebody screenshots, and announcing the change, which is a correction email to people who never asked for the original. Neither is a good use of the trust you published it to build. A roadmap without dates still has to answer when, and that guide covers what to say when somebody asks, which they will.

Status goes for a related reason. In progress, published, is a support ticket asking when in progress ends. You have created a question with no satisfying answer and pointed customers straight at it.

What actually earns its place?

Area, so a customer can find the one line that’s about them. The rewritten name, so they can tell whether it’s about them at all. A link, but outward only — a changelog entry that closes the loop when something ships, never a ticket, which exposes an argument the team had and isn’t yours alone to publish.

Owner comes off without much debate. A named employee attached to a wanted feature gets found on every channel that exists, and the person who ends up handling that didn’t agree to it.

Publishing is a commitment to maintenance

The field list is the small half of this decision. Most teams shouldn’t publish one at all, and the argument is about upkeep more than openness: a page nobody updates is stronger evidence that you stopped shipping than no page at all.

Two habits make the difference. Remove things — a list that only grows tells a reader nothing ever lands, and the item you dropped quietly is the one that gets asked about. And attach the update to something that already happens. Staleness is a copies problem rather than a discipline problem , and the same fix applies here: one set of items, a saved view carrying the public field list, published from the same file the squad works in.

That way there’s no second document to remember. The public view is a filter and a field list over the roadmap you were maintaining anyway. Hiding a field is a property of that view, so the value stays in the file and every other view still reads it, which is why what you publish is a picture instead of the file itself.