Build a public roadmap customers can trust

Choose the promise your roadmap makes

Decide whether the roadmap communicates broad direction, confirmed work, or release timing. Most early products should communicate direction with broad horizons rather than calendar dates. Customers need to understand what is being considered and what is actively underway—not a promise you cannot keep.

• Now: active, committed work.
• Next: validated work that may change order.
• Later: promising problems that need more evidence.

Keep internal tasks separate

Do not publish every engineering task, security fix, dependency upgrade, or half-formed idea. Create internal tasks for implementation work and publish only customer-meaningful outcomes. Upstep internal items stay on the team board and out of the public feedback experience.

Define statuses customers understand

Use short, plain-language status names. Your public status should answer a customer’s question: is this idea being considered, actively built, or complete? Avoid internal acronyms and engineering-specific workflow names.

Suggested public statuses

Under consideration
Planned
In progress
Shipped

Collect votes as evidence, not a referendum

Votes reveal concentration of demand, but they do not replace product strategy. Combine vote count with customer segment, revenue impact, support frequency, effort, and confidence. The highest-voted request may not be the next thing to ship.

• Use votes to find duplicate demand.
• Ask follow-up questions before committing to broad requests.
• Score comparable initiatives with the free RICE calculator.

Explain movement on the roadmap

When an item changes status, add a concise team comment when useful. Customers tolerate a changed order much better when they can see the reasoning: a dependency, a stronger customer need, or newly discovered scope.

Example update

We moved this into Planned after hearing the same request from teams managing multiple workspaces. We are validating the first version now and will share timing once the scope is confirmed.

Share the right entry point

Link to the public roadmap from your Help, changelog, in-product feedback launcher, or customer email. Do not force customers to hunt for it. The same feedback flow should let them submit an idea, vote for an existing request, and follow progress.

Run a lightweight maintenance ritual

Review public items on a regular cadence. Archive stale requests, consolidate duplicates, promote validated work, and mark shipped outcomes promptly. A small honest roadmap maintained monthly is more credible than a detailed one that has not changed in a year.