CTC2: How to organise feedback without flooding your backlog
Here's how to stop your backlog from becoming a mess.
Ever opened your backlog and felt overwhelmed?
Product inputs can come from many different places. However, not all of this data is equal and actionable. Dumping all of it directly into your backlog will only lead to chaos.
How can you effectively manage this feedback without your backlog ballooning into an unmanageable mess?
Backlog vs Feedback
I think of the backlog as a list of actionable items that we definitely should be doing. An actionable backlog item should have a clear problem statement, acceptance criteria, and an owner. The backlog item should be refined/reviewed with the team, and sized.
The backlog can contain spikes - discovery work - if they are clearly defined and timeboxed.
The backlog should not contain unclear tasks, ideas, feedback, or anything that’s a “maybe”. A sure sign of a task that does not belong on the backlog is one that has a title and no description - or very little in the way of details.
Feedback does not belong on the backlog. As a product manager, it’s up to you to filter this information and make decisions based on it - which can include deciding to take no action. Your job isn’t to simply log all the feedback as tickets.
What are the different types of product feedback?
User feedback: This can include general comments, usability issues, wishlist items, or even complaints.
Client and stakeholder requests: These can come from your sales teams, support staff, or senior stakeholders keen to get features onto your backlog.
Bugs and technical debt: Quality improvements to your product, tidying up after taking shortcuts to get something out the door, or routine refactoring due to library upgrades, performance issues, or simply things your team didn’t know when the code was first written.
Opportunities and bets: Big ideas that don’t neatly fit elsewhere.
So how can you store feedback, and make decisions on it?
User feedback can be held in a central database. This can be as simple as a Notion database, or a dedicated tool such as Google Sheets. You can look for common trends such as opportunities or emerging problems: if several people mention the same thing, maybe that’s worth pursuing. Don’t react to every single comment if only one person says it, unless it clearly aligns with your vision - or is simply a great idea!
Client and stakeholder requests can be held in a similar database to user feedback - though likely not the same one. Unlike user feedback, client and stakeholder requests are the types of feedback you’ll normally need to respond to. You don’t have to do everything immediately, or even at all, but you need to consider the requests and respond with clear reasoning as to why. Keeping track of past decisions can be beneficial if the same requests come up, so you can review your previous response and also consider whether things have moved on since then.
Bugs and technical debt may live on the backlog, if they are things you will be addressing soon. You could also maintain a database of known bugs and tech debt on Notion or a similar tool. This means you don’t lose the information, but you aren’t holding onto a long list of tickets for when you eventually get to them. Creating documentation can also help with planning how to address this type of feedback, instead of looking at individual tickets in isolation.
Opportunities and bets: again, these could live in a database and should be reviewed periodically. Along with most other, these should be quantified. However, quantifying the impact of a bug is different to looking at the potential value of a bet. Bug impact is a lagging impact (it’s in the past) whereas opportunities or bets are a leading impact (we’re trying to predict the outcome). So, even if a bug affects 100 people and a bet could benefit 100 people, they aren’t identical value. Fixing a bug removes a known issue, whereas a bet has an unknown benefit.
In summary
Don’t put feedback directly on the backlog. Filter it first.
A structured feedback system helps you cut through chaos, stay focused, and build a stronger product — without drowning in backlog clutter.
Hi, I’m Ben Barden. “Cutting Through Chaos” is about organising messy, chaotic information in product management. Head over to the About page to find out more.
If you found this post useful, why not subscribe below?