How to Get Useful Feedback on an MVP: Questions, Sessions and Sorting

Why does “do you like it?” teach you so little?

People are polite, and a polite person who has just been shown your work says something kind. The answer feels like data and is mostly manners. What you want instead is evidence about what someone did, said they would do and merely felt, and the three are not worth the same.

Treat the second and third rows as leads for a follow-up question, not as instructions. A feature request is usually a need in disguise: asking “what were you trying to do when you wished for that?” turns it into something you can build for.

Who should you ask, and how many?

Ask people who have the problem the MVP addresses, and be wary of a crowd of other makers unless your users are makers. A handful at a time is enough to see the first obvious breakages. Fix them, then show the next handful, because the same five people cannot see the product fresh twice.

To find them, use the places where the problem is already discussed, a short list of names you can write messages to, and a public launch page for the people who find you. How to get first users for free explains where to look by product type, and the MVP scope planner helps if you are unsure which single task to test.

How do you run a 15-minute session?

Keep it short enough that people agree to it. Use a call with screen sharing, or sit beside the person; if you record, ask first. The script below fits a quarter of an hour.

1. Say: “I am testing the product, not you. Nothing you do is wrong.”
2. Give one task in the user’s own words, for example “Get a reminder sent to a client who is late paying you.” Never use feature names.
3. Ask them to think aloud. Then stay silent. If they ask what to do, ask what they would try.
4. Note every pause, backtrack and sigh with the screen they were on.
5. Afterwards ask: “What did you expect to happen when you clicked that?” and “What did you do before this product?”
6. Finish with: “Who else deals with this, and could I show them?”

The hardest part is the silence in step 3. If you explain the screen, you will never learn that it needed explaining. Write down what happened in the order it happened, and leave the interpretation for later.

Where does feedback come from when nobody will take a call?

• The thread under your launch. Comments are free and public. Ask one specific question in the first comment, for example “Which step felt slowest?”, so replies have a direction. This board has threaded comments, and how to respond to launch comments covers answering them.
• A Show HN post for something people can try. Hacker News’s moderator tips say to state clearly what the project is or does, because otherwise “the discussion will consist of ‘I can’t tell what this is’”, and to make it easy to try without sign-up. Its rules also forbid asking friends to vote or comment.
• A question in a community, not an advert. Post what you are unsure about and say what you built to find out. Read the community’s rules first.
• One in-product question. After the core task, ask “Was anything harder than it should have been?” and let people skip it.

Feedback on a launch page is useful for the page and the pitch. It is weaker evidence about the product itself, because most readers never used it. Where you can, launch your MVP for free and then ask the people who open it to try the task.

How do you tell a real problem from a passing opinion?

1. Count independent repeats. One person’s complaint is a story. The same stopping point reached by several people who never talked to each other is a finding. Three is a reasonable working bar; pick your own and write it down.
2. Prefer what they did over what they said. If a tester says the product is clear and then fails the task, believe the failure.
3. Tie it to the core task. A problem that blocks the one task outranks any request about the edges.
4. Weigh the fix. A small fix for a repeated stop beats a large build for a single request.

Keep a sheet with four columns: the problem, how many people hit it, where it sits in the core task and how big the fix is. When the top row changes from week to week, you are learning. When the same row stays on top, ship the fix before collecting more. The guides on what an MVP is and how to scope an MVP help you decide what to leave out.

What should you do after someone helps you?

Tell them what changed. A short message, “you were right that the bank step lost people; it is now optional”, costs a minute and turns a tester into a returning user. It also proves to you that you act on what you hear. Keep a list of the people who gave feedback, and use the feedback request template when you need to ask again. If you are not sure yet what to test, the app ideas board shows how other builders phrase the problem they want solved. For places built around this, see where to launch for feedback.