How to launch a product: from idea to MVP / Decide what to build
How to validate a product idea before you build
The cheapest MVP is the one you never had to build. Before you commit engineers, you can test most of your assumptions with conversations, a landing page, a clickable prototype, or a service you run by hand without the user seeing it. Validation is how you find out the idea is wrong while it is still cheap to be wrong.
Published July 27, 2026. Editorial.
Key takeaways
- Test demand before you build, not after. Most bad ideas can be caught without code.
- Watch what people do, not what they say. Actions are honest, opinions are polite.
- Look for real demand: users trying to use the thing, paying, or asking when it is ready.
- You are testing your riskiest assumption, so name it first, then design the cheapest test of it.
Most failed products were built competently. The problem was not the engineering. It was that nobody wanted the thing, and the team found that out only after spending months building it. Validation is the work of finding that out first, when it costs a week instead of a year.
Name the assumption you are testing
Validation without a clear goal is just asking people if they like your idea, and they will be polite. Start by naming the single riskiest assumption in your product. Is it that people have this problem badly enough to care? That they will switch from what they use now? That they will pay? That you can technically deliver it? Each of those needs a different test, so you cannot design the test until you know which assumption you are checking. This is the same riskiest-assumption thinking that drives how to scope an MVP.
Talk to real potential users first
The cheapest validation is a conversation. Find people who actually have the problem and talk to them, not your friends and not investors. Ask about their current behavior, not your idea. "How do you handle this today? What is the worst part? What have you tried?" Their answers tell you whether the problem is real and painful. If people shrug when they describe the problem, no product fixes that. You want people who are clearly frustrated and already trying to solve it themselves.
The mistake here is leading questions. If you ask "would you use a tool that does X," almost everyone says yes to be nice. That answer is worthless. Ask about what they do now, and let the problem appear on its own.
Test with things you can build in days
Beyond conversations, a few cheap tests reveal a lot before any real build.
A landing page that describes the product and asks for a sign-up tells you whether the promise attracts people. Real email addresses from people who found it are stronger evidence than any survey.
A clickable prototype, built in a design tool, lets people go through the main steps and react to something concrete. You learn where they get confused and whether the idea makes sense to them, without writing production code. Good UX and UI design at this stage is validation, not decoration. If you are deciding whether to buy that design work and from whom, our product discovery and UX design guide covers the whole purchase.
A manual version of the service, where you deliver the value by hand without the user seeing it, while the user thinks it is a product, is one of the strongest tests of all. It proves people want the outcome before you build the software that produces it. Several well-known companies ran the first version of their service manually before automating anything.
Read the results honestly
The hardest part of validation is not running the tests. It is being honest about what they say. Founders who are strongly attached to an idea find reasons to read weak evidence as strong evidence.
Watch what people do, not what they say. Someone who signs up, comes back, and asks when it launches is showing you real demand. Someone who says "great idea, I would totally use that" and never engages again is showing you politeness. Real demand looks like people trying to use the thing before it is ready, paying, referring others, or getting annoyed that it does not exist yet. If you have to keep persuading people to try the product, that is a warning, no matter how nice they are about it.
When you have enough evidence
You never get certainty, and waiting for it is its own failure. You are looking for enough real demand to justify a build, not proof. Once a clear group of people show they want this badly enough, stop validating and start scoping. Take what you learned straight into the main guide and into how to scope an MVP, where the validated assumption becomes the thing your first build tests. As we argue in knowing what to build, being right about what to build is the most important part, and validation is how you gain that confidence cheaply.
Common questions
How do I validate a product idea without building it?
Test demand with things you can make in days: conversations with real potential users, a landing page that asks for sign-ups, a clickable prototype, or a version of the service you run by hand without the user seeing it. Each tests a different assumption without production code.
What is the difference between what users say and what they do?
People are polite about ideas, so what they say is weak evidence. What they do is honest: signing up, coming back, paying, referring others, or getting annoyed the product does not exist yet. Weight actions far more than opinions when you judge whether an idea is validated.
How much validation is enough before I build?
You will never get certainty, and waiting for it is its own mistake. You are looking for enough real demand from a clear group of users to justify a build. Once people show they want it badly enough that they actively ask for it, stop validating and start scoping.
What is the difference between validating an idea and testing an MVP?
Validation happens before any product exists, using conversations, landing pages, prototypes, or a manual version of the service to see if the idea has demand. Testing an MVP happens after you have built a real working product, using actual usage to see whether people get value from it. Validation shows the build is worth doing. The MVP tests it with something real.
How long should idea validation take?
Validation should take days, not months, because the entire point is to find out an idea is wrong while it is still cheap to be wrong. Conversations, a landing page, or a manual version of the service can all be run quickly. If validation is stretching for weeks with no clear evidence either way, that lack of demand is itself an answer worth taking seriously.
What are common mistakes founders make when validating an idea?
The most common mistake is asking leading questions like whether someone would use a tool that does X, which almost everyone answers yes to out of politeness. Other mistakes include talking only to friends instead of real potential users, and mistaking a polite compliment for genuine demand. The fix is to ask about current behavior and watch what people actually do.
Is it safe to skip validation and build the MVP directly?
Skipping validation is risky because most failed products were built competently but nobody wanted the thing, and the team only found that out after months of work. Validation with conversations, a landing page, or a manual version of the service can catch a bad idea in days. Skipping it trades a small, cheap risk for a much larger and more expensive one.
What questions should I ask when validating a product idea?
Ask about current behavior instead of the idea itself: how do people handle this problem today, what is the worst part of it, and what have they already tried. Their answers reveal whether the problem is real and painful. Avoid leading questions like whether someone would use a tool that does X, since almost everyone answers yes to be polite.
How a build like this runs
Related reading
Knowing what to build is now the most important decision
AI made writing software cheap. That moved the hard part earlier, to deciding what deserves to be built and having the discipline to cut the rest.
You cannot measure engineers by how much they produce
Lines of code, tickets closed, and hours logged all measure activity rather than progress. Here is how we think about engineering output without numbers that only look good.
More in Decide what to build
How to scope an MVP
Scope is the most important decision in your launch, and it is where most MVPs go wrong. The fix is to scope around one question, not your whole roadmap. Define the single core action that tests your riskiest assumption, build only what is needed for it, and let everything else wait.
How to prioritize features for a first version
When the feature list is long and everyone involved wants their idea in version one, prioritization gets political. The fix is a shared rule that ranks features by how much they serve the one thing your MVP tests, not by who argues hardest. Make the rule explicit and the arguments get easier.