Stop Guessing. How to Organize Customer Feedback That Guides Your Roadmap

Hi, I'm Daniel, and this is the Airtable that we use to help our customers know where to focus on, what are their users' problems and challenges, and what to prioritize. So it's less second-guessing and more value delivered for the end users. Most of the teams I work with collect customer feedback one way or another. You know, emails, customer support tickets, reviews on different websites, but few actually use them at their full potential. All of them know how important that is and how much it can impact their roadmap, but They either don't have time, they don't know how to do it, or it's just too much to take care of. So all of these end up being stored on emails, documents, spreadsheets, Slack threads, and so on. Some might bring it up, and if they have time on development, they might just do it. But that's definitely not a strategy you can build a business on. To give our clients clearer view of where their users struggle and what they actually need, we started to organize all these feedback in Airtable. It's not just another place where you throw everything and then forget about it. It's a structured database that helps you identify which parts of the product are affected, where your customers struggle the most, what features or improvements they are asking for, and so much more. This is how we actually do it. The first part that's really important is to map out the product. We usually structure this in 2 parts. We have the product components, which are the big parts of the product, and we have the subcomponents. That basically means that we will break down each of the components to more granular level to identify the subcomponents that we want to track. All of the feedback will be tracked on these subcomponents. You can see it here on the screen. For an example, we have sign up and login, onboarding, dashboard, company, job post, candidates, and offers. These would be the components. And besides the web platform, you might have a desktop app, a mobile app, and so on. So you can do this specifically for each platform. But in this case, let's say we have just a web platform. So we have the web platform, then we have the components. And for each of the components, we have the subcomponents. So for example, for signup and login, you might have a signup part and the login part. For onboarding, you might have the onboarding questionnaire and you might have a setup company profile in this case. Then you have a dashboard and maybe dashboard is just something generic. So you would say a general dashboard or dashboard general as we usually put it. Then you have the company profile. And let's say for posting a job, you have different subcomponents like create and edit a job, the status of a job, seeing candidates for a job. And for the candidates, you might have different actions like candidates actions and scheduling a call. And for offers, you might have the option to send an offer and to manage the offers that you send. So this would be a high level of, as I mentioned, the platform. The components, and then the subcomponents. We usually map this in Miro or in FigJam, so everything is structured here first. Then with all this information, we move to Airtable. And this is how we set it up. We have the feedback tab, the insights, we have opportunities, product subcomponents, product components, platform, and user and companies. This is just an example, so I will walk you through on how this is set up. You can add a bunch of more information depending on the company size. And what you actually want to track. So we usually start with the platform. As I mentioned, you might have web, mobile, desktop, whatever. You can put it here depending on what you track. Each of these platforms are then connected to product components and product subcomponents. So if we move to product components, you will see as we had it in FigJam, we have the signup, login, onboarding, dashboard, company profile, job posts, candidates, and offers. Now we go even more granular. And for these components, we will have the subcomponents. And you can see them here. Candidates is connected to these 2 subcomponents, company profile to this one, dashboard for this one, and so on. So we have all of these subcomponents here listed and everything is connected. So you have the subcomponent connected to the components, the components connected to the platforms, and then you have the feedback part, which is usually where you spend most of your time. You can see here we have We have the name, we create an identifier, so it's not just the name. So for the identifier, we have the name, we have the date, an ID, and the status. Because you don't want to just keep feedback around forever, how I set it up at this moment is that if the feedback is older than 3 months, then we will consider it archived or inactive. So the status will change, and this will also influence the next steps when we actually count these. You can see here we have a formula for counting the feedback that's still active because these are not older than 3 months. They are counted as active. And then for the feedback, we have something like this. It's connected to a user, obviously. And then we have a couple of identifiers or descriptions of the user like role, company name, feedback type, where it comes from, the purpose of the feedback. Any text that we want to add goes here. The content in itself, and depending how long the content is, sometimes we extract some highlights. And if it comes from different other sources like review pages or forms or tickets and so on, we might add a feedback link here so we can go back there and follow up if it's needed. And then everything is connected to an insight. So we don't count the feedback as one unit, but we connect it back to an insight. For insights, we use the I would like to kind of statement. So I would like an easy way to whatever. I would like to be able to do whatever. I would like the product to be stable, easy to use, so on, so on. And then the whole reason behind this is basically to pull multiple feedback points into one insight, and the insights then is connected to the subcomponent. So if we go through the feedbacks, then you will see that we have the feedback, we have the user, as I mentioned, we have the content of the feedback, and we have the insights. And now you can see that we have an active count here of 2. That means that 2 still active feedback points are connected inside of this specific insight. And there are a bunch of other things here. So status, you can change the status here if you want. Like if something was already reviewed or processed or archived, then you can just change it here. If we change the status of this specific feedback to, let's say, archive, then you will see that the still active status changes to archive or inactive in our case. And the count here moved to 0 and this count moved to 1. That means that we don't consider this feedback anymore. It happens the same way if we change to archived here, or if the feedback is older than 3 months. Going a bit back, so you see we have these 4 feedback points here with the connections and so on. We have the insights here. And now if we move into the insights part, you will see that the insights are actually grouped by subcomponents. So we have insights for the specific subcomponent of creating and editing a job. We have one for the job status, we have one for the scheduling a call and so on. And we sum it up by active count to see how many feedback points we have still active for this specific subcomponent. And this will help us to see where users struggle, what kind of features they are asking for, where we should focus on. And then we can make different decisions. So we can maybe follow up with some of these customers and understand better what are their needs. What we should focus on, what challenges they have, how they are using the product. We might use the information that we have here to maybe draft a solution or collect more feedback, or just keep an eye on this specific subcomponent to see if we have more problems or feedback or challenges or requests coming into this specific subcomponent. So this is how we actually use the subcomponents and this whole infrastructure to prioritize the parts of the product that we want to focus on. Then you can also do a bunch of other things. So you can connect insights to opportunities and you can track them here as well. From here you can then move it into your task management system and so on. Some other interesting stuff that we've done with, with some other companies is that based on their ICP or non-ICP level, we give different ranking for different companies. And then we take that into consideration when we weight the feedback. So instead of each feedback being weighted as just 1, some might be weighted as 2 or as 4, depending on how important is that customer for the client. So yeah, kind of this is the whole structure. Obviously there are a bunch of other things that you can do. We have some automations in place with Some of the customers we work with, that means that we drag into the system feedback from different forms like Intercom, different forms that we set up in different places that either the support team, either customers can fill in so they can send into this system feedback directly. There are also interfaces that you can use, as you can see this one, to track different information like feedback type, feedback purpose, categories, usernames. You can also go back to see what happened last week. Same for the insights. You can see which of the insights attract more feedback, and you can track all this in order to help you prioritize what you should do next. Obviously, all this can be customized for your own need. So yeah, this is just a starting point. Hope this was helpful. And if you have any questions, feel free to leave a comment or reach out. Happy to help anytime. Thank you.