Collecting User Feedback and Deciding What to Build Next (2026)
How to collect useful feedback from your first users, sort it without drowning, and turn it into a clear decision about what to build next, with templates and a scoring example.
Key Takeaways
- Behaviour beats opinion. What users did last week is more reliable than what they say they’d do. Ask about specific past events, as The Mom Test recommends.
- Collect the problem, not the solution. When someone asks for a feature, ask what they were trying to do. The real need is often met by something simpler.
- Listen hardest to your most engaged users. Superhuman’s product-market fit process focused on users who would be “very disappointed” without the product, and set aside feedback from those who wouldn’t.
- Score, then decide. A simple framework like Intercom’s RICE (reach, impact, confidence, effort) turns a list of opinions into a ranked list you can defend.
- Close the loop. Tell people when you ship what they asked for. It is the cheapest way to get more and better feedback.
Quick-Start Prioritization Framework
| Source | What it tells you | How often | Effort |
|---|---|---|---|
| User conversations | Why people do what they do; problems they haven’t mentioned | 5 a week | High, most valuable |
| In-app feedback link | Bugs and frustrations in the moment | Always on | Low |
| Usage data | What people actually do and where they drop off | Weekly review | Low once set up |
| Short surveys | Patterns across many users, including the “very disappointed” test | Monthly or quarterly | Medium |
| Support messages | What breaks and what confuses | Daily | Low |
Once real people use your app, you will get more suggestions than you can build. A user wants dark mode. Another wants an export. A third wants something you’ve never heard of. If you build in the order requests arrive, the app turns into a pile of features nobody quite asked for. This guide shows how to collect feedback that reflects what people actually do, organise it so patterns show up, and choose the next thing to build with a simple, repeatable method.
Set up your feedback channels
You need a small number of channels you actually check, not every tool available. For a new app, four are enough.
A visible feedback link
Put a “Send feedback” link in the app’s menu or footer that goes straight to you, by email or a short form. Sign it with your name. People write more, and more honestly, to a person than to a support queue.
Regular conversations
Book short calls with users every week. Five 20-minute conversations a week will teach you more than any dashboard. Rotate between new users, heavy users and people who stopped using the app.
Basic usage numbers
Track a handful of events that matter: signed up, completed the main action, came back the next week. You don’t need a complex analytics setup. You need to know whether people do the thing the app is for, and where they stop.
One place to collect it all
Copy every piece of feedback into one spreadsheet or board with the date, the person, their exact words and a tag. Feedback scattered across email, chat and notes is feedback you will forget.
How to ask so you get the truth
Most feedback is unreliable because of how it’s asked for. Rob Fitzpatrick’s The Mom Test sets out three rules for customer conversations: talk about their life instead of your idea, ask about specifics in the past instead of generalities or opinions about the future, and talk less and listen more.
Questions that work
- “Walk me through the last time you used the app. What were you trying to do?”
- “What did you do right before opening it, and right after?”
- “Was there a moment you got stuck or weren’t sure what to do?”
- “What did you use before this app for the same job? Do you still use it?”
- “If the app disappeared tomorrow, what would you do instead?”
Questions to avoid
- “Do you like it?” (People are polite.)
- “Would you use feature X?” (Everyone says yes to free features.)
- “How much would you pay for this?” (Hypothetical prices are unreliable; real payments aren’t.)
- “Don’t you think it would be better if…?” (A leading question gets the answer you planted.)
Turning a feature request into a problem
When someone says “Add a calendar view”, ask “What were you trying to do when you wanted that?” The answer might be “See which days I’m free next week”, which a simple “upcoming” list might solve in an afternoon. Write down both the request and the underlying problem; prioritise the problem.
Organise feedback so patterns show up
A single request tells you about one person. Patterns tell you about your product. The point of organising is to see the patterns.
Tag every item
Use a short, fixed set of tags: bug, confusion (they didn’t understand something), missing (they needed something that isn’t there), friction (it works but is slow or annoying), and praise. Add a tag for which part of the app it concerns.
Count people, not mentions
One vocal user can mention the same thing ten times. Count how many different people raised each problem. Seven people stuck on the same step outweighs one person asking for seven features.
Weight by who’s asking
Note whether each person is a heavy user, a light user or someone who left. Requests from people who use the app every week matter differently from requests from people who tried it once. Both are useful; they answer different questions.
The “very disappointed” test
Once you have a few dozen active users, a short survey can tell you how close you are to something people need, and whose feedback to prioritise.
The question
First Round Review’s account of how Superhuman found product-market fit describes Sean Ellis’s question: “How would you feel if you could no longer use the product?” with the answers very disappointed, somewhat disappointed and not disappointed. Ellis benchmarked nearly 100 startups and found that companies below about 40% “very disappointed” tended to struggle to grow.
The follow-up questions
Superhuman added three questions: what type of people would most benefit, what is the main benefit you receive, and how can we improve the product for you. The answers from very disappointed users describe your best customer and the benefit to protect.
How to use the answers
Superhuman ignored feedback from users who would not be disappointed, and acted on improvement requests from somewhat disappointed users who valued the same main benefit as the very disappointed group. The lesson for a small app: build what turns near-fans into fans, not what might win over people who don’t care.
Decide what to build next
With patterns in hand, you need a way to compare unlike things: a bug fix, a new feature, a smoother onboarding step. A scoring framework keeps the decision honest.
RICE in plain words
Intercom’s RICE framework scores each idea on four factors. Reach: how many people it affects in a set period. Impact: how much it helps each of them, scored 3 (massive), 2 (high), 1 (medium), 0.5 (low) or 0.25 (minimal). Confidence: how sure you are of your estimates, 100%, 80% or 50%. Effort: how much work it takes, in person-months in the original; for a small app, days work fine. The score is reach times impact times confidence, divided by effort.
A worked example
Illustrative numbers for a club-membership app with 60 active users, scoring reach as users affected per month and effort in days. These are our own example figures, not benchmarks.
| Idea | Reach | Impact | Confidence | Effort (days) | Score |
|---|---|---|---|---|---|
| Fix confusing payment-status screen (7 people stuck) | 60 | 1 | 100% | 1 | 60 |
| Reminder email before each session | 60 | 2 | 80% | 2 | 48 |
| Export members to a spreadsheet | 10 | 1 | 80% | 1 | 8 |
| Calendar view | 15 | 0.5 | 50% | 4 | 0.9 |
| Dark mode | 20 | 0.25 | 50% | 2 | 1.25 |
Reading the result
The confusing screen wins because it hits everyone and is cheap. The calendar view, which felt important because one enthusiastic user kept asking, ranks last. Scores are a guide, not a verdict: if the export would unblock a club willing to pay, that context can move it up. The point is that you’re making that call deliberately.
Saying no and closing the loop
Most requests won’t get built. How you handle that matters for keeping users engaged.
A kind no
“Thanks, this is really useful. We’re not building a calendar view right now because we’re focused on making reminders reliable, but I’ve logged it with your note about seeing free days. If more people need it, it’ll move up.” Honest, specific, and it keeps the door open.
Tell people when you ship
When you build something someone asked for, message them personally: “You asked for reminders before sessions. They’re live today. Let me know if the timing works.” People who see their feedback acted on give more of it.
A simple changelog
Keep a short list of what changed each week, in the app or on a page. It shows momentum to users and gives you a record of what you learned.
A weekly feedback rhythm
A routine keeps feedback from piling up or getting ignored. An example week for a solo founder:
| Day | Task | Time |
|---|---|---|
| Monday | Review last week’s usage numbers and new feedback; tag and count | 1 hour |
| Monday | Score the top five problems; pick one main item for the week | 30 minutes |
| Tuesday–Thursday | Build and test; hold five user conversations across the week | Most of the week |
| Friday | Ship, update the changelog, message people whose feedback it addressed | 1 hour |
Common mistakes
These are the habits that lead to a cluttered product and confused users.
- Building requests in the order they arrive, or for whoever shouts loudest.
- Treating “I’d use that” as evidence instead of looking at what people did.
- Collecting feedback in five places and reviewing none of them.
- Counting mentions instead of distinct people.
- Listening equally to people who use the app weekly and people who tried it once.
- Building the exact solution a user described instead of solving their underlying problem.
- Never telling users what happened to their feedback.
If you’d rather not build the changes yourself
If you’d rather not code each change by hand, Floot, the AI app builder that publishes this site, lets you describe a change in plain English, see it in a live preview and publish it, and includes visitor analytics for published apps so you can see what people actually use.
Frequently Asked Questions
How do I get feedback from users of my app?
Combine a visible feedback link, regular short conversations with users, basic usage numbers and occasional short surveys. Collect everything in one place with the person, date and their exact words.
What questions should I ask users for feedback?
Ask about specific past behaviour: the last time they used the app, what they were trying to do, where they got stuck, and what they’d do if it disappeared. Avoid asking whether they like it or would use a hypothetical feature.
How do I decide which features to build first?
Turn requests into underlying problems, count how many distinct people have each one, and score them with a framework like RICE (reach, impact, confidence, effort). Fix problems that block many people before adding new features.
What is the 40% rule for product-market fit?
Sean Ellis asks users how they’d feel if they could no longer use the product. In his benchmark of nearly 100 startups, those with under about 40% answering “very disappointed” tended to struggle to grow. It is a guide, not a law, and needs a reasonable number of active users to be meaningful.
Should I build every feature users ask for?
No. Most requests are solutions to problems that can be solved more simply, or matter to only one person. Build what solves common problems for your most engaged users, and say no kindly to the rest.
How many user conversations are enough?
There’s no fixed number, but a steady habit beats occasional bursts. Many founders aim for a few conversations every week, across new, heavy and lapsed users.
Sources
- Rob Fitzpatrick, The Mom Test (book site) https://www.momtestbook.com/
- First Round Review, How Superhuman Built an Engine to Find Product/Market Fit https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit/
- Intercom, RICE: Simple prioritization for product managers https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/