Feature requests are easy to collect and hard to judge.
One customer asks for something. Another asks for something else. Soon, your backlog is full of ideas, but you still don’t know what to build.
Here’s a simple, automated workflow to make prioritizing feedback easier.
This workflow gives every customer request a simple process:
The request then ends in one of these places:
This keeps you from building unnecessary things.
You only need a few tools for this workflow:
Keep the system simple. One form. One Airtable base. One Zap. One weekly review.
Start by creating a form in Jotform.
Go to Jotform:
Add these fields (or something similar):
The customer can now send a request with enough detail.
Next, create the place where the requests will be saved.
Go to Airtable:
This table has three kinds of fields.
First, add the fields that come from the customer form:
Next, add the fields that AI will fill:
Last, add the fields that you will fill yourself:
Use simple field types:
For Category, add these choices: Reporting, Integrations, Automation, Permissions, Billing, Import, Export, AI, Admin, Other
For Revenue signal, add these choices: Low, Medium, High, Expansion, Churn risk, Unclear
For Decision, add these choices: Backlog, Ask follow-up, Customer interview, Founder follow-up, Sales follow-up, Small build
Every request now has one place to live.
Go to Zapier.
Click: Create → Zap
Set the trigger:
Click: Test trigger
If Zapier does not find a request, submit a test request in Jotform.
Next, add AI to the Zap.
Paste this prompt (or something similar):
You are helping a small SaaS founder review a feature request.
Use only the information provided. Don’t make anything up._
Return:
* AI summary: One short sentence that explains the request.
* Category: The closest request category.
* Request group: A short lowercase label with hyphens. Example: scheduled-pdf-reports
* Revenue signal: The possible revenue impact.
* Decision: The best next step.
* Decision reason: A short sentence explaining the decision.
Rules:
* Expansion = may lead to an upgrade, more seats, a higher plan, or a paid add-on.
* Churn risk = customer may cancel or cannot keep using the product without it.
* High = clear pain, urgent pain, paid workaround, or high-value account._
* Medium = real problem, but money impact is unclear.
* _Low = nice-to-have.
* Unclear = not enough information.
Request details:
* Feature: [map Jotform feature request]
* Problem: [map Jotform problem]
* Urgency: [map Jotform urgency]
* Workaround: [map Jotform workaround]
* Workaround details: [map Jotform workaround details]_
* Customer plan: leave blank for now
* Account value: leave blank for now_
Click: Test step
Add another Zapier step.
Choose: Airtable → Create Record
Select:
Map the fields from Jotform. Then, map the fields from the AI step ( Leave Customer plan, Account value, Customer ID, and Revenue score blank for now. You will fill them in during your weekly review.)
Click: Test step
Then open Airtable and check the new row. Each new request should now be saved with the customer details and the AI cleanup.
Now, create a few Airtable views.
Instead of one giant list, create one view for each action. These views should help you answer one question: “What should I do next?”
Create these four:
View 1: Founder Review
This is for requests that may matter to revenue or churn.
Create a new view called: Founder Review
Filters:
View 2: Backlog
This is for requests you are not acting on yet.
View 3: Customer Interviews
This is for requests where you need to talk to the customer.
View 4: Small Build Candidates
This is for requests that may be worth building soon.
These views make the review faster and easier.
In Airtable, open the Requests table:
Airtable will now group similar requests. Review these groups weekly. Look for:
AI may not group everything perfectly. For example, these may all mean the same thing:
If they are the same request, give them one shared name during your weekly review.
Do this part by hand at first. Score at least the first 20 to 30 requests yourself.
Open the request in Airtable. Review:
Use this scoring (or something similar):
Once you have the final score, use it to choose the next action. Here’s an example:
Update these Airtable fields:
You now have a simple way to compare requests.
Use the Decision field to choose the reply.
Users now get the right response based on the value of the request.
In Zapier, add a filter or path.
Send this message (or something similar):
Feature request needs review:
* Customer: [Customer email]
* Plan: [Customer plan]
* Account value: [Account value]
* Request: [Feature request]
* Problem: [Problem]
* AI summary: [AI summary]
* Revenue signal: [Revenue signal]
* Decision: [Decision]
Next step: Reply personally before adding this to the roadmap.
Now, important requests do not get buried.
Before you build a big feature, email the users who asked for it.
Send this (or something similar):
Hi [First Name],
Thanks again for sharing more about this.
We are considering a small version of this feature.
Before we build it, I want to understand how important it is to you.
If we solved this well, would it help you do one of these?
* Upgrade to a higher plan
* Add more users
* Replace another tool
* Pay for it as an add-on
* Stay with us instead of switching
No pressure either way.
I’m asking so we make the right product decision.
Thanks,
[Your Name]
This way, you learn whether the request is connected to revenue.
If the signal is strong, build an MVP of the feature first.
Good points! Backlog management and scoring are two very important challenges.
Most founders drown in feedback because they try to listen to everyone at once. Your workflow solves this by forcing a decision on every input. If you don't have a system to sort requests, you end up building things nobody actually needs. Keep the process fast so you spend your time building, not managing lists.
I think the transparency is the real innovation here. Once scope changes are documented objectively, the conversation shifts from "I feel like this is extra work" to "Here's exactly what changed." That removes a lot of unnecessary friction for both sides.
The revenue signal field is smart. The other thing that's easy to lose is the user's exact wording. The phrase they use to describe the pain often tells you more than the feature request itself, because you can hear whether it's annoyance, a workaround or real churn risk. I built DictaFlow, and some of our best decisions came from reading the raw "I keep fighting this in Gmail, Citrix, or notes" language before we ever turned it into a neat backlog card.
The "revenue signal" step is the most important part. I built a small AI pipeline that checks for real money signals in feature requests (like "I'm paying $X for a workaround"). It prevented me from building 2 features that "felt" important but had no actual paying users waiting for them.
How do you handle the gap between "sounds urgent" and "actually generates revenue" in your scoring?
Step-11 is game changer
Steps 1 through 10 are optional. Step 11 is the whole game. We once killed a feature three loud users begged for, then not one of them would pre-pay when asked. Willingness to pull out a card tells you more than any AI tag or score ever will.
Thank you! This is very helpful. I can definitely use this as a reference for designing broader workflow systems.
This is basically the n8n equivalent of what I'd build with Zapier here —
solid workflow. One thing I've run into building similar pipelines (I do a
lot of n8n + GPT-4o automation, including a tool that turns SOWs into
project plans): the AI categorization step is usually reliable for clean
requests, but breaks down on vague or multi-intent submissions ("can it
also do X" buried inside a request about Y). Ended up adding a "confidence"
field to the AI output so anything ambiguous gets flagged for manual review
instead of silently mis-tagged. Might be worth adding a similar guardrail
here before the scoring step, since a bad Category/Revenue signal call
quietly skews your weekly review.
wow
The revenue signal taxonomy is what I've been missing. I've been
treating all feedback equally — a "nice to have" from a free user
gets the same attention as a "we might cancel" from a paying customer.
That's a prioritization failure, not a product one.
The Step 11 waitlist tweak is underrated. I'm currently validating
a job board for bootstrapped startups and doing exactly this —
Instead of building the full product, I launched a landing page
with a "Post a Job" form and an email signup. The form submissions
are my revenue signal. No submissions = wrong audience or wrong
messaging. A handful = worth building.
One thing I'd add to the scoring framework: weight recency. A
request from 6 months ago from a churned user, and the same request
from a new paying user this week, the signals aren't equal, even if the
words are identical. Timestamp + current plan status together tell
a cleaner story than either alone.
A clean workflow — this is exactly the kind of system that keeps feature requests from turning into chaos.
A simple way to think about it is that the goal isn’t to collect more feedback, it’s to separate signal from noise.
When every request gets tagged, summarized, and routed, you stop guessing and start seeing patterns.
Have you noticed how often the real product priority only becomes obvious after similar requests start clustering?
One thing I've started realizing while building is that feature requests rarely tell you what to build—they tell you where people are struggling.
For example, I originally thought I was building "portfolio tracking." But after talking to traders, I realized the real problem wasn't tracking prices—it was making better decisions after opening the app.
That completely changed my roadmap. Now I spend much more time asking "what decision is the user trying to make?" than "what feature do they want?"
Curious if you've ever had a customer request lead you to a completely different product direction than expected.
The "before you build" discipline is the hardest thing to actually hold to my whole team's instinct is to open the design tool the second an idea sounds good. One thing that's helped us more than any workflow: we force the research to end in a decision ("build / don't / not yet"), not a document. A doc lets you keep deferring; a decision forces the call. Curious where your workflow lands does it output a checklist, or an actual go/no-go?
the sleeper field here is "what are you doing today instead?" — a paid or manual workaround is the strongest build signal there is. customers describe solutions ("add this button"), but the workaround reveals the actual job. worth grouping by problem, not by requested feature — ten scattered requests often collapse into one missing capability.
Really solid workflow. This is the kind of system I wish I had set up from day one instead of drowning in scattered requests.
The most underrated field in this whole system is “What are you doing today instead?” Urgency is self-reported and inflated. Everyone says their request is important. But workarounds are behavioral evidence. Someone who says “I spend 45 minutes every Monday copying data by hand” has already proven the pain with their time. Someone paying for another tool has proven it with money. I’d almost weight the workaround answer higher than the urgency dropdown when scoring. Stated urgency lies. Revealed behavior doesn’t.
I build an open source wiki tool (~500 GitHub stars). The most useful signal I got wasn't any single request — it was stepping back and noticing that the newest issues were all about file compatibility with Obsidian vaults and AI agent workflows. Nobody filed a ticket saying "make this more like an agent-readable knowledge base." But together, the requests told me something I hadn't expected about who was actually using the tool.
The harder problem I'm still working through: I'm planning a hosted offering, and I know the waitlist validation only works if the right people land on the page. My current audience is mostly self-hosters. The person who'd actually pay for convenience hasn't found the tool yet.
Still figuring that part out.
Step 11 hits hard. I'm building FamiStream, a parental control app for IPTV. and I've been guilty of building features based on assumptions rather than testing willingness to pay first.
The waitlist approach you mentioned in the comments is exactly what I'm doing now, but I never thought to use it for individual features too. Going to start asking waitlist signups which feature matters most to them before I build anything else.
The revenue signal taxonomy is the part I'm taking away from this. Right now I treat all feedback equally. This changes that.
The revenue signal taxonomy is the part that actually changes behavior. Most founders collect requests but have no framework for separating 'nice to have' from 'losing a customer if we don't ship this' — and those require completely different responses.
The scoring weights feel right. Paying for a manual workaround (+2) might even deserve more weight — if someone is paying a third-party tool or a VA to compensate for your missing feature, that's almost always a high-intent signal and worth a direct founder call, not just a backlog entry.
Step 11 (test money before building) is where a lot of teams skip and regret it later. One tweak: combine it with a waitlist for the feature. 'We're considering building this — if you'd pay for it, drop your email here.' Filters the politely enthusiastic from the genuinely blocked, fast.
Great system overall — stealing the Airtable view structure.
slowing the urge to build build build is the advice i needed when i launched my first startup!
Ideation and building is a serious addiction which can only be cured by a strict dose of marketing reality.