Two roadmaps, two jobs
A public roadmap is the customer-facing story: planned, in progress, and shipped work people can follow and often vote on. A private roadmap is the team’s operating board: spikes, debt, experiments, and sensitive bets that are not ready for a public commitment.
Confusing the two creates either oversharing or a fake public board that never matches delivery. Start from the commercial surface on public product roadmap.
Keep reading in this cluster: Public Product Roadmap Best Practices for…, Roadmap Software vs Product Planning Tool, How to Prioritize Feature Requests with C…, and Public product roadmap.
What to publish
Publish customer-valued features and fixes you are willing to discuss. Link items to feedback when possible. Prefer a short honest list over a long speculative one. If dates may move, say so in plain language.
What to keep private
Keep internal research, refactors, competitive bets, and unfinished experiments off the public board until they become a real customer commitment. Run that work on private Kanban or your planning tool so engineering still has a single queue.
Keep the public board truthful
When an item stalls, move it or explain it. Silent drift trains customers to ignore the roadmap. Pair status changes with changelog updates when work ships so voters see outcomes.
For column habits, see public product roadmap best practices. For how roadmap software differs from internal planning, read roadmap software vs product planning tool.