Published in

Canonic.org

5 min readNov 30, 2021

Should your roadmap be public?

A question, we here at Canonic, recently faced. Growing SaaS businesses, especially those with a bottom-up marketing strategy, often contemplate whether their roadmap should be public. A lot of fears, a lot of benefits!

Should it be public? Should we build it ourselves? What if our competitors gain an advantage by having a look?

Making our roadmap public has given us valuable insights into our product, from early feedback to prioritizing and understanding our users better. In this article, we discuss some of the benefits & challenges of making it public.

What’s a public roadmap?

Essentially a public view of your platform/business’s upcoming features and plans for the product. It can be a simple Kanban board showing cards denoting features bucketed by progress. They often allow engagement and interaction on the roadmap such as asking users to upvote or submit feature requests.

Isn’t a public roadmap risky?

Here are some of the more common fears of making a product roadmap public.

The competition might steal it!

Don’t fear the competition! If you continue to dedicate all your energy towards making the customers happy and gaining their loyalty, it’s the competition that will fear you.

“You can only avoid competition by avoiding good ideas.”

- Paul Graham

If they really want to, competitors can get that data regardless through a number of ways. The benefits of building trust and getting early feedback far outweigh the downside of the competition checking out your roadmap.

You can minimize the impact further by being slightly selective about your roadmap, and leaving your top-secret features out of it! You can also decrease the visibility to only logged-in users (especially if you have some sort of free access).

We are agile! Things change rapidly

Another fear that we had at Canonic. Given, we are new and growing quickly, how do we commit to the timelines while maintaining the flexibility to pivot?

One of the key reasons for making a roadmap public is building trust through transparency. Users understand that timelines change, priorities change, plans change! Keeping users in the loop can go a long way in building this trust and they won’t mind the changes.

Roadmaps also indicate looser timelines and buckets instead of exact deadlines (Backlog/In Progress/Next/Released). It still gives users a general idea of what the company is focused on, and what the future looks like.

Why make it public?

Get early feedback

This is incredibly valuable for early-stage companies. Without even building the feature, companies can get a lot of feedback from actual users through upvotes and comments.

As we all know, user feedback is extremely important. The roadmap is another point of engagement, another chance to get feedback. It also helps validate some of the choices and builds more confidence about the overall direction within the company.

“Feedback is the breakfast of champions.”

– Ken Blanchard

Build trust & excitement

For developer tools, building trust is paramount. It’s a long and arduous journey and once you gain trust, everything becomes a tad bit easier.

Transparency is a massive factor in gaining the trust and loyalty of your users.

Giving users a peek into upcoming plans, features, and ideas, also leads to a build-up of excitement. Apple events and the hype that usually surrounds them is perfect example. For SaaS businesses, the customers are often using your product to succeed in their businesses. As a result, they often get excited about upcoming features and the potential positive impact on their work.

Helps the company internally too!

When you make your roadmap public, you end up putting a significant amount of thought into it. This leads to an alignment across the founders, the team, and other stakeholders. Everyone is also a lot more committed to shipping those features, especially when there’s a lot of positive feedback and excitement on it!

How do you make a public roadmap?

Build v/s buy

Once you decide to make your roadmap public, you need to decide how to get it out there to everyone. The eternal question of whether to build or to buy comes up.

A roadmap is a simple enough feature but comes with its own challenges. Not only should it display the roadmap, but it must also have multiple points of engagement with the user. This includes the ability to upvote items, give feedback on them, and request new items to be added. This leads to needing at least a week’s worth of developer bandwidth. You also need a CMS to be able to keep the content up to date.

The other option is to go the buy route, this usually means buying/subscribing to a tool that allows you to publicize your roadmap. Incredibly easy to get started but does have its own cons. They come with their own branding and it’s usually complicated to embed these roadmaps within your own platform.

However, as of writing this article, it’s 2021. There’s a sort of middle ground creeping up into the arena. What if you could lower the ROI bar on building it yourself? Without putting in much effort you get the benefits of completely owning certain aspects making customizability infinite.

Low-code is an emerging new way to build tools such as roadmaps, and simple and tertiary portals and embeds.

Low-code

Low code platforms increase the ROI by lowering the effort and knowledge required for products to be built. That means that you can get the same output by dedicating less than 10% of the engineering bandwidth that would be required to build the feature out by conventional means.

By handing off, let’s say, the backend development to a low-code platform, a frontend engineer on his own can build an entirely functional public roadmap in a couple of hours.

There are different levels of low-code depending on your needs:

Platforms that involve no code at all make it less functional but easier (Trello, Airtable, etc.)
Low-code platforms that are more function but expect users to have some basic technical knowledge. (Canonic, Firebase, Hasura, etc.)