Process for Managing Product Feedback

Continuous improvement to the product is the only way to build a successful business. It’s not something you can decide to put on hold for sometime and come back to later. If you do that then you run the risk of becoming obsolete with the ever evolving needs of customers.

Feedback on how to improve your product will come from a variety of sources. In the initial days of your product it might be ok to manage it on an ad hoc basis. There is no reason to burden the system with more processes if they are not required or might be an overkill. As the number of people who use your products increases, so will the feedback. You will at some point realise that you need to build a product feedback process.

We need to first understand where people feel most challenged in providing feedback. Find a solution for it before building out the process further. Keep it simple in the beginning. Sometimes we jump the gun and start looking at the tools that solve our problem without knowing what the problem is. Product teams often end up buying complex tools to manage their feedback process.  For small teams it ends up adding a lot of extra overhead. The same applies to the product feedback process. The feedback process should be:

You can start with an email address ’[email protected]’ or google forms to get the feedback. What’s important is to find the answers to the following questions to create your process:

I’ve shared my experience about these questions below:

Key sources from where you get feedback

In most cases it would be one of the following:

Internal Stakeholders

They are your key internal stakeholders who use the product everyday to:

Customers

They use your product to run their business. Their needs of their business might change. And that could result it request for new functionality in the product.

Prospects

People who are currently evaluating the product to see if it satisfies all their uses cases.

Types of Feedback

The feedback falls into four categories:

New product idea

This is a completely new product or feature that does not exist today. A lot of these come from the sales team in their conversations with prospects. They provide a view into the evolving customer needs and the competitive landscape for your industry. When looking at them take note of the following:

New feature in an existing product

The product exists but needs a new feature. This is true if you sell more than one product.

Update to an existing feature

An addition or modification to an existing feature that would extend its usability

Bug

Something is not working as intended. It can either be:

Information you want to collect 

You need to find a balance of how long your feedback form is. Keep two things in mind:

Below is the information that I usually put in the feedback form

In most cases you can  detect #1 and #2 so that the user does not need to enter it manually.

7 can sometimes cause confusion for some users. So if can omit it if you think that would happen with your team and do it later yourself.

The information you collect will be unique to your business. For example - bug reporting and product enhancement could be two different forms or processes. Support team might manage the former before putting it in the product queue.

Setting a priority on the feedback

Once you get the feedback the next step is to set a priority on it. You’ll go over the information provided to make sure you have everyting you need to get started. You then do the due diligence to find out the priority(P) on the feedback should be.

You can classify it into four priority levels:

Updating the feedback

Based on the priority of the request the status of the request is then updated to one of the following:

Visibility: Internal vs External Feedback

How much visibility do you want to provide stakeholders into the feedback process? It is important to consider this when you build out. In an ideal world you’d want everyone to be able to dig down into the last level of detail. All the information that a product manager looks at should be available to everyone. But it might depends on how your organization is set up and works with its customers. Everyone looking at each development task might not be ideal or the best use of everyone’s time.

Conclusion

You will never be able to build everything that users ask for no matter how big your development team is. What is important though is that the users feel:

A strong feedback process does that!

Use every opportunity you get as a product manager to: