Shipping an MVP Is Easy. Building a Business Around It Isn't.

Building software is getting easier. With modern frameworks, hosted infrastructure, and AI-assisted coding tools, a small team can put a working product in front of users faster than ever. That is a real change, and I think it is mostly a good one.

But it creates a quiet trap. When shipping becomes easier, it starts to feel like the main event. The product is live, people can sign up, the dashboard loads. It looks like progress. Often it is only the beginning of the harder work: finding out whether anyone needs what you built, and whether a business can grow around it.

Shipping feels like progress because it is visible

Features are easy to count. A release is easy to announce. A roadmap with ten completed items looks healthier than one with three. None of this is wrong, but it measures activity rather than outcome.

The questions that decide whether a product becomes a business are less visible. Do the right people sign up? Do they reach the moment where the product helps them? Do they come back next week without being reminded? Would they be annoyed if it disappeared? Would they pay for it, and keep paying?

A team can ship steadily for months and still not know the answer to any of these. That is why I think it is worth separating two ideas that often get merged: having a working product, and solving a valuable problem.

A working product is not the same as a valuable one

A working product means the code runs and the flows complete. A valuable product means someone's situation is meaningfully better because they used it, often enough and clearly enough that they would choose it again.

The gap between the two is where most early products live. The software can be technically sound while the problem it addresses is minor, infrequent, or already handled well enough by a spreadsheet, an email thread, or an existing tool. In that case, more engineering effort does not close the gap. Understanding does.

An MVP is an instrument, not a finished business

I find it useful to think of an MVP as a measuring instrument. Its job is to put a real offer in front of real people so the team can observe what happens. That framing changes what "done" means. An MVP is done when it can answer a question you care about, not when it has every feature a mature product would have.

It also changes what you pay attention to after launch. If the MVP is an instrument, the most important output is not the next feature. It is the evidence the instrument produces: who signed up, what they tried, where they stopped, what they came back for, and what they said when you asked.

The work that starts after deployment

Once a product is live, the work shifts into areas that are less about building and more about learning and connecting:

• Customer discovery continues, now with a real product to react to.

• Onboarding and activation determine whether new users reach the value you intended. (I explore this further in UX That Drives Product Growth: The Power of Time to Value.)

• Product intelligence means understanding usage, not just collecting it.

• Iteration is the team's response to what it observes.

• Acquisition and retention decide whether the right users arrive and whether they stay.

• Commercial validation tests whether the value is worth paying for.

None of these is a phase you finish and leave behind. They run in parallel and influence each other. More sign-ups do not help if new users never reach the core workflow, and better retention means little if the product can never be priced sustainably.

A hypothetical example: the project tool nobody returns to

Imagine a founder who launches a project-management tool for small agencies. It works well technically. Tasks, boards, comments, and notifications all function. Early sign-ups are encouraging. But after the first week, most accounts go quiet.

The instinctive response is to build: add time tracking, a calendar view, client portals, an integration with the team's chat tool. Each of these might be reasonable. But adding them now assumes the problem is missing capability, and that assumption has not been tested.

A more useful first step would be to investigate:

• The original problem. What were these agencies struggling with before they signed up? Was it task tracking, or was it something closer to client communication or capacity planning?

• The onboarding experience. Did new users set up a real project, or did they look around an empty board and leave?

• Adoption barriers. Did one person sign up but fail to bring the rest of the team? A collaboration tool used by one person is not really being used.

• Ongoing value. For the few teams that stayed, what were they doing differently?

The answers might still lead to new features. But they would be features chosen because of evidence, not because building is the most comfortable thing to do next.

Understanding what you are learning from early users

Early users produce a lot of signal, and not all of it points in the same direction. A few enthusiastic users can make a product feel more validated than it is. A few loud requests can make one feature feel more urgent than it is.

The founder's job is to keep asking what each piece of evidence actually says. A compliment is not the same as repeated use (a distinction I explore in Customer Compliments Aren't Product Validation). A feature request describes a proposed solution, not necessarily the underlying need. A sign-up shows interest, not value.

Prioritizing without a giant roadmap

After launch, it is tempting to respond to uncertainty with a long roadmap. I think small teams are usually better served by a short list of open questions instead:

1. What is the single most important thing we do not yet know?

2. What evidence would change our next decision?

3. What is the smallest piece of work that would produce that evidence?

This keeps the team focused on learning, and it makes it easier to say no to work that would not change anything.

Measuring progress through evidence

If features shipped is an incomplete measure, what should replace it? I would look for meaningful customer behavior: users completing the core workflow, returning without prompting, inviting colleagues, building the product into their routine, and eventually paying. The specific signals depend on the product, but the principle is the same. Progress is a change in what customers do, not only a change in what the product contains.

Beyond the build

This is the idea behind what I call Beyond the Build: the systems a founder needs after the MVP is live. Shipping is a necessary milestone. It is not proof that a market exists or that the business is ready to scale.

A deployed MVP creates the opportunity to learn. The teams that make the most of it treat launch as the start of a learning process, not the end of a build process.

A question worth asking this week: if you could only learn one thing from your current users, what would it be, and what are you doing to find out?