How to Set Realistic User Targets for Your MVP

What you need to know

• An MVP user target is a hypothesis test, not a growth target. The question is whether the assumed customer exists and whether the product delivers the assumed value to them.
• Ten engaged users who complete the core workflow are more informative than a thousand passive signups. Set targets that reflect the behavior you need to validate, not the numbers that sound impressive.
• Missing a user target is not failure. It is data about what needs to change in acquisition, activation, or the product itself before you scale.
• Separating acquisition metrics from activation metrics is the most important distinction in MVP-stage measurement. Acquisition tells you whether people are curious. Activation tells you whether the product works.
• The timeline for an MVP user target matters as much as the number. A hundred users in six months and a hundred users in six weeks are very different hypotheses about your go-to-market.

The core argument

The user target problem in early-stage products is that founders set them for the wrong reason. The number is set to satisfy investors, to motivate the team, or to create a sense of momentum. It is almost never set as a hypothesis about what constitutes evidence that the product is working. The result is a number that creates pressure without providing direction. When the team hits the number through tactics that do not resemble the actual go-to-market, the celebration happens before the insight does. When the team misses the number through no strategic fault, the narrative becomes "we failed" rather than "we learned."

The alternative is to set targets as explicit hypothesis tests. The target for the first thirty days is not "one hundred users." It is "fifteen users who complete the core workflow in the first session, which would confirm that the onboarding is clear enough and the value is legible without a demo call." That target has a specific behavior attached to it. Hitting it tells you something specific. Missing it tells you something specific. The number is the threshold, not the goal.

I use this framing when planning launch sequences for client products. When I built the initial version of Expert Tutorials, the first-month target was not a user count. It was a completion rate: how many users who started the core workflow finished it without dropping off? The completion rate told us whether the core flow was working before we spent any money trying to grow it. The user count was a constraint on the test, not the test itself.

Common mistakes

1. Setting user targets as aspirational growth projections. A target derived from a growth model is not a hypothesis test. It is a forecast. MVPs do not benefit from forecasts. They benefit from validated assumptions.

1. Counting registrations as users. A user who registers and never returns has not validated anything about your product. Count active users, defined as users who complete at least one core workflow action.

1. Not defining what counts as a user before launch. If you do not define "user" before the launch, the definition will expand to include registrations, trials, and abandoned sessions when the real count is below target. Define it in advance.

1. Setting the same user target for different channels. A user from a direct outreach campaign has different context than a user from organic search. Their behavior will be different. Track them separately and compare.

1. Treating the user target as the final success metric. The user target is the early evidence test. Retention and revenue are the success metrics. Make sure the team knows the difference.

Where to start

1. Write the hypothesis your user target is testing. Finish this sentence: "If X users complete Y action within Z days, that confirms our assumption that [specific assumption]." Now your target has a reason.

1. Define the user action that represents activation. Not registration, not login, but the specific action that means a user has gotten value from the product. Build the tracking for that action before launch.

1. Set a lower bound and an upper bound. The lower bound is the minimum that would represent a positive signal. The upper bound is the number that would represent strong early evidence. The range is more useful than a single number for planning the next step.

Related reading

• Validate Your App Idea Before Spending Fifty Thousand on Development
• How to Test an MVP with Real Users Before You Have Real Users
• Pre-Build Customer Discovery: 10 Questions That Save Months of Work
• The MVP Postmortem: Questions to Ask Yourself Six Months In