Most teams we work with collect customer feedback one way or another — emails, support tickets, reviews — but few use it to its full potential. Everyone knows how much it should impact the roadmap, but they don't have the time, don't know how, or it's just too much. So it ends up scattered across documents, spreadsheets, and Slack threads, and occasionally someone builds something when there's a spare moment. That's not a strategy you can build a business on. To give clients a clear view of where users struggle and what they actually need, we organise feedback in a structured Airtable — not a place you throw everything and forget, but a database that tells you which parts of the product are affected and where customers struggle most.

First, map the product

The foundation is mapping the product into components and subcomponents. Components are the big parts — signup and login, onboarding, dashboard, company profile, job posts, candidates, offers. Then you break each down to a more granular subcomponent level, because all the feedback gets tracked against subcomponents. Signup and login splits into "sign up" and "login"; onboarding into the questionnaire and "set up company profile"; and so on. If you have web, mobile, and desktop, you can do this per platform. We usually map this in Miro or FigJam first so everything's structured, then move it into Airtable.

Then, structure it so feedback rolls up into insights

In Airtable, platforms connect to components, components to subcomponents, and then there's the feedback itself — where you spend most of your time. Each piece gets an identifier (name, date, ID) and a status, because you don't keep feedback around forever. We set it so feedback older than three months is archived or inactive, and a formula counts only what's still active. Each piece links to a user (with role, company, feedback type, source, content, highlights, and a link back to the original ticket or review for follow-up).

The key move: we don't count feedback as standalone units. Each piece connects to an insight, written as an "I would like to…" statement ("I would like an easy way to do X," "I would like the product to be stable and easy to use"). That pulls multiple feedback points into one insight, and insights connect back to the subcomponent. So when you look at a subcomponent, you see how many active feedback points sit underneath it — which tells you where users struggle, what they're asking for, and where to focus. From there you can follow up with customers, draft solutions, or just keep watching a subcomponent for more signal.

Going further

You can connect insights to opportunities and push them into your task management system. We've also weighted feedback by how important a customer is — based on ICP fit, some feedback counts as two or four instead of one. And with some clients we automate intake: feedback flows in from Intercom and forms that support or customers fill in, straight into the system. Interfaces let you track feedback type, purpose, categories, and usernames, and review what came in last week or which insights are attracting the most feedback.

It's all customisable — this is a starting point, not a finished template. But the principle holds: structure feedback so it rolls up into insights tied to real parts of the product, and your roadmap stops being driven by opinion.

Want help setting up a feedback system that actually drives priorities? Reach out.