Designing Effective Feedback Prompts
Positive feedback helps a team decide where refinement will matter most. Without it, a team may spread its time and resources across many features, each adding only a little value. With it, the team can focus on refining a smaller set of high-impact features.
Why Teams Hesitate to Ask for Praise
When a team first designs a feedback prompt, attention usually goes to problems. Complaints, bug reports, and frustrated comments feel urgent, so the prompt is often built to catch the moment something goes wrong. Positive feedback tends to be left out of that design.
The reasoning behind this omission is that a product should not invite users to say what they love, since an extra prompt seems like one more thing standing between the user and the product. The underlying belief is that any request for feedback has a cost, and that positive requests carry that cost without a matching benefit. This article examines why that belief is incomplete.
What do you think happens?
Should a product ask users what they love, or only ask about problems?
Reveal answer
Ask about what users love too
The source argues that positive feedback is valuable to a product team. Concern about clutter is a reason to manage how often requests appear, not a reason to drop positive feedback altogether.
What Enthusiastic Feedback Reveals
Positive feedback answers a question that complaints cannot answer well: which parts of the product do people actually value enough to talk about with enthusiasm? Complaints show where something is failing, but they say little about where the product's real strengths sit. Enthusiastic feedback points to the features users love.
The source describes this need from the perspective of a product manager for a popular AI-powered product, whose team wanted this signal. The value is not only that the feedback is pleasant to read. It tells the team which features deserve continued investment.
Positive feedback helps a team decide where refinement will matter most. Without it, a team may spread its time and resources across many features, each adding only a little value. With it, the team can focus on refining a smaller set of high-impact features.
Limiting Who Sees the Prompt
The source's answer to the clutter concern is not to abandon the request. It is to control frequency. Instead of showing a feedback request to everyone, a team can show it to a limited percentage of users at a time. For a product with a large user base, the source gives the example of showing the request to only 1 percent of users.
The logic is that the disruption cost scales with how many people see the prompt, while the value of the responses depends on how many responses come back. Limiting the percentage keeps the first cost low. A large enough user base then supplies enough responses to be useful. Most people never see the prompt, so their experience is not disrupted, yet the team still receives a set of responses to learn from.
Deciding Which Users Get Prompted
Limiting the share of users who see the request means each user meets a decision point. The diagram below traces what happens to one user. A user who is selected sees the feedback request, and a user who is not selected continues with the product as usual. Only the selected branch produces a response that can reach the team.
Worked Example: Sizing the Sample
Splitting a user base into prompted and not prompted
A product has 200,000 active users. The team decides to show the feedback request to 1 percent of users. How many users see the prompt, and how many are not interrupted?
- 1Identify the percentage
The team has chosen 1 percent, which is 1 divided by 100, or 0.01 as a fraction of the whole.
- 2Compute the prompted group
Multiply the user base by the share: 200,000 times 0.01 equals 2,000 users who see the request.
- 3Compute the uninterrupted group
Subtract the prompted group from the whole: 200,000 minus 2,000 equals 198,000 users who never see the request.
- 4Check the trade-off
2,000 responses may be enough for useful insight, while 198,000 people keep an undisturbed experience. The remaining question is whether those 2,000 people resemble the full base.
2,000 users see the prompt and 198,000 are not interrupted.
The Trade-Off Between Sample Size and Bias
Limiting the sample has a cost of its own. The source warns that the smaller the percentage of users asked, the greater the risk of feedback biases. A small group may not look like the full user base. If the people who receive the prompt differ in some important way from everyone else, the feedback they give may tilt the team's picture of the product in one direction.
Mistakes Teams Make With Feedback Prompts
Common mistake Dropping positive feedback entirely because of clutter concerns
What it looks likeA team never asks what users enjoy, so it only hears about bugs and frustrations.
Why it failsThe source treats clutter as a reason to manage how often requests appear, not as a reason to remove positive feedback.
Do this insteadKeep the positive request and control its frequency by limiting the share of users who see it.
Common mistake Showing the prompt to everyone by default
What it looks likeEvery user in a large base sees the request on every visit.
Why it failsThe disruption cost grows with the number of people who see the prompt, and the source describes limiting the share as the way to keep that cost low.
Do this insteadChoose a percentage small enough to avoid disruption while still large enough to produce useful responses.
Common mistake Assuming a tiny sample is automatically representative
What it looks likeA team asks only a handful of users and treats their answers as the verdict on the whole product.
Why it failsThe source warns that the smaller the percentage asked, the greater the risk of feedback biases.
Do this insteadCheck that the pool is large enough and that the people reached do not differ in important ways from the full user base.
Common mistake Treating the frequency decision as the only design question
Practice Choosing a Percentage
A product has 50,000 active users. The team wants to show its feedback request to 1 percent of users. First, calculate how many users will see the prompt. Then explain one way the sample could be biased, and one design check that would reduce that risk.
Hints
- Multiply 50,000 by 0.01 to find the prompted group.
- Think about whether the users reached could differ from everyone else in some important way.
- The source's conclusion is to pick a percentage that avoids disruption and still yields feedback worth acting on.
Key Takeaways
- Positive feedback reveals which features users love, which helps a team focus effort on a smaller set of high-impact features.
- Concern about clutter is a reason to control how often requests appear, not a reason to drop positive feedback altogether.
- Showing the request to a limited percentage of users, such as 1 percent of a large base, can gather sufficient feedback without disrupting most users.
- The smaller the percentage asked, the greater the risk of feedback biases, so the goal is a percentage small enough to avoid disruption and large enough to produce feedback worth acting on.