11 User-Friendly Public Roadmap Examples for SaaS Companies

With these public roadmap examples, you'll see just how easy it is to create a portal for users to submit feedback, see what features are coming up, and check what has already been launched.

I've worked with thousands of SaaS teams through Frill, and the pattern I see most often is this: teams that publish a public roadmap early (even an imperfect one) build more loyal users than teams that wait until everything is polished. The roadmap doesn't have to be comprehensive. It just has to show users that someone is listening. In this guide, we showcase several examples and how to build your own.

What is a public product roadmap?

A public product roadmap is an insightful document that lists newly released product features and upcoming features a company intends to build. Sharing updates about implemented or upcoming feature upgrades with a public roadmap helps to keep customers and other stakeholders informed about your product development plans.

If customers know you’re building their desired or requested features, they can stay excited about your product, leading to improved user engagement and retention. Most SaaS businesses display public product roadmaps on their websites, where anyone can view them to stay updated about new or planned feature releases.

Why do you need a public roadmap?

The SaaS industry continues to boom. The worldwide SaaS market industry is expected to grow from $145.5 billion USD in 2021 to $171.9 billion in 2022. 100 countries around the world host SaaS company headquarters, and there are 15,000 SaaS companies in the US alone. So, while there’s plenty of market share to capture, there’s also tons of competition.

A public product roadmap can provide the competitive advantage you need to snag more market share. How? A public roadmap engages customers, letting prospects, existing customers, and other stakeholders track your product development progress and anticipate upcoming features. This fosters transparency and builds customer trust. Trusting customers are more loyal and willing to increase spending.

Also, stakeholders who know your product development plans can align their expectations. Having realistic expectations for upcoming features reduces the likelihood of user dissatisfaction and churning. Lastly, a public roadmap facilitates building user-centric products by letting customers share feedback on proposed features. Insights from the feedback will reveal if customers like or dislike your proposed features. You can then leverage the user insights to build truly customer-centric features.

Benefits of public product roadmaps

Here are the most valuable benefits your company can experience with public product roadmaps.

1. Effective marketing

Generate buzz and excite prospective and existing customers about your product with public product roadmaps. How? With public roadmaps, you can reveal that your customers’ most requested or desired features are coming soon. Publishing such updates will help you retain customers waiting for features listed in your roadmap. It can also help you capture new customers looking for certain features your competitors lack.

2. Foster transparency and trust

Publicly sharing your product roadmap demonstrates your transparency and eagerness to carry users along with your product development process. Your openness will inspire trust in customers, investors, and other stakeholders. Having the trust of your users is crucial because it fuels loyalty, minimizing the risk of churn.

The trust of potential investors is also crucial. A public roadmap facilitates getting investor buy-in by showing investors the high-value features you plan to build. For example, investors will be less hesitant about financing your product once they see your plan to build features that drive sales.

3. Connect product teams and users

With the help of a public roadmap, your product development team can collect feedback directly from real users. The feedback provides valuable insights your team can leverage to build a product that attracts and satisfies your target users.

For example, customers responding negatively to a proposed feature indicates that your users don’t want it. On the other hand, overwhelmingly positive feedback indicates that you should prioritize building a feature.

4. Customer engagement and appreciation

Engaged customers generate 51% more revenue and spend 23% more over their lifetime. Public roadmaps invite customers to engage more actively with your brand by getting them to submit feedback, feature requests, and product suggestions. Customers who engage in this manner feel like they are part of your company and building your product with you. Such customers are usually more loyal and satisfied and less likely to churn.

A public roadmap also fosters customer engagement by showing users you are acting on their feedback. For example, implementing a feature request or fixing reported product issues. Acting on your customers’ recommendations makes them feel appreciated and valued, contributing to increased engagement and loyalty. It also drives users to willingly keep giving valuable feedback that you can leverage to continue improving your product.

5. Expectation management and alignment

Public roadmaps are highly effective for visually communicating product development plans and progress to all stakeholders. The roadmap's clear information ensures all stakeholders, including customers and product teams, are on the same page. This prevents misunderstandings and wrong expectations regarding upcoming features, timelines, and deliverables.

