Feedback: what to do with what customers tell you

FeedbackSomething a customer says or does that gives you information about their experience, expectations, result, or decision. is tough; you can collect it from five different people, and finish with five different products in your head. One person asks for SMS reminders, another needs a QuickBooks integration, somebody thinks the price should be lower, and two tell you it looks great before never using it again; this is how your roadmap ends up being chosen by whoever emailed last.

That's why you should consider and ingest feedback productively, so each comment gives you information without making the product decision for you. Feedback is different from validation (which asks whether the problem was keenly felt and people would act or pay). Feedback starts once somebody has tried, bought, rejected, or stopped using something concrete; it helps explain what happened, and what you should do next..

Start around the comment

A customer's words are usually a short part of a longer story. Before sorting, counting, or considering them, collect five details:

1. Who said it, and whether they're part of the customer group you've chosen;
2. What they were trying to accomplish;
3. What they expected to happen;
4. What happened;
5. What they did next.

The same sentence can mean very different things once those details are added: “I need SMS reminders” may describe people ignoring email, someone working away from their computer, or one person preferring texts. These routes don't lead to the same product.

Customers may propose an addition (a feature requestA customer's suggestion for something the product should add or change. The request describes their proposed answer; the situation around it shows what they were trying to accomplish.), ask for help through a support ticketA recorded request for help with a product or service, usually sent through email, chat, or a support system., or stop paying (churnWhen a customer stops paying for or using a product during a chosen period.). These labels organize the record; the table shows what context each still needs.

Words/actions answer different questions

A conversation explains what a customer wanted, remembered, or found confusing. A product record shows that they started, completed, returned, paid, canceled, or left at a particular step; those actions are behavioral dataA record of what somebody did, such as starting a trial, completing a task, returning, paying, canceling, or leaving at a particular step..

Used together, they cover different gaps. An interview can't prove what somebody will buy next month, and an event log can't explain why they left; continued payment may mean the product works brilliantly or that exporting their data sounds awful. (Nielsen Norman Group, reviewed July 2026)

Who you ask depends on what you need to know

The person who paid and stayed can explain continuing value; somebody who left can describe what changed, while a suitable prospect who refused may be able to tell you which concern or alternative won.

The question determines who can answer it; payment, use, cancellation, and refusal keep their comments attached to something that happened.

Ask about the last time

People give more detail when they're describing one recent event than when they're asked how they usually behave or what they might do in future. When you're seeking feedback, it's a good idea to begin your conversations with “Tell me about the last time you tried to…” and follow the story through:

• What were you trying to get done?
• What did you expect to happen?
• What happened?
• What did you try next?
• What did the problem cost you in time, money, effort, or confidence?

This is a story-based interviewA customer conversation centered on one specific event from the person's past, so the goal, actions, context, and result can be understood together.. The critical incident techniqueA research method that asks somebody to describe a particular event that had a clear positive or negative effect on a result. narrows the question to one event that clearly helped or harmed a result. (Product Talk, April 2022; Nielsen Norman Group, January 2020)

Compare the user's account, if you can, with usage, payment, support, or what you observe.

The story behind a feature request

Imagine that a paying dog groomer asks the appointment-deposit product to add SMS reminders. “Build SMS” still leaves most of the decision unanswered.

You need the recent booking that prompted it. Did the client miss an email, did the groomer forget to send it, or did the message arrive without changing the result? Does texting by hand work?

If several suitable groomers describe clients missing email reminders, a manual SMS trial can test the behavior before the full system is built. An existing message hidden in the settings points back to the current product. Similar requests can come from different needs, while different requests can come from the same need. (Product Talk, June 2022)

Repetition is a sensible reason to investigate; one report is enough when it concerns security, safety, data loss, privacy, accessibility, or a legal risk.

Keep the good bits

Positive feedback can tell you which result, product behavior, support, or reassurance a customer values. “That was easy” gives you little to protect; “I sent the link while the client was on the phone, and they paid before we hung up” names the event and result.

The same recent-event questions work here. Repeat use, payment, and referral show whether the experience changed their behavior; the detail shows what a redesign, price change, or automation shouldn't remove.

People want to be kind

Customers are also speaking to the person who built the product. Some will soften criticism, say what seems acceptable, or agree with the answer contained in your question. Researchers call these social desirability biasThe tendency to give an answer that seems acceptable or makes the respondent look better, especially when another person is asking the question directly., acquiescence biasThe tendency to agree with a statement or the person asking, regardless of what the respondent would have said in a more neutral question., and the effect of a leading questionA question whose wording suggests the answer the person asking it expects or prefers..

Question wording, answer choices, order, and whether an interviewer is present can all change the response. A blank field lets the person answer in their own words (an open-ended questionA question somebody answers in their own words, instead of choosing from a fixed list.); a fixed list can make answering easier while limiting them to choices you supplied. (Pew Research Center, accessed September 2026). An anonymous surveyA set of questions given to several people so their answers can be collected and compared. can remove a layer of the politeness a user might otherwise apply to their answers.

A request that matches something you already wanted to build is easier to notice and remember, which is confirmation biasThe tendency to notice, seek, or favor information that supports what you already believe or want to do.. Keeping exact words, customer action, and conflicting evidence together can catch it before you work on something for six weeks.

Different products leave different gaps

The way you sell dictates the experiences that become visible. This table shows which records need to stay separate before you claim a pattern from the feedback you receive.

One decision from the pile

A possible pattern deserves more attention when it passes four checks:

1. It came from the customer group you've chosen;
2. It affected a real attempt or result;
3. It appeared more than once, or one event caused serious harm;
4. Responding supports the product you're trying to build.

These aren't four scores to add together. A repeated preference from free users outside your chosen group may stay parked; a single data-loss report goes straight to investigation.

Complete the feedback record with each person's words, behavior, and missing context together. Group records by a shared result and situation, then choose one question, observation, test, or change.

You're finished when one possible pattern has been investigated, one decision has been recorded, and you've chosen the customer action and review date that will tell you what happened next.

Prompt: turn my feedback into one decision

Copy this prompt into the model you use. Add customer comments, interview notes, support requests, survey answers, reviews, cancellations, usage, payment, and retentionThe proportion of customers or users who continue paying for or using a product over a chosen period. records; remove personal information you don't need before uploading anything.

I need to understand a set of customer feedback and choose one next decision.

Purpose
Keep each customer's words, situation, and behavior together; find possible
patterns without inventing a majority or treating a feature request as a build
instruction.

My context
- Product or service: [what I'm offering now]
- Product stage: [prototype / pilot / pre-launch / live]
- Customer group I'm concentrating on: [who]
- Result the product is meant to help them get: [result]
- Product direction and limits: [what I am and am not trying to build]
- Time and money available for the next test: [limits]
- Privacy or permission limits: [what can't be shared or quoted]

Feedback records
Paste each item separately with as much of this information as exists:
- Record ID and date
- Source: interview, support, survey, review, sales, product behavior,
  cancellation, or other
- Customer group and whether the person is part of my chosen group
- Paying, free, trial, pilot, prospect, canceled, or unknown
- User, buyer, approver, more than one role, or unknown
- What they were trying to do
- What they expected
- What happened
- Their exact words
- What they did next
- Payment, usage, repeat use, retention, referral, cancellation, or support data
- What remains unknown

Your task
1. Read and structure each record separately before comparing records.
2. For every record, separate exact customer words, observed behavior, my
   interpretation, and missing context.
3. State what result the customer appears to have wanted. Mark it as unknown
   when the record doesn't support an answer.
4. Identify feature requests, complaints, praise, support questions,
   cancellations, and behavioral records only after explaining what happened
   around them.
5. Group records only when customers in a similar situation were trying to get
   a similar result. Similar words alone aren't enough.
6. Show differences and evidence that conflict with the largest or clearest
   pattern.
7. For each possible pattern, check whether it concerns my chosen customer,
   affected a real attempt or result, repeated or caused serious harm, and
   supports the product direction I've supplied.
8. Flag any security, safety, data-loss, privacy, accessibility, or legal issue
   for immediate human review, even when it appears once. Don't give legal or
   security advice.
9. Write one neutral follow-up question tied to a recent event for every record
   missing important context.
10. Recommend one next decision: investigate, test, change, keep, decline, or
    park. Include one customer action to watch and a review date or rule.

Rules
- Don't invent customers, quotes, behavior, motives, frequency, severity,
  payment, use, retention, referral, or willingness to buy.
- Don't turn two comments into “most customers” or a qualitative set into a
  market percentage.
- Don't merge records from different customer groups, roles, or situations
  without showing the difference.
- Don't assume a customer's proposed feature is the only answer to their
  problem.
- Don't assume continued payment means satisfaction, or cancellation means the
  product failed.
- Don't let compliments outweigh payment, use, repeat use, retention, or
  referral.
- Don't remove positive feedback; identify the product behavior or result it
  may tell me to protect.
- Don't infer why somebody acted from product data alone.
- Don't fabricate or clean up direct quotations.
- Don't expose personal information in the output.
- Use ordinary language and explain any commercial or research term before
  applying it.

Return exactly these headings
## Records checked
## Exact customer words
## Observed behavior
## Missing context
## Possible patterns
## Important differences
## Positive experiences to protect
## Serious issues for human review
## Follow-up questions
## One decision
## Customer action to watch
## Review rule

Read the model's answer beside the original records. AI can help you organize what you've collected, and it can also remove context or invent a quote that sounds completely plausible. Teresa Torres recommends structuring each interview before comparing several, because a theme without the customer and situation is difficult to use; her own 2025 test also found fabricated or incorrect direct quotations in the AI output. (Product Talk, October 2025)

The next chapter, Pricing, uses what customers paid, refused, compared, and kept paying for to decide what the product should cost.

Sources

• Rosala, Maria, and Kara Pernice. “User Interviews 101.” Nielsen Norman Group, 17 September 2023; last reviewed 15 July 2026. Accessed 14 September 2026.
• Nielsen, Jakob. “Interviewing Users.” Nielsen Norman Group, 25 July 2010. Accessed 14 September 2026.
• Rosala, Maria. “The Critical Incident Technique in UX.” Nielsen Norman Group, 26 January 2020. Accessed 14 September 2026.
• Torres, Teresa. “Ask Teresa: What Are the Best Customer Interview Questions?” Product Talk, 6 April 2022. Accessed 14 September 2026.
• Torres, Teresa. “Ask Teresa: What Should You Do With Insights That Don't Come from Customer Interviews?” Product Talk, 15 June 2022. Accessed 14 September 2026.
• Torres, Teresa. “Customer Interview Analysis: Where AI Helps and Hurts.” Product Talk, 8 October 2025. Accessed 14 September 2026.
• Pew Research Center. “Writing Survey Questions.” Accessed 14 September 2026.