GGuide

Get feedback on your MVP before launch day.

An MVP is built to learn something, and it can only teach you if people use it. Launch day is a bad time to find out the sign-up email lands in spam. Here is how to get real feedback on an MVP in the weeks before, and what to do with it.

What to test first

  1. 1Can people get in? Sign-up, email verification, install. Everything else depends on it.
  2. 2Do they understand what it's for without you explaining?
  3. 3Can they reach the one thing your MVP exists to do?
  4. 4Do they want to come back? Ask what would make them use it next week.

What to ignore, for now

  • Requests for features that belong in version three.
  • Visual polish, unless it stops people from understanding the product.
  • Edge cases that only one tester hit and that you can't reproduce.
  • Anything about scale: your MVP doesn't need to handle a million users.

Finding people before you have users

Before launch, you have no users to ask. On Makers Wall, other makers try your MVP and send a written report of what broke and what confused them. You test theirs in return, which is also a good way to see how other people scope their MVPs.

Tell testers it's an MVP in the brief, and list what you already know is missing. They'll spend their time on what matters instead of reporting the obvious.

How it works on the wall

  1. 1 · SubmitPaste your link and write what testers should look at.
  2. 2 · TestClaim someone else's project and write down what broke. That's what moves yours up.
  3. 3 · ReceiveMakers test yours and send a report, every problem listed with its severity.
  4. 4 · RateYou rate each other; both ratings unlock together.

Free, and based on reciprocity. The FAQ has every rule written out.

Questions

How do I get feedback on my MVP?
Put it in front of people who have never seen it, with one clear task, and ask them to note where they got stuck. On Makers Wall, other makers test your MVP and send a written report; you test theirs in return.
When should I get feedback on an MVP?
As soon as someone other than you can sign up and reach the core feature. Earlier than feels comfortable, and well before launch day.
What feedback should I ignore on an MVP?
Feature requests far from your core use case, visual nitpicks that don't block understanding, and one-off issues you can't reproduce. Focus on getting in, understanding the product and reaching its core action.

Get on the wall first.

The doors open in a few days. Submit your project now and it’s in the first batch makers test.

Pre-submit your project