As you can see from the Reddit screenshot below, power users get frustrated when they can’t easily find your public roadmap online.

Not publishing your roadmap is a major missed opportunity.When you don’t have one, you show your users that you don’t care if they know what you’re working on, and they can only see what’s coming after it has launched.

Public product roadmaps VS. private-public roadmaps

Public product roadmaps and private-public product roadmaps outline a company’s released and upcoming features. However, there's a significant difference in who can view a public roadmap compared to a private-public roadmap.

Public roadmaps are open to anyone interested in viewing them, including customers, stakeholders, and the broader public. On the other hand, only stakeholders with proper authorization can view a private-public roadmap. These stakeholders may include key partners, investors, product team members, and active customers.

Differences between public and private-public roadmaps

• Access: Public product roadmaps may not require login credentials to be accessed. Businesses restrict access to private-public roadmaps by giving login credentials to only authorized stakeholders.

• Feedback collection: Public roadmaps are ideal for keeping a pulse on how the public feels about your product plans. This is because the general public can view your roadmap and provide feedback. On the other hand, private-public roadmaps limit who provides feedback because only authorized people can access them. However, this can be good because only people who've experienced your product can provide feedback.

When to use a public product roadmap or private-public roadmap

Companies should have public roadmaps anyone can access if their strategic goal includes fostering transparency and customer engagement. On the other hand, private-public roadmaps that limit access to only select individuals are better for companies that require privacy.

For example, if publicly sharing planned product features will give competitors an edge and disadvantage your business, you shouldn’t use public roadmaps. This may occur in highly competitive industries where competitors may copy your planned feature and release it first to gain an edge.

Lastly, use public product roadmaps when you want feedback from everyone, including people unfamiliar with your product. A private-public roadmap, on the other hand, is better for collecting feedback from only stakeholders who understand your product.

11 public roadmap examples

Let’s take a look at some examples built with a variety of roadmap tools.Pay attention to the statuses that each company uses to help inspire your own roadmap. If you have a technical audience, you can use technical terms like “in development” and “shipped.” But if your audience isn’t technical, your roadmap would be better off with terms like “in progress” and “done.”

1. Frill

We use our own product to manage our public roadmap tool, Frill, which means we're accountable to the same experience we ask our customers to create for their users. Our three statuses (Under Consideration, In Development, and Shipped), keep things simple and scannable. Every idea is tagged by category (Improvement, New Feature, Widget, Integrations) so our product team can filter and prioritize without wading through an unstructured backlog. Users can see exactly where their idea sits and what's actively being worked on.

Takeaway: Tags are one of the most underused features on a feedback board. Without them, your roadmap becomes a list. With them, it becomes a system your product team can actually use to prioritize. Start with three to five tags that reflect how your team thinks about the product—feature type, product area, or audience—and keep that taxonomy consistent.

2. Acadle

Acadle is a white-labelled LMS for employee onboarding and training. Their four-status roadmap—Under Consideration, Planned, In Progress, and Live—shows a product in active development, with substantial activity across every column. High-vote items like "Disable Next Lesson Button until a previous Quiz is Passed" (49 votes) and "Question/Options Randomizer" (37 votes) sit in Under Consideration, signalling that the team is responsive to user demand when prioritizing what moves to Planned.

Takeaway: Four statuses is a natural sweet spot for most SaaS products. It gives users enough visibility into the pipeline without creating ambiguity about where something stands. Under Consideration, Planned, In Progress, and Live maps cleanly to how users think about product development, and it's easy to maintain.

3. Channex

Channex is an API that connects property management systems with booking platforms like Booking.com and Airbnb. Their roadmap uses plain, descriptive statuses (Under Consideration, Planned, Working on it, Already Shipped), and keeps the scope tightly focused on features that affect all users, rather than individual API connections being built for specific clients. This is a smart editorial decision: it keeps the public roadmap relevant to the broadest possible audience while preventing it from becoming a dump of one-off integration requests.

