How do you get feedback on an early product?
The best feedback you will ever get on your product comes from the first handful of people using it, but only if you engage with them directly and obsessively. Surveys, analytics dashboards, and focus groups are substitutes you resort to when you're too big to talk to users yourself—and most early-stage founders reach for those tools far too soon. The goal right now is to be physically or digitally present when someone uses your product, watching what they do and listening to what they say.
Go to your users, don't wait for them to come to you
Most early feedback is bad not because founders ask the wrong questions, but because they create too much distance between themselves and the user. An email survey sent to ten beta users will return four responses, three of which are polite non-answers. A thirty-minute call where you watch someone try to complete a task in your product will surface things you could not have predicted asking.
Paul Graham's argument in 'Do Things That Don't Scale' is that direct engagement with early users produces the highest-signal feedback you'll ever receive—and that founders only abandon it because they're worried about not being able to do it forever. That fear is backwards. The constraint you have right now (few users, no scale) is actually a structural advantage: you can give each person attention that no large company ever could. Use it.
Concretely, this means scheduling screen-share calls and asking users to narrate their thinking aloud while using your product. It means showing up in Slack, Discord, or wherever your early users congregate and asking specific questions about moments in the product, not open-ended questions about what they 'want.' Open-ended questions produce feature requests. Specific questions about friction produce insight.
Act like a consultant to a single user before generalizing
One of the most counterintuitive feedback strategies for B2B founders is to temporarily stop thinking about a category of user and instead go extremely deep with one. Graham calls this the 'consultant' mode: pick one user whose problem is urgent and real, treat them as if you are building the product exclusively for them, and iterate until their workflow is genuinely solved. The insight that falls out of that process—the edge cases, the vocabulary they use, the steps they do before and after touching your product—will shape your roadmap more accurately than any number of broader interviews.
This approach works because you're not trying to synthesize feedback from many sources with competing needs. You're trying to achieve one complete solution, which forces specificity. Once you've solved it for that one user completely, you'll notice which parts of the solution generalize and which were idiosyncratic. That distinction is enormously valuable and very hard to see from aggregate feedback alone.
For consumer products, the analog is to find the five or ten users who are most actively engaged and give them your personal contact information. Not a feedback form—your actual email or a direct line. The users who care enough to write to you directly will tell you things that never surface in structured feedback channels.
Constrain your market to make feedback coherent
Feedback from a broad, diffuse user base is hard to act on because different users want different things. One way to solve this is to deliberately narrow who you're collecting feedback from at first. Facebook's early decision to restrict access to Harvard students wasn't just a growth tactic—it meant that early feedback came from a coherent population with similar needs, social contexts, and expectations. When everyone using your product has roughly the same job, the same workflow, or the same community, patterns in their feedback are meaningful signals rather than noise.
This also makes it easier to prioritize. If you're getting feedback from ten different verticals simultaneously, every complaint has an asterisk: is this a universal problem, or a problem specific to this one use case? When your early user base is narrow, that question mostly goes away. You can act on what you hear without worrying that you're over-indexing on a niche.
Practically, this means choosing your first beta users deliberately rather than letting signups accumulate randomly. Recruit from one company, one profession, one city, or one community. Recruit people who share enough context that their feedback will point in roughly the same direction. You can expand the population once you've made something that works deeply for a small group.
Separate feedback collection from feedback interpretation
A common mistake is trying to interpret feedback in the same conversation where you're collecting it. A user says 'I wish the dashboard showed more data,' and the founder immediately starts asking clarifying questions about data types and visualizations. But that first statement might not mean what it appears to mean—it might mean the user feels lost, or doesn't trust the numbers they see, or is comparing your product unfavorably to a competitor they used before.
Better practice: collect feedback by watching and asking 'what were you trying to do here?' and 'what did you expect to happen?' before asking anything about solutions. Record the sessions if possible, with permission. Write down what the user actually did, not just what they said. Then do the interpretation work separately, away from the conversation, when you're not under social pressure to agree with whatever the user is suggesting.
The users who give you the most useful feedback are rarely the ones who articulate it most clearly. Sometimes the user who seems confused or inarticulate is showing you the most important thing: a genuine failure point in the product's mental model. Watching that confusion happen in real time, without rushing to fix it in the moment, often produces the clearest diagnosis.
“The feedback you get from engaging directly with your earliest users will be the best you ever get.”
— Paul Graham, source
The one thing to do
Book a screen-share call with one real user today, watch them use your product without helping, and write down every moment they hesitate or fail.
Frequently asked questions
How many users do you need to start collecting feedback?
One is enough to start. A single user who has a real, urgent version of the problem you're solving will teach you more than a hundred casual sign-ups. Depth beats breadth at this stage.
Should you ask users what features they want?
Generally no—at least not directly. Users are better at describing frustrations and failed attempts than at designing solutions. Ask what they were trying to do and what got in the way, not what they want you to build.
How do you avoid building only for a narrow set of users who aren't representative?
Choose your initial users deliberately from the segment you most want to serve, and go deep before going broad. Once you've solved the problem completely for that group, you'll be able to see clearly which parts of the solution travel to adjacent segments.
When should you stop doing unscalable feedback methods like one-on-one calls?
Much later than you think. Most founders switch to surveys and analytics when they have dozens of users; the right inflection point is closer to thousands. Unscalable feedback methods force specificity that quantitative data can't replicate.
Sources
- Do Things that Don't Scale — Paul Graham
- gstack: README.md — Garry Tan
- Life is Short — Paul Graham