Another approach for gathering user feedback is by publicly sharing what is currently in the backlog and what isn't. One team that publicly shares which features they are working on is the Azure DevOps team. Naturally, this list does not contain all features the product group is planning. The reasons for this might be to keep a competitive edge or to keep some new feature secret until a big announcement. However, their backlog provides a good insight into what is currently brewing.

Adopting this practice allows the users of a product to reach out and comment on this public list. It allows them to request features to be moved up or down the list of priorities and they can share which features they are missing.

This can bring the following advantage to a company: When users engage with feedback on the list of features, they are encouraged to specify why they make a certain request. This might provide new insights into customer demand and may lead to a shift in priorities.

There are also downsides to this approach:

• Not all users will engage in and provide feedback on a public backlog. This might result in a bias toward more vocal or more demanding customers in the group that provides feedback. While not necessarily an issue, it is good to keep this in mind.
• Engaging with users over feature requests or features that they want to be moved up or down the list can be very time-consuming. Especially when comparing with in-product feedback, this approach takes more time.

As well as having a public feature roadmap, there are also other ways to give users an insight into what a company is currently working on and what they are planning. Some examples include the following:

• UserVoice: UserVoice is a platform that allows users to propose new features and vote on features proposed by others. It allows gathering user ideas, without opening the actual backlog to users.
• Bugtrackers: If customers are very vocal about reporting bugs and errors in an application, it can help to open up a bugtracker. This allows users to see which issues are already known and if and when they might be fixed.

Public backlogs and UserVoice-like platforms are more common than open backlogs. Open lists of bugs or issues are more often seen in open source development.