Takeaway: Think carefully about what belongs on your public roadmap versus what should stay internal. Not every piece of work needs to be public-facing. A focused roadmap that only shows universally relevant updates is more useful and more trustworthy than a comprehensive one that includes work only a handful of users care about.

4. Smartwriter

Smartwriter is a sales outreach tool that helps SDRs personalize emails at scale. Their Frill roadmap uses four statuses (Under Consideration, Planned, In Progress, Already Shipped) with consistent tagging across every item. What stands out is the discipline of the tagging system: nearly every card has both a type tag (Improvement or New Feature) and a product area tag, making the board immediately filterable for users looking for updates relevant to their workflow.

Takeaway: Consistent tagging only works if it's applied consistently. It's worth spending fifteen minutes at setup defining your tag taxonomy and making sure every team member adding items to the board follows the same rules. An inconsistently tagged roadmap is almost as hard to navigate as an untagged one.

5. Gorgias

Gorgias is a helpdesk platform for ecommerce brands. Their roadmap takes a visual approach that most tools don't: every item that reaches the Planned stage gets a custom image added to it. Under Consideration cards are plain text, but once something is committed to, it gets a proper visual treatment, like screenshots, mockups, or branded illustrations that make the feature tangible before it ships.

Takeaway: Adding images only at the Planned stage is a clever signal to users. It shows that a feature has moved from "we're thinking about it" to "we're actually building this." It also gives the product team a natural checkpoint to invest in proper communication before development begins, rather than scrambling to explain a feature after it ships.

6. Loom

This product roadmap example is built around three straightforward statuses (Coming Soon, Under Consideration, and Launched) and organizes ideas by product area within each column. The Under Consideration tab shows feature ideas with detailed descriptions already written out, like "Auto Touch up my voice" and "Time Based Self-Destructing Videos," giving users enough context to vote meaningfully rather than just reacting to a title.

Takeaway: Description quality matters more than most teams realize. A roadmap item with a one-line title asks users to vote blind. A card with two or three sentences explaining the feature and the problem it solves gets more thoughtful, useful signal. Take the extra two minutes to write a real description. It improves both the quality of votes and the trust users have in the process.

7. Dubsado

Dubsado is a client management platform built for freelancers and small businesses. Their "Discussing and Planning" tab, one of four statuses alongside In Progress, Up Next, and Released, shows something most roadmaps skip entirely: the messy middle stage where ideas are being evaluated before they're committed to.

What makes this roadmap particularly well-organized is how the team categorizes every item by product area (Mobile App, Clients and Projects, Multi-users, Scheduling, Forms, Other) before it goes public. Users aren't scrolling through an undifferentiated backlog. They're navigating a structured view of the entire platform, grouped by the part of their workflow it affects. For a product with as many moving parts as Dubsado, that organizational layer makes the difference between a roadmap users actually read and one they abandon after ten seconds.

Several items also include a direct prompt, like "Interested in this feature? Let us know below!" This turns the roadmap into an active conversation rather than a passive announcement.

Takeaway: Categorizing roadmap items by product area is one of the most underrated organizational decisions you can make. It costs nothing extra, but it immediately makes your roadmap scannable for users who only care about one part of your product. And including a visible "Discussing and Planning" stage signals honesty. Users see that their ideas are being genuinely considered, not just logged and forgotten.

8. DesignFiles

DesignFiles is a project management platform built for interior designers and design firms. Their public roadmap uses three clean statuses (Planned, In Progress, and Completed), and the Completed column alone has 186 items, which tells users something important before they even read a single card: this team ships constantly.

What stands out most is the vote counts. The most-requested features in progress have 141, 53, and 45 votes respectively, and the Completed column shows finished features with 80, 72, and 65 votes. Users can see at a glance that the things they cared about most actually got built. That's the feedback loop made visible.

The feature titles are also unusually specific, such as "Combine Quotes into a Final Invoice," "Client Signatures on Quotes," "Import Contracts from DOC/PDF Files." These aren't vague capability statements. They're the exact language a designer would use to describe their own workflow problem, which signals that the product team is listening closely.

