How to write a feedback request people actually answer

Most feedback requests fail before anyone reads them. “Hey, would love your thoughts on my app!” asks the reader to do all the work: figure out what the app is, decide what matters, guess what kind of answer you want, and find time for an open-ended task. Busy people postpone that kind of task forever.

A good request does the opposite. It makes answering cheap, specific and safe. Here is a structure that works whether you're asking a peer, a potential user or someone senior.

1. One line on what it is

Name the project and say who it is for and what it does in a single sentence. “ShiftSwap lets clinic nurses trade shifts without a group chat.” If you can't write this sentence yet, that's useful information — fix it before asking anyone else.

2. A link they can open immediately

A prototype, a Figma file, a landing page, a two-minute screen recording. No sign-up walls, no “I'll send it if you're interested”. Every extra step loses people.

3. The kind of feedback you want

Say whether you want a reaction to usability, the technical approach, the pricing, or the messaging. This lets the right people self-select and stops a designer from reviewing your database schema.

4. One specific question

This is the part that matters most. Compare:

• Weak: “What do you think?”
• Better: “Is the onboarding clear?”
• Strong: “After the first screen, could you tell what you'd do next? If not, where did you get stuck?”

The strong version can be answered in two minutes, and the answer is something you can act on. If you have several questions, pick the one whose answer would change what you build next week. Save the others for later.

5. The time it takes and permission to be blunt

“About five minutes” tells people this fits between meetings. “Blunt answers are the most useful, and ‘not for me’ is a fine answer” lowers the social cost of honesty — which is the whole point.

After you get answers

1. Thank everyone, including people who said it wasn't for them.
2. Look for patterns, not individual opinions. One person disliking a colour is noise; three people stuck on the same step is signal.
3. Tell responders what you changed. People who see their feedback used are far more likely to help again.
4. Return the favour — answer someone else's request this week.

A template

Hi — I'm building [project], which helps [who] do [what]. Here's a [prototype/demo]: [link]. I'm looking for feedback on [usability/pricing/…]. My one question: [specific question]? It should take about [N] minutes. Blunt answers help most. Thank you!

The free Feedback Request Builder applies this structure and checks your draft for the most common mistakes before you send it.