Build in Public
How to Build a Public SaaS Roadmap Without Overpromising
Build a public SaaS roadmap that collects useful customer feedback without turning votes, dates, or planned features into accidental promises.
By Uriel Bitton · 4 min read
The short answer
A public SaaS roadmap works best as a communication layer, not a contract or voting machine. Publish selected problems, themes, and stages such as Now, Next, and Later; keep dates tentative; explain what each status means; and collect context behind requests instead of ranking by votes alone. Keep sensitive backlog items private, close the loop when priorities change, and measure whether the roadmap improves feedback and customer understanding.
A public SaaS roadmap can strengthen building in public when it shows direction without pretending the future is fixed. Publish selected customer problems and broad stages, explain what each stage means, invite contextual feedback, and keep prioritization under founder control. Treat the roadmap as a communication layer, not a contract or popularity contest.
Make the public roadmap a filtered view, not your backlog
Your internal backlog contains half-formed ideas, bugs, security work, technical debt, and requests that may never ship. Publishing all of it creates noise and accidental expectations. The public roadmap should contain only work that helps customers understand direction or give useful feedback.
Atlassian’s product roadmap template recommends organizing ideas with horizons such as Now, Next, and Later and creating tailored views for different stakeholders. That is a useful model for founders: the public roadmap can be a filtered view of the plan rather than a mirror of the internal queue.
Use the Direction–Context–Commitment loop
1. Publish the direction before the feature list
Start each roadmap item with the customer problem or product outcome. “Improve team approvals” gives people more useful context than “add bulk approve button.” It leaves room to change the implementation while keeping the direction understandable.
Buildside’s practical guide to building in public recommends sharing decisions, evidence, lessons, and next steps instead of broadcasting activity. A roadmap should follow the same rule: make the reasoning visible enough to be useful.
2. Define what every status actually means
A label such as “Planned” sounds like a promise unless you define it. Use a small number of stages and explain them. For example: Exploring means you are validating the problem; Next means you intend to work on it after current priorities; In progress means implementation has started; Shipped means customers can use it.
GitHub’s public roadmap distinguishes exploratory work from features already moving toward release and explicitly states that the roadmap does not guarantee delivery. That separation is valuable for smaller SaaS teams too because it lets you share direction without pretending every idea is committed.
3. Collect context behind votes
Feature votes can show that a topic deserves attention. They cannot tell you why it matters, which workflow is blocked, or whether the voter belongs to your target segment. When a request gets traction, ask what the user is trying to accomplish, what they do today, and what happens if the problem stays unsolved.
Buildside’s guide to reaching B2B buyers while building in public makes the audience-quality distinction explicit: feedback from the target buyer should not be weighted the same as broad founder engagement. Apply that filter to roadmap votes.
4. Treat dates as commitments only when you mean them
Early-stage priorities move because customer evidence changes, technical work expands, incidents happen, and opportunities appear. If an exact release date is not operationally necessary, use a horizon or status instead. Docker’s public roadmap explains that it avoids dates because priorities can change and also keeps some work off the roadmap. That is a useful precedent for selective transparency.
Keep customer-specific evidence private
A roadmap item can be public while the evidence behind it stays private. Do not paste customer names, support transcripts, contract details, security information, or identifiable usage into a public card. Summarize the pattern instead.
GitLab’s guidance on incorporating private customer needs into a public roadmap describes using generic customer details in public feature requests rather than exposing the private customer conversation. For a small SaaS, the simplest version is usually enough: publish the problem pattern, keep the account-specific evidence in your CRM, notes, or support system.
Close the loop when the roadmap changes
A public roadmap becomes untrustworthy when items quietly disappear or stale dates remain visible. If direction changes, update the status and give the customer-facing reason: stronger evidence changed the priority, a dependency expanded the scope, or the problem is being solved another way.
Measure whether the roadmap creates better feedback, fewer repeated questions, clearer customer conversations, or decisions changed by useful evidence. Buildside’s guide to measuring build-in-public impact recommends tracking useful conversations and informed decisions rather than judging public work by impressions alone.
Use a five-card roadmap to start
If your SaaS does not have a public roadmap today, do not publish fifty backlog items. Start with five: one or two in progress, one or two likely next priorities, and one problem you are openly exploring. Give each card a customer-facing problem, a stage, and one question you want feedback on.
That is enough to make product direction part of your build-in-public story without surrendering the ability to change your mind. The roadmap should make the company easier to understand while leaving room to learn.
Sources
Frequently asked questions
Should an early-stage SaaS have a public roadmap?
It can be useful when customers repeatedly ask what is coming, when you want structured feedback, or when public product decisions are already part of how you build. Keep it small enough to maintain. If priorities change weekly and you cannot keep the roadmap current, a lighter public changelog or occasional direction update may be better.
Should customers vote on a public SaaS roadmap?
Voting can show interest, but it should not decide priority by itself. A request from ten casual users may matter less than one request tied to a core workflow, retention risk, revenue, or strategic customer segment. Use votes to find questions worth investigating, then add customer context before making the product decision.
Should I put release dates on a public roadmap?
Use exact dates only when you have enough delivery confidence and the date matters to customers. Early-stage teams often benefit from broader stages such as Now, Next, and Later because priorities and technical estimates can change. Explain that the roadmap communicates current direction rather than a guaranteed delivery commitment.
What should stay off a public product roadmap?
Keep private anything that would expose customer identities, confidential requests, security work, commercially sensitive negotiations, internal incidents, speculative ideas that would create false expectations, or implementation details that do not help customers understand product direction.
A note from Uriel Bitton
A public roadmap is useful when it makes product direction easier to understand without turning every suggestion into a promise. I would publish the customer-facing problem, current stage, and why it matters, while keeping the internal backlog, sensitive requests, and exact prioritization logic private. The roadmap should improve the feedback loop, not hand the product strategy to a vote counter.
Keep building with us
Get practical founder lessons and product updates in your inbox.