The most dangerous phase of a software project is the time before the first real user touches the product.

At that moment, the team has the most confidence and the least information.

Ideas feel correct. Feature lists grow quickly. Edge cases start to matter. Without real users in the system, every decision is based on internal assumptions.

And assumptions compound quickly.

In early-stage products, the biggest risk is rarely technical difficulty.
The biggest risk is spending too long building the wrong thing.

Because of that, the most important line in a project definition is not the roadmap, the architecture, or the feature list.

It’s the definition of the absolute minimum version of the product that provides real value to someone.

Not a prototype.

Not a demo.

Something a real user would actually use.

That definition determines how quickly a team can start learning.

The easiest mistake is continuing to build

One of the most common patterns in early product development is the urge to “just add one more thing” before launch.

One more feature that completes the workflow.
One more edge case that should be handled.
One more improvement that would make the product feel more polished.

Individually, these decisions feel responsible.

Collectively, they extend the most dangerous phase of the project — the period where the team is building without feedback.

The longer that phase lasts, the higher the risk that the team is building the wrong thing.

Feedback changes the roadmap faster than planning

Once real users start interacting with a system, priorities change quickly.

Features that seemed essential often turn out to be unnecessary. Small workflow details suddenly matter more than major functionality. Entire parts of the product may collapse into something simpler than originally designed.

This happens in nearly every product.

But it only happens once the product is in someone's hands.

Speed to feedback is far more valuable than feature completeness.

Defining the minimum is the hard part

Defining a minimum viable product (MVP) is rarely a technical challenge.

It’s a prioritization challenge.

Teams have to decide what they are willing not to build yet.

That is uncomfortable. It means shipping something that feels incomplete. It means trusting that the product will evolve through usage instead of design discussions.

But the alternative is worse: spending months building a sophisticated product that nobody actually needed.

The purpose of an MVP is not to impress anyone.

It is to start the learning loop.

Build for a few real users first

Colin Stewart recently wrote about the 3/10/30 rule in his Founder’s Edition newsletter: make three users incredibly happy, then ten, then thirty.

That idea applies just as much to development as it does to growth.

If three real users are getting real value from the product, they will tell you what matters. Their feedback becomes the roadmap.

Trying to design for thousands of users before solving the problem for a handful almost always introduces unnecessary complexity.

Solve the problem deeply for a few people first.

Then expand.

Ship earlier than feels comfortable

Most teams launch later than they should.

The first version of a product doesn’t need to be impressive. It needs to be useful enough that someone will try it, struggle with it, and tell you what is wrong.

That moment — when a real user interacts with the product — is when the project actually begins.

Everything before that is preparation.

If a product team can define the smallest version that delivers real value and get it into users’ hands quickly, the odds of success increase dramatically.

If they spend months building before learning from users, the risk compounds with every feature added.

The difference between those two paths is usually decided at the very beginning of the project.

This is the question I care about most at the start of any build:

What is the smallest thing we can ship that someone will actually use?

Everything else can evolve once the learning loop begins.