What should you do when early users ask for different features?
Start by understanding the work behind each request. Two people asking for an export button may need different things: one wants to review a result outside the app, while another needs a structured file for a teammate. Building the same button for both may leave the important need unanswered. Ask what they were trying to finish and what prevented it.
Treat feedback as an input to your product decision. Linear’s account of its customer-request work emphasizes interpreting needs rather than merely counting feature votes. A solo builder can apply that idea in a small spreadsheet: preserve the source, describe the task, record the obstacle, and decide what evidence would support a change. A specialist feedback platform is optional.
Separate the observation, interpretation, and proposed fix
Write what the person actually reported or what you observed before adding an explanation. The participant tried to send a draft to a colleague and copied text into an email is an observation. The app needs team workspaces is one interpretation. A shareable preview, a downloadable file, or clearer copy controls might address the task at different levels of effort.
GOV.UK’s research-analysis guidance distinguishes observations from findings and actions. Keep that separation visible in your log. It becomes especially useful when an AI assistant summarizes support messages: compare the summary with the source so an inferred motivation does not become a customer quote. The interview guide helps investigate an unclear request without pitching your preferred fix.
Classify the problem before placing it on a roadmap
A reproducible defect needs a different response from a request for a new market. First check whether the promised workflow works as described. Then ask whether the person could discover the existing behavior, whether an expected capability is absent, or whether the product was never intended for this task. Classification helps you choose a next action without pretending every item needs engineering.
The following examples are invented for a small report-writing app. The actions illustrate a triage conversation; they are not a universal priority score. A serious failure affecting one person can deserve attention before a popular cosmetic request, while an unverified report may first need reproduction.
| Observation | Possible classification | Useful next action |
|---|---|---|
| An acknowledged save disappears after reopening | Potential loss of work | Reproduce with demo input, investigate persistence, and explain the status |
| A participant cannot find an existing download control | Discoverability or explanation | Observe the task and test a clearer label or location |
| A reviewer needs a spreadsheet format the app lacks | Missing capability for a relevant workflow | Inspect the handoff and evaluate a small export option |
| A visitor wants the app to generate payroll | A different product need | Explain the boundary and investigate separately if strategically relevant |
Which factors should determine the next priority?
Consider the consequence for the task, fit with the audience you serve, strength of the evidence, and effort required to learn or resolve it. Add dependencies and how reversible a change would be. Distinguish the cost of a small investigation from the cost of the full requested feature. Reproducing a defect or testing a label can be a better next commitment than promising a redesign.
If you use a numeric scoring framework, retain the assumptions behind the score. An impact of five is not measured evidence simply because it appears in a formula. With a few early users, a short written reason often makes uncertainty clearer: this blocks the core task for two observed testers, the cause is reproducible, and we can verify a bounded fix.
How do you avoid treating the loudest user as the whole market?
Group feedback by person or account as well as issue. Ten messages from one customer remain one customer’s repeated experience, not ten independent requests. That experience may be urgent, but the distinction matters when you assess how widely the need occurs. Record audience fit and available context alongside the count.
Look for missing voices. People who abandoned setup may never join your feature discussion, and satisfied users may rarely contact support. Ask relevant participants about the actual workflow rather than circulating only a list of your favorite proposed features. Use the beta-recruitment guide to fill a specific gap in who you have observed.
What should you tell someone when you are not building their request?
Acknowledge the task and give the current decision. An illustrative reply could read: I understand you need to send a draft for a teammate’s review. This version supports downloading a PDF, which may cover that handoff. Shared editing is not currently planned, so I cannot promise a release date. Would you be open to showing me where the PDF falls short? Use this only when the stated capability and invitation are accurate.
Keep investigation, planned work, and shipped work as separate statuses. If a date is uncertain, say so before the user builds a dependency around it. A clear boundary helps someone decide whether the product suits their work now. The trust guide explains how specific, verifiable facts support that decision.
How do you verify that a change solved the problem?
Return to the original task and input, then check the result on the changed version. A resolved ticket is a workflow status; successful completion provides evidence about the product. Where the participant agrees, invite them to try the corrected path. Record any remaining assistance or a new obstacle rather than marking the whole journey successful because one step improved.
Connect the change to your activation definition when it affects first use, or your retention observation when it affects repeated work. Avoid attributing every later increase in activity to the fix if recruitment, timing, or other parts of the app also changed.
Turn the decision into a small, maintainable record
For each important item, retain the source reference, observation, audience, consequence, current interpretation, next action, owner, and review trigger. Keep private customer material out of a public roadmap. Close or archive stale items with a reason so an old request does not silently reappear as a fresh commitment.
The downloadable decision log has blank fields for your evidence and a status column. Use a few well-supported items in your weekly founder routine. When the issue is a recurring explanation gap, the feedback-to-content guide can help you write the answer instead of repeatedly sending the same improvised reply.