Customer discovery investigates a person's problem and working context, while a feature request proposes a particular solution. Treat the request as evidence to investigate, then decide whether the underlying job fits your product and whether building is the best response.
Listening does not mean promising every requested capability. Ignoring requests because customers are not product designers is equally unhelpful. A customer may understand the problem far better than you while suggesting a solution that would be costly, redundant or unsuitable for other users.
Translate the request into a job
When someone asks for a dashboard, integration or export, ask what they were trying to accomplish when they noticed the gap. Ask them to reconstruct the most recent occurrence. What did they do instead, who else was affected and what was the consequence?
Nielsen Norman Group's interview guidance explains why self-reported accounts have limits. An authorised task walkthrough can help distinguish a demonstrated obstacle from an appealing description of a possible future workflow.
Preserve the original request in the notes. Do not quietly replace it with your preferred interpretation. The translation should be visible so you can return to the customer and check whether you understood.
Use a request-to-evidence ledger
Create a row with these fields:
| Field | What to capture |
|---|---|
| Request | The capability the customer actually asked for |
| Trigger | The recent event that produced the request |
| Job | The result they were trying to achieve |
| Workaround | What they do without the feature |
| Consequence | What remains costly, risky or incomplete |
| Scope | Which customers share this job? |
| Smallest response | Documentation, setup help, service or product change |
| Evidence gap | What must be checked before committing? |
A repeated feature name is not necessarily a repeated problem. One customer may want an export for a monthly management report, another for a one-off migration and another because a colleague refuses to log in. Each calls it an export, but the useful product response may differ.
A hypothetical integration request
Imagine a founder selling a project checklist to small creative studios. This example is hypothetical. A customer asks for a direct integration with their task manager and says it is essential.
A walkthrough shows that they manually copy unresolved items into a weekly team review. The underlying job is preparing a reliable discussion list, not continuous two-way synchronisation.
The founder could test a clearly labelled weekly export before building a permanent integration. If it solves the job, the smaller response avoids unnecessary operating complexity. If the customer needs changes to flow back into the checklist, the experiment reveals that requirement rather than assuming it.
The customer may still reject the export. That is useful evidence. The founder should compare the cost and wider relevance of the integration with the value of serving this segment, instead of treating one emphatic request as a roadmap mandate.
Separate commercial urgency from evidence strength
A large prospective account can make a request feel more credible. It may simply be more commercially important. Record whether there is an actual purchase commitment, who controls it and what else must happen before a sale.
A promise that the customer will buy after a feature ships can conceal other blockers: data access, procurement, security review or internal politics. Investigate these before treating development as the last obstacle.
Peter Reinhardt's YC interview about Segment describes early product enthusiasm that did not translate into successful classroom use. It is a founder's account, not a universal rule, but it illustrates why expressed interest and real behaviour should remain separate in your decision record.
Choose a response that fits the problem
Some requests need a product change because the current experience repeatedly blocks the core job. Others need clearer documentation or a better setup process. A request outside your intended customer may deserve a referral or an honest no.
Use a short decision note: this is the job, this is the evidence, this is the selected response and this is what we will observe next. Share the relevant part with the customer. Avoid telling them a request is on the roadmap when no commitment exists.
For a shipped change, return to the original task. Did the customer use it, did it remove the obstacle and what new work did it create? Delivery is not the same as resolution.
When conviction should lead
The counterargument to constant discovery is that customers may struggle to imagine a new approach. A founder sometimes needs to make a thoughtful bet before users can describe the product.
That is reasonable when the bet is labelled as such and tested at a proportionate cost. It is less reasonable to call a founder's preference customer demand. Keep conviction and evidence in separate columns so both can inform the decision honestly.
Stop a feature investigation when the job does not fit the product, the cost exceeds the plausible benefit or the customer cannot demonstrate the claimed obstacle after a reasonable effort. Good discovery reduces uncertainty about what matters. It does not turn every conversation into more code.