Don’t Build the MVP Yet. Prove the Problem First.
You know that moment when an idea starts feeling real?
Maybe you even start searching for developers, designers, or the “best tech stack for an MVP.”
But sometimes, it is only momentum.
And momentum can be dangerous when it is moving in the wrong direction.
The founder who built too early
Imagine a founder with a strong product idea.
The problem sounds obvious.
The solution feels useful.
A few friends say, “I would definitely use this.”
So the founder starts building.
The product gets cleaner.
The feature list gets longer.
A few say the product looks impressive.
But hardly anyone comes back.
The founder did not necessarily build a bad product.
They may have built a good product for a problem that was not painful enough.
That is the difference validation makes.
Validation asks whether the problem deserves a product before the product starts consuming your time, money, and energy.
Start with the uncomfortable question
Before asking what features the MVP needs, ask:
Who is already struggling with this problem today?
Not who might struggle someday.
Not who thinks the idea sounds interesting.
Who is actively dealing with it now?
A real problem usually leaves evidence behind.
People complain about it.
They create spreadsheets to manage it.
They combine several tools.
They hire someone to handle it manually.
They lose time, money, customers, or sleep because of it.
That behavior matters more than compliments.
Talk to customers without pitching
Customer interviews are not sales calls.
You are not trying to convince people that the idea is brilliant.
You are trying to understand what actually happens in their world.
When did this problem happen most recently?
What did you do to solve it?
What was frustrating about the process?
What happened when it was not solved?
Have you paid for another solution?
Founders often become so excited about the solution that they explain too much.
The most useful moments usually happen when the founder stops talking.
Do not ask, “Would you use this?”
People are generous with hypothetical support.
They say yes because the idea sounds useful.
They say yes because they want to encourage you.
They say yes because saying no feels uncomfortable.
But “I would use this” is not the same as:
“Can you send me the pricing?”
“Can my team join the pilot?”
Interest is polite. Commitment is evidence.
Build a landing page before a product
A simple landing page can teach you a surprising amount.
Show who the solution is meant for.
Then ask visitors to take one clear action.
The number of visitors matters less than the quality of their actions.
A waitlist of 2,000 random people may be less useful than 25 ideal customers who reply to your emails and ask when the pilot starts.
Test the promise manually
One of the smartest things a founder can do is deliver the result before building the system.
This is often called a concierge MVP.
Suppose you want to build software that automatically reviews customer support conversations and identifies urgent issues.
Before building the platform, you could ask a few companies to send you sample conversations.
You review them manually.
You prepare a structured report.
You send recommendations.
Would they want it every week?
That manual process will not scale.
You are not testing scale yet.
Let people experience the workflow
A clickable prototype can help customers understand the idea without requiring a full product.
But do not guide them through every screen.
Give them a realistic task.
Notice where they hesitate.
Notice what they expect to happen.
Notice which feature they ignore completely.
Sometimes the feature you love most is the one customers do not understand.
That is useful information to learn before development.
Talk about money earlier than feels comfortable
Many founders delay pricing conversations because the product is not ready.
But pricing is part of validation.
You need to know whether the problem is valuable enough to support a business.
What does this problem cost you today?
Do you already pay for another solution?
Who approves this kind of purchase?
What outcome would make this worth paying for?
Would you consider a paid pilot?
A deposit, paid test, or signed commitment is much stronger evidence than a positive survey response.
It does not mean every early customer must pay immediately.
It means the subject of money should not arrive as a surprise after the MVP is finished.
Pay attention to what people already do
A powerful startup signal is not what customers say they want.
It is what they are already doing.
Are they using spreadsheets?
Are they paying assistants?
Are they building internal workarounds?
Are they switching between five different tools?
Are they repeatedly searching for alternatives?
Existing behavior proves the problem has enough weight to create action.
Your startup does not need to invent demand.
It needs to find demand that is already trying to express itself.
Validation is not about eliminating risk
You will never have complete certainty.
There will always be unknowns.
The goal is not to remove every risk before building.
The goal is to avoid taking expensive risks based on assumptions that could have been tested cheaply.
A few interviews can test the customer.
A landing page can test the message.
A waitlist can test interest.
A paid pilot can test willingness to pay.
A prototype can test the workflow.
A technical proof of concept can test feasibility.
Each small experiment replaces one guess with evidence.
Know when the evidence is strong enough
You may be ready to build when:
Different customers describe the same problem
The problem happens frequently
Existing workarounds are frustrating or expensive
Qualified people request access
Some prospects discuss pricing seriously
Customers agree to pilots or other commitments
The prototype makes sense without heavy explanation
The main technical risks have been tested
You do not need everyone to say yes.
You need enough consistent evidence from the right people.
Sometimes validation tells you not to build.
That can feel disappointing.
But it may be one of the most valuable outcomes.
The audience is too broad
The buyer is different from the user
The price cannot support the cost
A simpler service works better than software
Another customer segment cares much more
Stopping or changing direction early is not failure.
It is what validation is supposed to protect you from.
Start with the customer’s problem, not your feature list.
Look for real behavior, recurring pain, current spending, and imperfect workarounds.
Do not treat compliments as demand.
Waitlists, meetings, pilots, deposits, and repeated use are stronger signals.
Test the outcome manually before automating it.
A concierge MVP can reveal whether the value is real.
Discuss pricing before launch.
A product is not commercially validated until someone is willing to make a meaningful commitment.
Build only what you need to learn next.
The first MVP should answer an important business question, not attempt to become the final product.
Before opening the code editor, try this:
Talk to ten qualified customers.
Study how they currently solve the problem.
Create one simple landing page.
Ask for one meaningful action.
Deliver the result manually to a small group.
Then decide what deserves to be built.
That process may slow you down for a few weeks.
It may also save you from spending a year building the wrong thing.
For a more detailed founder’s playbook covering customer interviews, landing-page tests, waitlists, concierge MVPs, willingness-to-pay experiments, and technical validation, read the complete guide from KSoft Technologies:
How to Validate Your Startup Idea Before Building an MVP