- What is a product feedback policy?
- Why is the policy important?
- What should the policy cover?
- Where should we publish our feedback policy?
What is a product feedback policy?
Your product feedback policy governs and lays out the whole process you employ to gather and manage feedback.
If you want to see an example of a product feedback policy, then here is our very own version: Receptive's Product Feedback Policy.
Why is the policy important?
It's important to create a policy as you start using Receptive. Having a policy ensures that everyone (both team members and customers alike) will understand how they can submit feedback, and how their feedback will be managed.
It sets expectations from the start and keeps your organization on track with your feedback process.
Creating a policy is easy and hassle-free, and should take up very little of your time.
What should the policy cover?
Firstly, you need to explain your approach to feedback. State your intentions.
How important is feedback to your organization?
What will you be using it for?
Next, you can explain the general process.
How can people submit their feedback?
What happens to it from there?
How often is it reviewed and who by?
Finally, explain how customers and team members can be kept in the loop.
How can you track the status of the feedback?
Are people told when their feature is released?
Below are some ideas to help you answer the questions...
Your Feedback Approach
You should explain that you take feedback extremely seriously and that it's crucial to your product and as an organization.
Chances are, you'll be using the feedback you collect to figure out the most important additions to the product, based on the priorities of both team members and customers.
The General Process
The way that people can submit feedback depends on how you integrate Receptive with your product.
It could be that you use the in-app widget and so customer and team members can click the button at the side of the screen. Or it might be that they navigate to the help menu within your app and click on a link from there.
Within your policy, it would be wise to send your team members and customers to relevant help docs to show them how Receptive works and how they can use it.
You then need to map out your process for them.
If you follow the guidelines that we establish in the Launchpad series, then your process will look a little something like this:
1) New requests are set to "Awaiting Feedback" while we wait for other users to vote and comment on them.
2) Our product team meets regularly (weekly/biweekly/monthly). In the meetings, we review the highest priorities from customers, team members, and prospects.
3) If we decide to build a feature, the status will be changed to "Planned" or "Building" and we'll aim to give a timeframe of completion on our roadmap.
Kept In The Loop
You should end with a few points about how you'll keep those who submit feedback in the loop.
With Receptive, this is easy. Customers and team members who have submitted (or voted to say they wanted) a feature will automatically be notified if the status of that feature changes.
Mention that you'll try to give an explanation whenever a feature is rejected in order to help them understand your reasoning.
Where should we publish our feedback policy?
We recommend publishing a full, in depth version of your policy on your knowledge base. Then taking relevant sections for your marketing materials, Receptive announcements, blog posts, etc.
And finally, we recommend linking to your policy when moving requests to "Awaiting Feedback" status in Receptive.