Process for Managing Product Feedback

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:

1.Easy to use
3.Not time consuming for the users
4.Easy to manage for the product manager

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:

1.Who is giving the feedback?
2.How do they provide the information?
3.Is the information enough?
4.What information do we need to make the feedback actionable
5.How often do you want to go through the feedback?
6.How much time does the product team have to manage the feedback 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:

Demo it to prospects
Onboard new customers
Troubleshoot problems that existing users might be facing
Build and test updates


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.


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:

1.What is the problem that the user is trying to solve?
2.Is there a feature that can solve the problem but isn’t obvious enough?
3.Is there a workaround that can be a temporary solution

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


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

1.An issue with the product that you need to fix OR
2.We are trying to use a feature in a way that it’s not supposed to work

Information you want to collect 

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

1.It should give you enough information to take it to the next step.
2.It is not so cumbersome that it deters people from giving feedback.

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

3.What do you want to provide feedback on?
1.New Product
2.Enhancement to existing product
4.What is the problem you are facing?
5.How would you like us to solve it?
6.Add any screenshots or videos that might help us understand the problem better
7.How important is it to fix the problem?

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:

1.P1: This is the highest level of priority and needs immediate attention. The engineering team needs to start working on it immediately.
2.P2: It is important to work on this update and someone in the engineering team would pick it up in a week or two.
3.P3: It would be nice to have this feature and someone would start working on it within a month.
4.P4: This is a nice to have. But there are no plans to work on it in the immediate future.

Updating the feedback

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

1.Will likely not do: These are P4 requests that are not likely to be worked on
2.Backlog: This is a prioritized list of all the items that will be worked on. Generally the items at the top of the backlog are put in the development teams queue and picked up by them when there is capacity in the team
3.In Development: The update is being worked on by the engineering team and will be available once it’s ready
4.Released: Work on the feature is done and it is available to everyone.

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.


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:

1.Empowered to share their opinion
2.That they are being heard
3.There is a rationale behind why some things are built and others not.

A strong feedback process does that!

Use every opportunity you get as a product manager to:

1.Share he product vision and roadmap so that everyone knows how the smaller updates fit into the larger piece of the puzzle
2.Highlight the user feedback that makes into a product release

You may also like