How to Identify User Needs Behind Feature Requests
A user need describes the progress someone is trying to make in a real situation. To identify it, ask about a recent attempt, observe the workflow when possible, and connect the desired outcome to the obstacle and workaround. A requested feature is one possible solution; it is not the whole need.
UserTold helps you investigate that moment with an in-product AI interviewer. Start with users you can already reach and a question you need evidence to answer.
Start with a recent event
Choose one uncertainty: why a setup step fails, why a feature is ignored, or why a user keeps working in a spreadsheet. Ask the participant to reconstruct the last time it happened. A concrete episode gives you people, constraints, actions, and consequences to investigate.
Use neutral questions:
- What were you trying to accomplish the last time this came up?
- What started that task?
- Can you show me what you did?
- What did you expect to happen at that point?
- What did you do next, and what did that cost you?
- How did you decide you were finished?
Avoid asking whether the participant likes your proposed solution before understanding the situation. “Would you use an export button?” invites an opinion about your idea; “What happened to the information after you found it?” investigates the work.
Separate the request, need, and proposed solution
The following is an illustrative example, not a customer result.
| Part | Example | What to verify |
|---|---|---|
| Request | “Add CSV export.” | The participant's original words and context. |
| Situation | A team lead prepares an engineering planning meeting. | When the task happens and who needs the result. |
| Observed workaround | The lead copies selected research into a spreadsheet and rebuilds source links. | The recording of that workflow, if captured. |
| Desired outcome | Share relevant evidence with engineers who do not use the research workspace. | Ask the participant to explain what a useful handoff contains. |
| Need | Prepare a traceable handoff without rebuilding the evidence manually. | Check the synthesis against the source and other relevant interviews. |
| Possible solutions | Export, a shareable view, or an existing tracker integration. | Test which option fits; the interview does not choose the implementation. |
Do not infer the desired outcome from clicks alone. Backtracking can tell you where to ask a question; it cannot establish what the user expected.
Run the investigation in UserTold
- Create a Study with one goal, such as “Understand how team leads share research with engineers.”
- Invite reachable users who recently performed that task. Explain the purpose and recording before they participate.
- Start with a conversation about the recent event. Add an observation segment if the participant can show the workflow inside the product.
- Follow with a planned debrief. Enable realtime analysis for the debrief when you want its questions to use the running evidence summary of the preceding activity.
- Open the completed Interview and inspect the recording and Evidence. Preserve the participant's words separately from observed behavior and your interpretation.
Use the Quickstart for installation and the study design guide for configuration. The switching guide goes deeper when the important context is the decision to adopt or leave a tool.
Write a need you can investigate
Use this working sentence:
When [situation], [user] needs to [make progress], but [obstacle] gets in the way. Today they [workaround].
Keep the recording or transcript references beside the sentence. Mark any missing element as unknown. A convincing sentence does not become evidence merely because AI wrote it.
How many interviews are enough?
There is no universal count that validates a need. Review whether you have concrete episodes from the intended users, understand important differences, and have looked for counter-examples. A small qualitative sample can explain a problem; it cannot tell you what percentage of all users have it.
If the next decision depends on prevalence or conversion impact, combine this research with appropriate product analytics or a separate quantitative study. UserTold does not recruit a representative sample for you.
Turn the need into a reviewed Finding
Next, analyze the interviews to compare source moments and test your interpretation. Then prioritize supported problems using product strategy, impact, and effort. Keep the need open to several solutions until the evidence and product context justify one.