Find the problem behind a feature request

Customers describe solutions, not problems

Customers know their pain better than anyone. They are less reliable about the fix. A request like "add a button to export to Excel" describes a solution the customer imagined. The real problem might be that month-end totals take an hour to copy by hand. A button is one way to remove that hour, and it may not be the best one.

Treat every feature request as the start of a conversation. The request tells you where to look, and the customer's description of their day tells you what to build.

Ask why until the job is clear

Ask why two or three times. Stop when you can name the task, the person and the moment when the problem happens. These questions work well in a reply:

1. What were you trying to finish when you needed this?
2. What do you do today instead?
3. What happens if this takes another month?

The third question separates real problems from nice-to-haves. If nothing bad happens without the feature, the request is probably a delight rather than a need. That is still useful information, but it is a different decision.

Use the jobs-to-be-done frame

Jobs-to-be-done is a way to describe the task behind a request. Write it as one sentence: "When I [situation], I want to [motivation], so I can [outcome]." Filling in the three parts keeps you from building for the solution the customer named.

For example: "When I close the month, I want to see totals by client, so I can send invoices on time." That job can be served by an export, a filter, a summary report or a reminder. Choosing among them is a design decision, and the job tells you what success looks like.

Compare requests with their problems

The table below pairs common requests with the problems they usually point to. The pairs are examples, not a lookup table, so check each one against what the customer actually wrote.

Request	Likely problem
Add a button to export to Excel	Finance copies rows by hand at month end
Let me filter by date range	Support cannot find last week's complaints quickly
Send me a message for every refund	The team misses refund requests over the weekend

Two different requests can share one problem. Two customers asking for different features may both be fighting the same slow search. Group by problem, not by request wording, or you will count one pain as several. When you build your own table, keep the same columns each time: the request as the customer phrased it, the problem in one sentence, and the number of distinct customers who described that problem. A table in that shape turns a pile of wording into a short list you can take into a planning meeting.

Write the problem in an internal note

After a conversation, write the problem in one sentence in the internal note of each feedback item. Start with the job, then list the solutions people asked for: "Job: close the month with totals by client. Solutions asked: export button, date filter."

This note becomes the grouping key. When you count requests for a problem, you count notes, not the wording of each message. That reduces noise and makes the trend easier to see across weeks.

Revisit the notes once a quarter. A problem that many notes described last quarter and none describe now may have been solved by a release, which is worth recording before you reopen the request.

Reply and confirm the problem

Confirm the problem before you commit to a solution. Reply from your own email, because Escuta Produto does not send messages to customers on your behalf. Restate the job in your reply and ask whether you understood it correctly. "It sounds like month-end totals take too long to build by hand. Is that right?" Replies like this often surface the real need, and customers feel heard.

Use the reply templates in how to reply to customer feedback so each reply stays short and specific. If your app calls identify for signed-in users, the item already holds the sender's email, and the follow-up takes a minute. The identify fields are listed in the widget docs.

Find the problem in your Escuta Produto inbox

1. Filter the product inbox to type idea and read the new items.
2. When the item includes an email address, follow up by email with the job question.
3. Write the job in the internal note, and keep the solutions requested in the same note.
4. Search the inbox for the nouns and verbs of the job, such as "month" or "invoice", to find other customers describing the same problem.
5. Once the problem has an owner and a score, move the item to planned.

For scoring what you find, see how to use RICE to prioritize customer feedback. When a problem has no good fix, read how to say no to a feature request before you reply.