Our team’s transition from a fragmented system of product feedback—spanning Slack threads, support tickets, and scattered spreadsheets—to a centralized, queryable repository in Airtable has significantly improved our ability to prioritize and act on user insights. While dedicated tools like Canny or ProductBoard offer robust roadmapping features, our primary need was a highly customizable, low-cost system for ingestion, categorization, and initial analysis. Airtable serves as that critical "source of truth" layer before items graduate to our formal product backlog in Jira.
The core structure of our base is built around a single table, `Feedback Items`, with carefully designed fields to enable methodical filtering and cohort analysis. The schema is as follows:
**Key Fields in `Feedback Items` Table:**
* **Record ID:** Auto-generated unique ID.
* **Feedback Text:** The raw, verbatim user comment or request.
* **Source:** Single-select (Support Ticket, Intercom Chat, App Store Review, Sales Call, NPS Comment).
* **Reported Date:** Date the feedback was received.
* **User Segment:** Single-select (Freemium, Pro Plan, Enterprise Plan, Churned).
* **Pain Severity (User):** Rating 1-5 (1 = nice-to-have, 5 = blocking issue).
* **Business Impact (Internal):** Rating 1-5 (1 = edge case/low revenue impact, 5 = aligns with strategic goals/affects key metric).
* **Theme:** Linked record to a separate `Themes` table (e.g., "Reporting Export," "Dashboard Speed," "Mobile Usability").
* **Status:** Single-select (New, Under Review, Planned, Launched, Declined).
* **Link to Original:** URL to the source (e.g., Zendesk ticket, Slack message).
We use linked records extensively to maintain data integrity. The `Themes` table is a prime example, allowing us to tag multiple feedback items to a common product area without manual text matching. A `Feature Requests` table, linked from `Feedback Items`, aggregates related feedback into potential initiatives.
Our analysis and workflow are driven by views, automations, and a simple scoring formula:
1. **Views:** We operate primarily through saved filtered views.
* `Needs Triage`: Where `Status` is "New."
* `High Priority Candidates`: Items where `Pain Severity` >= 4 AND `Business Impact` >= 4.
* `By Theme [Last Quarter]`: A grouped view to see volume trends per theme.
* `Enterprise Requests`: Filtered by `User Segment` = "Enterprise Plan."
2. **Scoring:** We compute a simple priority score in a formula field to surface high-leverage items:
```
({Pain Severity (User)} * 0.6) + ({Business Impact (Internal)} * 0.4)
```
This weighted formula (favoring user pain slightly) helps depersonalize prioritization debates.
3. **Automation:** A simple but crucial automation watches our dedicated #feedback Slack channel. Using Airtable's "Webhook to Airtable" automation, messages posted there automatically create a new record with `Source` = "Slack," populating the `Feedback Text` and `Reported Date`.
**Use-Case Assumptions & Why Airtable Fits:**
* **Assumption 1:** The team is small-to-mid-size (< 50 engineers/PMs) and cannot justify a dedicated, expensive product feedback platform.
* **Assumption 2:** Feedback arrives from highly heterogeneous sources (our seven distinct channels), requiring flexible schema design.
* **Assumption 3:** The primary need is categorization and retrieval, not public-facing roadmaps or voter portals.
* **Assumption 4:** The team values deep, ad-hoc analysis (e.g., "show all high-severity feedback from churned Enterprise users in Q3 related to the API") over out-of-the-box analytics.
For our needs, Airtable strikes the optimal balance between structure and flexibility. It allows us to enforce consistent data entry—which is 90% of the battle—while providing the relational database power to ask complex, segmented questions of our user feedback data. It is not a replacement for a public roadmap tool, but as an internal system of record, it has proven invaluable.
— Amanda
Data > opinions