The short answer
Trace each request to the task a user is trying to complete, check what happens in the current product, then choose a build, service fix or deferral that you can test. One service founder reports that fewer than 60% of clients who tried the service said it went well after he analyzed conversations from 505 clients.1 One software founder reports that 3 customers moved to an agency plan in a week; one accepted his suggestion to consolidate separate accounts.2
What founders did
6 real examples, each linked to the moment in the source. Results are self-reported.
- X
Roy Banwell
Fewer than 60% of clients who tried the service said it went well. The spending cut was a decision, not a reported result.
Analyzed client conversations and decided to shift attention from acquisition to service quality.
- RedditCustomer accepted account merge
Strong_Teaching8548
The customer accepted, gained capacity for three more sites without extra charge, and sent a positive email; the founder said revenue barely changed.
Suggested merging a customer's separate site accounts into an agency account.
- X
Mat De Sousa
Said some agencies used WideBundle more for its data and A/B tests than for its bundles. He did not report performing the free-versus-paying usage analysis.
Asked agencies what they used and disliked about bundle tools; recommends checking adoption and distinguishing free from paying users when interpreting usage.
- YouTube
Diya Jolly
Found that users wanted the total rather than the statement itself.
Dug into repeated requests to display a bank statement during reconciliation.
- X
GREG ISENBERG
Described collecting cancellation reasons and inspecting funnel drop-offs with agents while leaving judgment and feedback to people.
- YouTube
Matchy Life
The creator decided to restock a bag on pre-order after repeated restock alerts.
Your playbook
Use this when
Use this playbook when you have an existing product or service, feedback from its users, and a decision about what to improve next.
You’ll leave with
Create a feedback-to-roadmap worksheet with each problem, its supporting observations, a chosen response and a test result.
Find the task behind the request
- Do
Enter current requests and complaints in the worksheet. Record who raised each one, what they were trying to do, where they got stuck and what they asked for. Follow up when the task is unclear.
- Make
Add a task and obstacle beside each request.
- Check
If you can describe the obstacle without naming the requested feature, investigate its extent; otherwise ask the user to show the task.
Why this step is in the plan
Diya Jolly said users repeatedly asked to see a bank statement during reconciliation. Digging deeper showed they wanted its total instead.4 Roy Banwell started with a broader problem: after analyzing conversations from 505 clients, he reported that fewer than 60% of clients who tried his service said it went well.1
Check behavior and the affected users
- Do
For each obstacle, inspect the relevant setup path, support history or feature usage. Note which users encounter it and whether it blocks an existing task or calls for a new capability.
- Make
Add the affected users, observed behavior and missing evidence to each worksheet entry.
- Check
If behavior supports the reported obstacle, consider a response; if it conflicts, observe affected users doing the task before building.
Why this step is in the plan
Mat De Sousa said agency conversations revealed that some used WideBundle more for its data than its bundles. He recommends tracking onboarding, retention and adoption, and separating free from paying users when interpreting usage. His free-versus-paying example is proposed analysis, not a result he reported measuring.3
Choose a response rather than defaulting to a feature
- Do
Compare a product change with setup help, an existing option or a delivery fix for each supported problem. Choose the response tied most directly to the task; defer requests whose problem remains unclear.
- Make
Add a build, fix-without-building or defer decision and its reason.
- Check
If the response cannot be tied to the observed obstacle, revise it before committing roadmap capacity.
Why this step is in the plan
Strong_Teaching8548 suggested an account merge for a customer using separate site accounts; the customer accepted, and the founder said revenue barely changed.2 Roy Banwell instead decided to cut ad and sales spending by over 50% and focus his team on hiring, scheduling and service quality after reviewing client conversations. These cases called for different non-feature responses.1
Test the response with affected users
- Do
Put the chosen response in front of affected users. Record whether they complete the original task and what still gets in their way. For a product change, inspect adoption among the users it was meant to help.
- Make
Add an observed result and a keep, revise or stop decision.
- Check
Keep the response if affected users can complete the task; revise or stop if the obstacle persists or the change goes unused.
Why this step is in the plan
The creator of Matchy Life chose a bag restock on pre-order after repeated restock alerts, but had not yet seen how many orders it would receive.6 For software changes, Mat De Sousa recommends checking whether users actually adopt a feature after release. An inventory decision and a software change need different observations after the decision.3
Turn feedback into a build decision
- What you find
A request names a feature, but not the problem
Response to considerInvestigate the user's task
What to checkContinue when you can describe where the current workflow fails without naming the requested feature.
- What you find
The user cannot reach value already offered
Response to considerTry setup help or a usability fix
What to checkWatch the user retry the task; build a new capability only if the obstacle remains.
- What you find
An obstacle affects users you intend to serve
Response to considerConsider a focused product change
What to checkCheck whether affected users adopt the change and complete the task.
- What you find
Feedback points to delivery trouble or lacks context
Response to considerFix delivery or defer the request
What to checkRevisit the choice when the service improves or you can observe the underlying task.
Build
Choose a product change when you can tie it to an observed obstacle for users you intend to serve.
Fix without building
Choose setup help, an existing option or a delivery change when it resolves the user's task.
Defer
Keep the request and its context when the underlying problem or affected users remain unclear.
Make it yoursFeedback-to-roadmap worksheet
A fill-in template for your own test
Copy into one worksheet entry for each candidate: User and context: [who encountered it] Request: [their proposed solution] Task and obstacle: [what they tried and where it failed] Observed behavior: [usage, setup or service evidence] Response: [build, fix without building or defer] Check: [what the affected user can now do] Decision after test: [keep, revise or stop]
When this works
- Use this process when you can connect feedback to identifiable users and observe their existing workflow.
When to avoid
- Do not use it as a substitute for validating an unbuilt idea or judging demand for an entire product.
- Avoid treating the loudest request as the roadmap when you cannot identify its task or affected users.
Related questions
Can AI help sort customer feedback into roadmap candidates?
Use it to surface candidate patterns, then inspect the underlying conversations before deciding what to change. GREG ISENBERG describes using agents to collect cancellation reasons and inspect funnel drop-offs, while assigning creative feedback and judgment to people.5
Should I build a feature requested by only one customer?
Aakash Gupta describes a Salesforce practice of tagging field feedback as a paper cut or feature request, matching it against the roadmap, and asking whether customer-specific work should serve everyone.7 Keep an isolated request with its context until you can decide whether its underlying problem extends beyond that customer.
What if customers ask for features but struggle with setup?
Emma Guetta recommends setting up the product with a customer using real data and noting where they get stuck as a candidate product fix.8 Try helping them reach the existing result before adding the requested capability to the roadmap.