Field notes / Product Strategy
An MVP is not the cheapest possible version of an idea. It is the smallest version that can test whether the important part actually works.
Igniter Studio · 2 Oct 2026 · 5 min read
“MVP” has become one of those terms that can mean almost anything.
Sometimes it means:
the first focused version of a product
Sometimes it means:
build the whole idea, but badly
Those are not the same thing.
A minimum viable product should reduce scope.
It should not reduce basic quality to the point where the test becomes meaningless.
Every product idea contains assumptions.
For example:
The MVP should help test the assumptions that matter most.
Imagine an idea for an AI tool that automatically reviews construction quotes.
The risky assumption may not be whether you can build user accounts.
It may be whether AI can extract and compare quote items accurately enough to create value.
That is the thing worth proving first.
Early product scopes often become bloated because every future requirement gets included immediately.
You start with:
Users upload a document and receive an analysis.
Then the scope grows:
None of those features are automatically wrong.
They may simply be premature.
If the core analysis is not valuable, sophisticated billing infrastructure will not rescue it.
Build the part that proves the reason the product should exist.
Users still need a coherent experience.
The first version should have:
You can leave out advanced functionality.
You should not leave users wondering whether the product worked.
There is a difference between:
limited
and
badly made.
A good MVP is intentionally limited.
Instead of starting with a feature list, define one successful path.
For example:
That might be enough.
The goal is for one journey to work properly from beginning to end.
Half-building eight workflows usually produces less learning.
Not everything behind an MVP needs to be automated.
This surprises people.
Suppose a new platform promises matched recommendations.
You might initially generate those recommendations manually behind the scenes.
The customer still experiences the core concept.
Meanwhile, you learn:
Once the workflow is understood, automation becomes easier to design.
This is sometimes called a concierge MVP.
It is not cheating.
It is avoiding expensive automation before understanding the process.
There is one important caveat.
Manual work should not hide the thing you actually need to prove.
If your product's value proposition is:
AI can classify these records automatically with high accuracy.
and a person secretly classifies everything manually, you have not tested the key assumption.
The prototype should simplify secondary parts.
Not fake the core innovation.
One of the easiest ways to keep scope under control is to explicitly document excluded ideas.
For example:
Not in MVP
This is useful because those ideas are not rejected.
They are parked.
When somebody suggests:
What if users could also...
you can decide whether that feature helps validate the core assumption.
If not, put it on the list.
An MVP needs a learning goal.
Otherwise every result becomes ambiguous.
Possible signals include:
These do not need to be perfect venture-capital metrics.
They simply need to tell you whether the idea is moving in the right direction.
If you want to learn from the MVP, make important behaviour observable.
You might track:
Qualitative feedback matters too.
Talk to users.
Ask what confused them.
Ask what they expected.
Ask what they would miss if the product disappeared tomorrow.
Analytics tell you what happened.
Conversations help explain why.
People often worry:
What if we suddenly get a million users?
That would be a very good problem for most MVPs.
The more immediate risk is:
What if we learn the workflow is wrong and need to change it next week?
Early architecture should support iteration.
Use good engineering practices.
Keep data safe.
Avoid obvious dead ends.
But do not design a distributed global platform for demand that does not exist.
Optimise first for learning.
The first version is not supposed to remain the product forever.
Once you have evidence, you can decide what comes next.
Maybe:
That final outcome is valid too.
Discovering cheaply that something should not be built is a successful MVP.
The best MVPs feel focused.
They solve one problem clearly.
They leave obvious future ideas out.
They provide enough quality that users can evaluate the real concept.
And they create evidence for the next decision.
That is the point.
Not to build the cheapest version possible.
To build the smallest version that teaches you something worth knowing.
Your next chapter starts here
Tell me what you’re working on. I’ll help you find a practical way forward.
Let’s talk about it