How to launch a product: from idea to MVP / After launch
Getting your first users and feedback
Launch is the start of the only feedback that matters, which is what real users do. The first users are hard to get and worth the effort, because they tell you whether your riskiest assumption was correct. The skill is finding a small group who truly have the problem, watching how they behave, and reading it honestly.
Published July 27, 2026. Editorial.
Key takeaways
- Launch is the beginning of learning, not the end.
- Find a small group who genuinely have the problem, not the widest audience you can reach.
- Watch behavior, not opinions. Whether people come back is the honest evidence.
- Talk to the users who stay and the ones who leave; the leavers often teach you the most.
Releasing the MVP feels like the goal, and it is really the start. Now the product meets real users, and what they do decides what you build next. The founders who launch well treat the first weeks after launch as the most valuable learning of the whole project, because it is the first time real customers answer your riskiest assumption.
Find the right first users, not the most
The instinct is to get in front of as many people as possible. For a first version, that is wrong. You want a small group who genuinely have the problem you are solving, badly enough to care. Their behavior tells you the truth. A large audience with little interest tells you little and can even mislead you, because people with no real need stop using the product for reasons that have nothing to do with your product.
If you did the work in how to validate a product idea, you already know who these people are and often how to reach them. Go back to them first. Early users often come from personal outreach that would not work at large numbers, which is fine: a first version does not need scale, it needs evidence. Getting a handful of real users who deeply want the product is better than getting a large group with little interest.
Watch what they do, not what they say
The single most important habit after launch is to trust behavior more than opinion. People are polite. They will tell you the product is nice and then never open it again. That politeness is worse than useless if you mistake it for validation.
Behavior is honest. Do people come back after the first visit? Do they complete the core action? Where do they stop? Do they tell other people? The clearest evidence in any early product is whether users return on their own, because that is the hard thing to fake. Set up enough measurement to see the core action and whether people repeat it, then trust what the behavior says over what the interviews say. This is the same habit of trusting actions over words that runs through the main guide.
Talk to the stayers and the leavers
Numbers tell you what is happening. Conversations tell you why. Talk to your early users, both the ones who stayed and, especially, the ones who left. The leavers are uncomfortable to contact and often the most useful, because they show you the gap between what you built and what people needed. Ask what they were trying to do, where it did not meet their needs, and what they did instead. Those answers show you what to build next.
Keep asking about their behavior rather than offering them fixes. "Tell me about the last time you used it" teaches you more than "would you use it if we added X." You are still testing assumptions, now with real usage behind the answers.
Turn feedback into the next build, carefully
Feedback is input, not instructions. If you build every request, you will produce a large, confusing product, because different users want different things and none of them see the whole. Your job is to find the pattern under the requests: the shared problem that many of them are describing in different words. Build for that pattern, not for the loudest single user. This is the same prioritization discipline as how to prioritize features, now based on real usage instead of guesses.
Watch for the one request that keeps coming back from users who genuinely have the problem. That repetition, from the right people, is the strongest evidence you can get about what to build next.
Know what you are looking for
All of this is aimed at one judgment: was your riskiest assumption correct, and is there real demand. If a clear group of the right users keep coming back and actively ask for more of the product, you have evidence worth acting on. If nobody returns no matter what you add, the honest conclusion is that the assumption was wrong, and it is far cheaper to learn that now than after a big build. When the evidence is clear and real, when to scale past the MVP helps you decide whether it is time to invest. Take what you learn back to the main guide and let the users set the direction.
Common questions
How do I get my first users for an MVP?
Go to the small group who genuinely have the problem you solve, often the same people you spoke to while validating the idea. Early users usually come from personal outreach that would not work at large numbers, and that is fine. A first version needs evidence, not scale, so a handful of the right users is better than a crowd with little interest.
What feedback should I trust after launching an MVP?
Trust behavior over opinions. People are polite, so what they say is weak evidence. Whether they come back, complete the core action, and tell others is honest. Set up enough measurement to see the core action and repeat usage, then trust that more than what interviews say.
Should I build everything my early users ask for?
No. Feedback is input, not instructions. Building every request produces a large, confusing product. Find the shared problem many users describe in different words and build for that pattern, especially the request that keeps coming back from users who genuinely have the problem.
How many first users does an MVP need before the feedback means something?
There is no fixed count. What matters is a small group who genuinely have the problem the product solves, not the widest audience you can reach. A handful of users who deeply want the product and keep coming back gives clearer evidence than a large group who tried it once and mildly liked it.
How do I get feedback from users who stopped using my MVP after trying it?
Reach out directly and ask what they were trying to do, where the product did not meet their needs, and what they did instead, rather than offering them a fix. Users who left are uncomfortable to contact but often the most useful, because they show the gap between what was built and what people actually needed.
Is it a bad sign if my MVP has low usage right after launch?
Low overall usage right after launch is not automatically a bad sign, since the goal at this stage is evidence from the right users, not scale. What matters more is whether the small group who genuinely have the problem keep coming back on their own. If that group grows and returns, the product is going in the right direction even with a small total user count.
What tools should I use to measure user behavior after launching an MVP?
Set up enough measurement to see whether users complete the core action and whether they repeat it, since that is the clearest honest evidence available. The specific tool matters less than tracking the right thing: return visits and completion of the core action, trusted above opinions collected in interviews or surveys.
What is the difference between getting feedback and validating an idea?
Validation happens before a product exists, testing whether the idea is worth building through conversations, landing pages, or prototypes. Feedback after launch happens once real users interact with a working MVP, and it tests whether the built product actually delivers the value the idea promised. Feedback is validation continued with real usage instead of hypothetical questions.
How a build like this runs
Related reading
How to launch a product with minimal resources
A tight budget forces good decisions. It makes you focus on the value that actually matters and cut everything that does not.
Knowing what to build is now the most important decision
AI made writing software cheap. That moved the hard part earlier, to deciding what deserves to be built and having the discipline to cut the rest.