As product people, we tend to think of feedback as a thing that happens at a specific moment in time. A user sends us feedback, we read it and then we store it in the back of our brains. And then it just sits there until one day you’re sitting in a meeting and someone says, “what was that thing the customer wanted?”

But the reality is feedback has a series of lifecycle stages, just as customers do. At Parlor, we manage feedback through a process so that we’re being thoughtful about the feedback we collect and how it aligns with work we’re thinking about doing.

To really make the most of your user feedback, shepherd each piece of feedback through a series of lifecycle stages as it matures from an idea a user shares with you to a feature that makes it to your product. So what’s the process that takes that user’s opinion and eventually turns it into work to be done in your product? In this post, we’ll define six stages of the user feedback lifecycle:

  1. Collection
  2. Assignment
  3. Association
  4. Validation
  5. Alignment
  6. Prioritization
A moon in different phases


The first step of the feedback lifecycle is collection. User feedback comes in through many different channels. We think of feedback channels as either reactive, such as feedback that users send in through chat, social media channels or your customer-facing teams, or proactive, such as feedback that you collect through in-app or emailed surveys. The collection of feedback is a big topic, which we’ll cover in a subsequent post.

Would you like a response?


When feedback comes in, you should immediately assign ownership. Who’s responsible for shepherding this piece of feedback through its maturation process? Without clear ownership, no one will act on the feedback. The person responsible needs to decide:

  • We’re not going to work on this, because it’s immediately clear the feedback isn’t relevant
  • We’re going to explore it deeper or
  • We’re definitely going to work on it 

So who’s the best person to assign it to? Well, it shouldn’t de facto be the person who’s looking at the unassigned customer ticket bucket. It’s not their job to own the feedback lifecycle just because they’re supposed to manage unassigned customer tickets. 

You should assign feedback to the person for whom it’s most relevant. Often this will be a combination of someone on the product team and someone on the customer team. That said, it can’t just be a customer person, eventually a product or UX person needs to be involved. It’s OK for it to start assigned to one person and later be assigned to another, but there should be a single owner at any point in time so that one person feels responsible. 

One way to help speed up with process is to actually ask customers what type of feedback they are submitting and have each type go directly to the appropriate team. For example, feature requests go to the product team that can work on assigning priority, while bugs can be sent directly to engineering for triage. Not only does this free up the support team from having to route feedback, but it creates a smoother customer experience.


After the feedback has been assigned, it needs to be associated with other similar types of feedback. The association gives us an idea of how much weight we should give this piece of feedback and then associate it with projects related to those requests. For example, a piece of feedback associated with a thing we’ve only heard once before should be weighed far less than something we’ve heard 30 times.

Let’s look at Netflix as a familiar example. Say they get a piece of feedback that says a user wants to be able to change the profile photo associated with an account. Or users want the ability to turn off autoplay. These are all a collection of requests related to personalization of the experience. A different type of feedback would be users reporting that they’re not seeing content relevant to them, which is related to the recommendation algorithm.

So if Netflix has a project to overhaul the personalization options for Netflix, they’ll want to go look at the different feedback associated with this project to figure out what specifically they need to build, based on what the biggest pain points are.

Another type of association, primarily relevant to B2B products, is association to the customers or users who made the request. This association allows us to assign a value (e.g. ARR) with particular feedback, so we can understand the recurring revenue of companies who want this thing, and therefore, the impact on the business. For both B2C and B2B products, you can also associate feedback with a given type of customer, e.g. beta testers, power users or highest paying customers.

Parlor customer council


Validation is the most important stage of the feedback lifecycle. It’s important to remember that feedback collection is not the same as feedback validation. It’s natural to want to immediately react to feedback received, but until it’s validated, feedback is just an opinion, not fact or truth. So we have to validate that the feedback is legitimate and deserving of our time and attention.

There are two ways that we validate feedback, first by going deep and then by going broad. We go deep by engaging with the users who shared that perspective. Why do they feel that way? What are their pain points? User interviews are the most typical way to build this deeper understanding from the user.

Once we have a deeper understanding of the specific issue, then we need to get a broader view to see how pervasive that perspective is. How many of our users share that view, if any? Surveys (ideally in-app surveys), focus groups, and concept validation are all effective ways to get this broader perspective.

Once we’ve gone both deep and broad on the issue, we’ll have a much better understanding of what the need or pain is, as well as how pervasive it is across our user population, which will tell us whether we should move forward with the potential work.


After feedback has been validated, the next step in the feedback lifecycle is to make sure that the work required to address this feedback is aligned with work we’re actually planning on doing. Unless it’s a critical issue, it shouldn’t utterly disrupt our plans and vision for the future of the product. It may be that a validated piece of feedback isn’t worth addressing in the short term, because it’s not aligned with our broader goals. Teams have a limited bandwidth so it’s important to make sure the energy they’re investing into the product is going to serve the broader vision and needs of customers.


Assuming the validated feedback is aligned to planned work, now we need to prioritize it. Is this something we’re going to do in three months? That is, it is aligned with work we’re planning on doing then? Is what we learned in the validation step so important that we’re going to re prioritize items to address it immediately? When we should do this work is determined by what we’ve learned about its potential impact relative to its cost and how it aligns to potential work that we already have planned.


Now that a piece of feedback has made it through these lifecycle stages, it’s become “work to be done” rather than “a problem to be considered”. And our team is ready to move forward to address it. This may sound like a lot, but we’ve found it ensures that the voice of the customer is thoughtfully integrated into our product plans and aligned with the strategic direction of the product. Parlor makes this process easy for you by creating a single system of record for customer feedback and user insights. By creating a culture of collaboration with your users, you’ll be sure to delight customers and increase their lifetime value for your business.