How do you write a Product Feedback Policy?

Please share some good examples and best practices!



1 comment
  • Think of the most conservative Feedback workflow you want to implement, in particular the triage piece, and document that in your Product Feedback policy. It's tempting to be more heavy handed with triage when you first adopt a feedback management system, but this can quickly become unmanageable. You want to set expectations with your customers that their voice counts, and the data they submit to Feedback will be used, but that does not mean that every feature request will be built. It's easier to set the tone from day one, rather than have to re-educate users about a workflow you've had to adapt as you scale.

    Think of the type of data that you want your customers to send in and outline this clearly in your Product Feedback Policy. Optionally remind your users that this is not the place for support tickets or complaints.

    Be transparent about your processes. Will your product team be checking each request, or will requests only be reviewed once they have reached a certain threshold (for example, after it's hit 10 votes)? Does the product team have a regular cadence to review and consider which top requests to build? Will you be sharing a roadmap in Feedback? Will you be conducting research by sending Feedback emails? Document this here so your customers know what they can expect after they send a feature request in.


Please sign in to leave a comment.

Didn't find what you were looking for?

New post