At a glance
Key takeaways
- Under 100 users, conversations beat surveys: you can reach almost everyone, and one call tells you more than fifty form responses.
- Ask about past behavior (what they did, what they used before) instead of opinions about features that do not exist yet.
- Make reporting a problem a one-click action inside the product, reply within a day, and tell people when their issue ships.
Why feedback from your first users is different
With ten or fifty users, every individual matters. One confused user is 10% of your customer base. One churned account can be most of your revenue. That changes how you should collect feedback.
Three things are true at this stage:
- You can talk to almost everyone. A survey makes sense when you cannot reach people one by one. Under 100 users, you can.
- Early users are polite. They chose to try something new, they like you for building it, and they will soften bad news unless you make it safe to say.
- Silence is the most common signal. Most users who are not getting value will not tell you. They just stop logging in.
So the playbook is mostly conversations, plus one always-on channel for problems, plus watching what people actually do.
Start with 15-minute calls, not surveys
A short call with one user tells you more than fifty form responses, because you can ask "why?" and "can you show me?". Aim for three calls a week while you have fewer than 100 users.
Ask right after a meaningful moment, such as finishing setup or using the core feature for the first time. Send this from your own address:
Subject: 15 minutes on how you're using {product}?
Hi {first name},
I'm the founder of {product}. I saw you {did the thing} this week. Thanks for trying it.
Could I take 15 minutes this week to hear how it's going? No pitch, I just want to learn what's working and what isn't. Here's my calendar: {link}
{your name}
If they do not want a call, the same email with one question in place of the calendar link still gets useful replies. The feedback question generator has ready-made sets for beta users, onboarding, and churn.
The call script: ask about the past, not the future
People are bad at predicting what they will do and good at describing what they did. Build every question around a real, recent event. This is the core idea of Rob Fitzpatrick's book The Mom Test, and it is the most useful habit for early conversations.
| Ask this | Not this | Why |
|---|---|---|
| "Walk me through the last time you did {task}." | "Would you use a feature that does X?" | Real stories reveal the actual workflow; hypotheticals get polite yeses. |
| "What did you use before this?" | "Do you like the product?" | Shows what you really compete with, often a spreadsheet. |
| "What was the most frustrating part this week?" | "Any feedback for us?" | A specific prompt gets a specific answer. |
| "What almost stopped you from signing up?" | "Why did you sign up?" | Objections are rarer and more useful than reasons. |
| "If {product} disappeared tomorrow, what would you do?" | "How much would you pay?" | Reveals the real substitute and the real value. |
Two rules during the call: let silences run, and do not defend the product. If a user says something is confusing, the only right response is "tell me more."
Write notes within an hour, using the user's exact words for problems. Those quotes will later become your landing page copy.
Give users a one-click way to report problems
Calls cover the people you reach. Everyone else needs a way to tell you something the moment it happens, without finding your email address.
The simplest version is a link to your personal email in the app's menu. The better version is a feedback button inside the product that asks what kind of feedback it is (bug, idea, or praise), captures the page and browser automatically, and lands in one inbox. Users report more when the button is right there and the form takes ten seconds. See how to add a feedback button to your website for the setup on any stack.
Whatever you use, follow two rules:
- Reply to every message within a day. At this stage, a fast personal reply is your competitive advantage over every larger company.
- Tell people when you fix their issue. "You reported this on Tuesday, it's fixed now" turns a user into a fan, and they report the next problem too.
Keep this channel private at first. A public voting board with three posts and no votes looks like an abandoned product, and early users rarely post publicly anyway. Publish a roadmap later, once you have requests worth showing. The customer feedback portal guide covers when to make that switch.
Watch what users do, not only what they say
Feedback explains behavior; it does not replace it. Track three numbers per user, even in a spreadsheet:
- Did they reach the first useful outcome? For a feedback tool, that is the first real submission. For your product, define the moment someone gets value.
- Did they come back in week two? Returning without a reminder is the strongest early signal you have.
- Did they invite anyone or pay? Both cost the user something, so both are honest.
Then cross-check. A user who says "it's great" but never returned is telling you something the words do not. Email the ones who went quiet and ask one question: "What got in the way?" Their answers are often the most valuable feedback you will get.
A weekly routine for the first 100 users
You do not need a product team for this. About three hours a week covers it:
- Monday (30 minutes): read everything that came in last week: calls, emails, feedback button submissions. Tag each by the problem, not by the feature the user asked for.
- Tuesday to Thursday (90 minutes): three 15-minute calls, plus one email to a user who went quiet.
- Thursday (30 minutes): pick the one problem that came up most often and decide what to do about it. If you are choosing between several bigger requests, score them quickly with the RICE calculator.
- Friday (30 minutes): ship something small and tell the users who asked for it, by name.
Keep one running document of problems with a count of how many different users mentioned each. That count, not the loudest request, decides what you build.
Signals that you are onto something, or not
Around 30 to 40 active users, ask the product-market fit question: "How would you feel if you could no longer use {product}?" with the options very disappointed, somewhat disappointed, and not disappointed. If 40% or more say very disappointed, you are close. If it is under 20%, more features will not fix it; go back to who your users are and what problem you solve for them.
Other good signs: users describe the product to you in the same words without prompting, they report bugs instead of leaving, and some ask how to pay before you push.
Warning signs: feedback is all feature requests and no problems, every user wants something different, and nobody would mind if you shut down. When you see these, narrow the audience before you add anything.
Mistakes founders make with early feedback
- Asking friends and family. They will be kind. Kindness is not data.
- Building every request. Ten users asking for ten different things is a positioning problem, not a backlog.
- Waiting for statistically significant data. You will not have it for months. Three independent users with the same problem is enough to act.
- Leading questions. "Wouldn't it be great if…" always gets a yes.
- Collecting feedback with no time to read it. If you cannot reply within a few days, collect less.
Make the feedback button the easy part: Get TellTide Pro. One script tag puts a feedback button in your product, every report lands in a private inbox, and users get an email when their request moves.
Questions teams ask before choosing this workflow
How many users do I need before feedback is meaningful?
Patterns start to show after five to ten conversations with the same kind of user. You do not need statistical significance at this stage: when three users independently describe the same problem, treat it as real and investigate.
Should I launch with a public feedback board?
Usually not. A public board with three posts and no votes looks abandoned, and early users rarely post publicly. Collect feedback privately first, then publish a roadmap once you have requests worth showing.
How do I get early users to reply at all?
Write from your own name, keep the email to three sentences and one question, send it right after they do something meaningful in the product, and reply to every answer. Response rates fall quickly when emails look automated.
Should I offer incentives for feedback?
For calls with busy B2B users, a small gift card or an extended billing period is fair. For in-product feedback, skip incentives; they attract people who want the reward rather than people with a problem to report.
Abhijith
Founder of TellTide, writing practical guides about product feedback, feature requests, and public roadmap workflows for SaaS teams.