Takeaway: Vote counts in your Completed column are underrated. Most teams hide or remove votes once something ships, but leaving them visible lets users see the direct connection between what they asked for and what got built. That transparency is what earns the next round of feedback.

9. GitHub

GitHub's public roadmap is one of the most comprehensive examples on this list, and one of the most complex. Built natively inside GitHub Projects, it's organized by quarter rather than by status, with columns running from Q1 through Q3 2026 and a dedicated "Recently Shipped" tab. Each item is tagged by product focus area, plan tier (Enterprise, Free, Team), and release stage (GA, Public Preview, Preview), giving developers an unusually granular view of exactly what's coming and who it applies to.

The left sidebar filters by strategic theme: Platform for collaboration at scale, Secure at every step, Accelerate with AI. This makes the roadmap useful at both the executive and developer level. You can scan for strategy at a high level or drill into specific items relevant to your tier and use case.

Takeaway: GitHub's roadmap works because it's built for a technical audience that expects precision. The quarterly columns, version tags, and release stage labels (GA vs Preview) reduce ambiguity for developers who need to plan around what ships and when. The lesson isn't to copy this level of complexity. Most SaaS products don't need it. It's to match your roadmap's detail level to what your users actually need to make decisions. For a developer tool, that means specificity. For a consumer app, simplicity wins every time.

10. Linkish

With Linkish, you get a bookmark manager for consumers, creatives, and businesses. Their Frill-built roadmap uses four clean statuses (Upvote to Consider, Considering, Planned, and Upcoming) which adds a useful stage before Considering that most roadmaps skip. "Upvote to Consider" effectively tells users: this idea exists, but it needs community validation before we'll commit resources to evaluating it. It's an honest way to manage a long backlog without making every item feel equally likely to get built.

Takeaway: Not every idea deserves equal weight on your roadmap. Creating a pre-consideration stage, whether you call it "Upvote to Consider," "Needs More Votes," or something else, gives you a filter layer that reduces the noise in your Considering column and sets honest expectations with users about what it takes to move an idea forward.

11. Juuno

Built with Frill, Juuno's public roadmap for their digital signage platform does something most product teams avoid: it shows users what isn't getting built, not just what is.

The four statuses (Planned, Building, Shipped, and Unlikely to Build) tell a complete story. The Shipped column has 63 items, which signals consistent delivery to anyone evaluating the product for the first time. But it's the "Unlikely to Build" column that earns the most trust. With 7 items listed, including an Apple TV app (27 votes), Restaurant menus (45 votes), and Music (45 votes), users can see which ideas were genuinely considered and why they didn't make the cut. That's a conversation most product teams simply don't have in public.

Takeaway: An "Unlikely to Build" column is one of the most underused features in public roadmaps. It closes the loop on ideas that won't move forward without making users feel ignored. They can see the decision was made, not just that their idea disappeared. It also reduces repeat submissions of the same requests. If you're using Frill, adding this status takes about thirty seconds and pays off in user trust for months.

Should your roadmap be completely public, or only viewable to users?

A public roadmap is typically available to the entire public, meaning anyone on the internet that stumles upon it, with no need to sign in. This is the right choice for most SaaS companies. You want prospective customers to be able to see your roadmap. However, if the idea of publishing what you’re working on makes you uncomfortable, you could choose to only make it available to users or paying customers. You can easily manage this with Frill, which offers SSO so only people with accounts can view your roadmap. Or, you can use Frill to set it to public.

How to build a public roadmap

While you can build a public roadmap with a project management tool like Productive, Trello or ClickUp, it’s better to use a platform that’s designed for managing feature requests. Otherwise, you’ll have to manually add users; ideas to your board. And if you use something like Trello, people will comment ideas in task cards instead of using your desired form or contact information—making the manual workload even higher.

Here’s how to build a public roadmap that will make it easier for you to interact with your users and fulfill your product vision.

Step 1. Choose a roadmap tool

