Curate a product feedback database
where so-called product ‘feature requests’ belong 2025-10-28 #product #management
Product managers value feedback about their product, because its broad and unfiltered customer perspectives help them identify product problems and opportunities. Curating a product feedback database makes this work more systematic.
The feature request problem
As a product manager, you receive a lot of feature requests. Naive teams add these requests to their development backlog, creating the infinite backlog problem.
Teams that ignore feature requests choose to miss out on their value, and create unnecessarily conflict with the stakeholders who share them. To stop talking about requirements, teams must also stop talking about feature requests.
Product feedback
When you reframe feature requests as product feedback, adding to a development backlog stops sounding like a good idea. It also better describes its actual value: a signal about how people experience the product, rather than something you have to build.
Product feedback belongs to the person who shared it; you don’t get the same feedback from everyone. To understand product feedback, you need the context you get from knowing who shared it. Therefore, you need to store feedback from different people separately.
Creating a database
Store product feedback in a separate ‘database’. You don’t need anything complicated, but you do need something that can keep growing as you continue to receive feedback.
Each feedback item typically consists of text or images. You may also find one or more of the following metadata useful:
- date received – for focusing on recent feedback, and identifying trends
- title – for searching and browsing, especially when the text doesn’t include likely search terms
- features – related product features, so you can review feedback about a specific feature
- category – the feedback topic, such as a user job-to-be-done
- customer – for B2B products, where some customers matter more than others, and so you can review a customer’s feedback before meetings with them
- user ID – for B2C products, where you don’t need to identify the user, but can use pseudo-anonymous unique identifiers to identify duplicate feedback
- source – maybe only for curiosity value, or if you want to track which sources provide the most feedback.
In theory, you don’t need to organise the database, because you’ll use the metadata to search, browse, and filter. However, depending on the tool you use, you might need a default organisation.
Organising the database
Start with the simplest thing that could possibly work: copy feedback into one or more documents. Group feedback by month, with a new ‘folder’ each month, so they don’t grow indefinitely, and you can easily browse recent feedback.
In practice, you might have a tool that supports hierarchical organisation. If you would find that exceedingly satisfying, rather than a pain to maintain, use one of three kinds of trees:
- product hierarchy – an existing product’s feature hierarchy
- job tree – a hierarchy of what users want to do, including as-yet unserved needs
- opportunity solution tree – a hierarchy of business outcomes, approaches to improving them, and solutions to implement those approaches.
Choosing the right hierarchy can give product discovery a head start, by illuminating what matters. When you can easily see the number of items and the number of unique customers for each topic, it quickly becomes obvious which topics dominate product feedback.
