Public roadmaps have become more popular over the past couple years, for good reason. Founders have written about why they have a public roadmap. The main reasons being that:
- Your users will love you for it
- You will improve your product with user feedback
- You will keep your team accountable
Making your roadmap public is a bold way for your team to say:
Hello lovely users, your voice is so important to us. Here’s what’s coming up in AwesomeApp. Let us know what you think!
A real win-win-win.
Given the above benefits, we still hear some concerns that we’d like to debunk. Here are the most common concerns we hear:
My competition will see what I’m working on
Yes, being transparent means that anyone, including competition, can see what you’re working on. Countless founders have written about how they worried too much about competition in the early days. Their conclusion: focusing on the competition is a distraction! Stay focused on executing your roadmap to the best of your ability and let your competition worry about you.
If your product is in beta, great! Be transparent about your roadmap from the start. Showing that you care about user feedback builds trust — the foundation of all strong relationships.
Buffer, champions of transparency, see the advantage of building in the open: “We think this could raise the bar for all of us, and challenge Buffer to build the best, most valuable features possible.”
As Sam Altman says, very few startups die from competition. Most die because they fail to make something users love. And let’s be real, there are several other ways your competition could find out what you’re working on.
We don’t want to tell users we can’t build something they want
The more you can engage your users in your product development, the better. Feedback allows you to be more confident in your decision making. Yes, your users will request features. Here are the two ways this pans out:
- You agree with the request and add it to the roadmap. Users keep you accountable to execute. Everyone’s happy.
- You disagree. Maybe it’s not a part of your team’s vision, or a slew of other reasons. Saying “no, and here’s why” is infinitely better than silence. Your users are people, they’ll understand and appreciate the transparency.
There will be times when something is highly requested but doesn’t fit the bill. Great product teams have established processes to determine what gets prioritized, and what doesn’t. Product development isn’t a democracy!
The feedback will be biased to a small, vocal minority
Public roadmaps are a great way to get:
- A pulse on demand of features in the pipeline
- Feedback on how a feature should be implemented
You can expect around 1% of your users to voice their feedback on your roadmap. Bias is a problem and can be harmful if not weighed against other sources of feedback.
Lower the risk of bias by getting feedback from a variety of sources such as a select group of users, your internal team, and quantitative data. Slack’s first PM, Kenneth Berger, talks about the whole range of biases that can occur in product feedback and how to interpret all the data.
A public roadmap is one method of soliciting feedback. There are several other methods that will all give you different signals. Building the wrong thing means costing your team time and effort. The more signals you have, the more informed you’ll be in building your roadmap.
We ❤️ having a public roadmap
As users, it feels great to have a say in the products we love using. But often our best efforts to give feedback are met with dead-end, canned, responses. Public roadmaps are a great way to build a brand around transparency while getting valuable feedback in return.
The boldness of putting your roadmap in the public brings advantages that far outweigh any of the above concerns.
Here are some examples of public roadmaps we love:
Repl.it – Cloud coding environment for any language
Flatsome – Multi-Purpose Responsive WooCommerce Theme