The first step is to choose a platform built for managing your roadmap and interacting with users.

Look for something that includes:

• Feedback collection and organization - Your product management team needs feedback. Use one platform for feedback, public roadmap, and announcements so everything can be managed in one seamless workflow. Look for a tool with simple UX and single sign-on.

• Upvoting and commenting - Make sure that the feedback board includes upvoting and commenting so you can get feedback from other users on every idea.

• Public or user-only roadmap - The platform should offer a roadmap tool that can be set to public for everyone, or only viewable to people who are signed in with their user account to your SaaS.

• Announcements - The tool you choose should also include features for product announcements. With Frill, you get a page with a running log, and you can even include your recent announcements in a widget.

Step 2. Set up your feature request board

The next step is to set up your feedback and roadmap portal. Give it a name, set up SSO, and brand the buttons to your main color.

All new ideas will automatically go in your first status, which is usually “under consideration” or “considering.”

You’ll also need to set up your other statuses. We pulled some of the most frequently used status schemes from the above public roadmap examples.

Common status schemes:

• Under consideration, in development, shipped

• Considering, planned, upcoming, developing, testing shipped, unlikely to build

• Exploring, in progress, done, unlikely to build

• Under consideration, planned, launched

• Under consideration, planned, in progress, shipped

• Need more feedback, planned, in progress, done

You might also want to create some tags for users to add. This way, you can control the tags and set them up in a way that makes sorting easier for product managers.

Step 3. Let users know about your feedback collection process and public roadmap

Tell your users about your idea board and public roadmap. You can send out an email newsletter announcing the new portal and add a temporary banner to your website using custom banner templates. With Frill, you can add a small widget to your product so users can easily give you feedback at any time. You might also want to add a small link to your idea board at the bottom of onboarding emails and email newsletters.

Step 4. Interact with users who offer feedback

Effective customer feedback management requires timely interaction. Whether or not you end up using their idea, your users will want to know that you saw it and considered it. Try to reply to every comment within 48 business hours. Ask for more information, say thank you for the idea, and/or let the user know if you plan to implement it.

If you have users on wildly different plans (from free to thousands of dollars per month, for example), you might want to check which customer account the idea came from. Because you’ll have SSO enabled, it’ll be easy to tell which customer gave you the idea. If the customer represents your most ideal customer, you might give their idea extra consideration.

When other customers comment on existing ideas with very specific feedback and questions, make sure that you interact with these comments as well.

Step 5. Announce new features

Use your roadmap tool to announce product updates. This way, users can check ideas, planned features, and new releases all in one place.

For example, if you click on Frill’s Announcements tab, you’ll see a running log with all announcements.

One of our recent releases was the ability to embed videos into Announcements. This is great for 30-second or 60-second product marketing promotional videos or for Loom video tutorials. If the new feature is more complex, you might want to embed Q&As or webinar content. To deliver and manage such content seamlessly across channels, many broadcasters rely on TV playout software for scheduling, automation, and high-quality distribution.

Best practices for public product roadmaps

Public product roadmaps can be effective tools. But only if you use them correctly. Below are the five best practices to implement to get the most out of public product roadmaps for your SaaS business.

1. Use SSO

Requiring users to log in to view your public product roadmap provides some degree of access control, showing you who views your roadmap. It also provides valuable insights into user engagement because you can track who logged in and how often they logged in to view your roadmap. However, logging in to view your public roadmap shouldn’t be tedious. Simplify authentication by utilizing Single Sign-On (SSO) to streamline access.

SSO users don't need a separate login to access your roadmap. Instead, they can use one set of login credentials to access multiple applications, including your roadmap. For example, signing in with Google credentials to access your roadmap.

2. Allow upvoting

Allowing upvoting on your public roadmap lets users indicate the proposed features they want or dislike. The insight into your user preferences will help you make data-driven decisions regarding the features to prioritize for building and implementation. You’ll also have an easier time identifying the features your users don’t want so you can avoid the costly mistake of building them.

Lastly, upvoting enables customers and stakeholders to actively participate in the product development process. This can help improve customer engagement and make users feel valued.

3. Link roadmap additions to feedback

Linking roadmap additions directly to feedback involves letting users share feedback on your roadmap posts. Users commenting on your roadmap additions will quickly let you know if they are enthusiastic about your proposed features. It will also provide insights into the proposed features and enhancements to implement to boost your product’s perceived value to customers.

User feedback tools like Frill let you connect user feedback and feature requests to your roadmap. Users can then see the submissions you’ve decided to act on. Acting on feedback shows you value and pay attention to user contributions, making you a more attractive brand.

4. Stay flexible

Customer needs and preferences frequently change. Adapting your product to match and satisfy such changes is crucial to staying a successful SaaS business. If it’s time to change your product to match current user preferences and desires, you must adapt your public roadmap to reflect the planned modifications. Otherwise, customers will remain unaware of your commitment to staying up-to-date with their latest requirements.

5. Manage expectations

Don’t publish a product roadmap that gives stakeholders unrealistic expectations. For example, don’t set unachievable timelines to deliver upcoming releases and features. The same goes for overpromising product enhancements or upgrades. False expectations can lead to user frustration and disappointment that trigger loss of trust, negative feedback, and churn.

Avoid such outcomes by managing customer expectations with a clear, honest, and realistic roadmap that accurately communicates what users should expect. For example, your public roadmap should clearly state the status of each listed task and specify what each feature will deliver.

Frequently asked questions about public roadmaps

Should my roadmap be public or private?

For most SaaS companies, public is the right default. A public roadmap lets prospective customers see what's coming, gives existing users visibility into your priorities, and holds your team accountable in a healthy way. The main reason to go private (to require login to view), is if revealing your plans would give competitors a meaningful advantage. In most cases, that risk is overstated. The benefits of transparency outweigh it. With Frill, you can easily toggle between fully public, login-required, or a mix of both depending on what's right for your product.

What statuses should I use on my roadmap?

Keep it simple. Three to four statuses is the sweet spot for most products, enough to show meaningful progress without creating ambiguity. The most common scheme I see working well is Under Consideration, Planned, In Progress, and Shipped. If you want to add more nuance, consider adding an "Unlikely to Build" column to close the loop on ideas that won't move forward. Avoid overly technical language unless your audience is developers. Terms like "In Progress" and "Shipped" are universally understood, while "Staging" or "QA" are not.

How often should I update my roadmap?

At a minimum, review and update your roadmap once a month. In practice, the best roadmaps I've seen get updated in real time, when an item moves from Planned to In Progress, it gets updated that day, not at the end of the month. The more current your roadmap is, the more users trust it. A roadmap that hasn't been touched in three months signals that nobody is maintaining it, which is worse than not having one at all.

How do I get users to actually engage with my roadmap?

The biggest mistake is building the roadmap and assuming users will find it. You have to actively drive them to it. Add a link to your onboarding emails, embed a widget in your product, mention it in your newsletter when you move something to Shipped. The teams with the most engaged roadmaps treat it as a communication channel, not a static page. Every time you close the loop by shipping something that users asked for and telling them about it, you give people a reason to come back and submit the next idea.

Do I need to respond to every idea submitted?

You don't need to respond to every single one, but you should respond to more than most teams do. At minimum, acknowledge ideas that get meaningful votes, move items through statuses as they progress, and always communicate when something is explicitly not going to be built. The teams that respond most consistently get the most feedback. Users stop submitting when they feel like they're shouting into a void.

What's the difference between a public roadmap and a changelog?

They serve different moments in the user relationship. A public roadmap shows what's coming. It's forward-looking and gives users a sense of direction. A changelog shows what's already shipped. It's backward-looking and gives users proof of progress. You need both. A roadmap without a changelog leaves users wondering if anything ever actually gets built. A changelog without a roadmap leaves users with no sense of where the product is heading. Frill combines both in one place so users can move naturally between the two.

Ready to launch a public roadmap and idea board? Get started with one of Frill’s affordable plans.