Product validation is the work of gathering evidence that a specific problem is worth solving for a specific audience, before any production code is written. A practical sequence runs through seven steps: define the segment, write the problem hypothesis, run discovery interviews, map existing substitutes, spike the riskiest technical assumption, prototype, then score the evidence. The output is not a feeling about the idea. It is a written argument that can survive a co-founder or an investor asking why.
Building an MVP without validating the product idea first is one of the fastest ways to burn a runway. CB Insights analysed 431 VC-backed startups that shut down between 2023 and early 2026, and running out of capital topped the list of failure reasons at 70%. That is the ending, though, not the cause. Among the 385 companies with an identifiable reason, 43% cited poor product-market fit, and two-thirds of those were early-stage teams that never found a market at all.
The uncomfortable part is that most of them built something that worked. It just did not matter to anyone.
This guide sets out a practical, step-by-step framework for testing assumptions, gathering evidence and making a build or no-build call before writing a single line of production code.
Start by getting specific about who the product is for. A product aimed at "small business owners" is too broad. A segment like "freelance accountants in the UK managing five to fifteen clients" is testable.
The more precise the segment, the easier it becomes to find interviewees, spot patterns and design something that resonates. Expansion can come later. Starting narrow is what makes the first round of testing cheap and fast.
Write down demographic details, job roles and the context in which users would hit the problem. This profile guides every other step in the validation process.
Before exploring solutions, commit to a single problem statement. It forces an honest split between what is known and what is still a guess.
A strong problem hypothesis follows a simple format: "[Target segment] struggles with [specific problem] because [root cause], which leads to [measurable consequence]." For example: "Freelance accountants struggle with reconciling client invoices because they switch between three different tools, which leads to two extra hours of admin work per week."
If that statement will not come out clearly, the idea is not ready to build. More conversations with potential users usually fix it.
Interviews are the primary source of pain proof. Five to ten conversations with people who match the target segment exactly is a workable first round. Avoid mixing different user types in the same batch.
The key principle is to ask about past behaviour, not future intent. Instead of "would you use a tool that does X?", ask "tell me about the last time you had to deal with invoice reconciliation." The approach comes from Rob Fitzpatrick's The Mom Test, and it surfaces real problems rather than polite enthusiasm.
Listen for frequency, context and cost. Good signals sound like "I do this every week" or "it takes me two hours each time." Vague compliments like "that sounds useful" are not evidence.
If the problem is real, the target users are already doing something about it. They might be paying for a competitor, using a spreadsheet or relying on a workaround. Document these substitutes in detail.
Understanding existing behaviour tells you where the real competition sits. Often it is not another startup in the space but the Notion database, the email thread or the Excel macro users already trust. Those substitutes are free, familiar and already integrated into someone's Tuesday morning, which makes them harder to displace than a funded competitor.
Identify exactly where each substitute breaks down. Those failure points are the positioning opportunity, and they point at features that address genuine gaps rather than imagined ones.
Before committing engineering time, test the single hardest technical assumption the product depends on. If the product requires real-time bank data sync, build a constrained proof of concept that tests only that integration.
This is not about creating a full demo. It is about getting a clear answer on the one risk that, if it goes the wrong way, makes everything else irrelevant. A one-day spike can save months of misdirected effort.
Regulated products raise the stakes here. Third-party integrations, regulatory APIs and data security requirements tend to be the assumptions teams discover late, and they are the ones most likely to reshape the roadmap when they break.
Once there is pain proof, behaviour proof and feasibility proof, it is time to test the proposed solution. A high-fidelity clickable prototype demonstrates the core user journey without production code.
Tools like Figma or Framer produce realistic interfaces in hours rather than weeks. The goal is to put something in front of real users and watch how they interact with it.
Run testing sessions with five users from the target segment. Watch where they get stuck, what questions they ask and whether they understand the value proposition without explanation. That feedback is what shapes MVP scope.
Validation is not a feeling. It is a written argument supported by evidence. A simple scorecard across four dimensions keeps it honest: pain proof, behaviour proof, feasibility proof and distribution confidence.
Rate each dimension from zero to five based on the strength of the evidence behind it, for a maximum of twenty. A low total is not a verdict on the idea, it is a signal that discovery is unfinished. A high total across all four, rather than a high total carried by one strong dimension, is what justifies moving into a build.
The scorecard does two things. It slows down emotionally driven over-building, and it creates a shared reference point for conversations with co-founders, investors or a development partner.
Building software is expensive. Even a modest MVP runs into six figures and several months of effort. Validation shifts that investment away from building something and towards learning whether the something should be built at all.
The alternative is familiar: a well-engineered product that solves a problem nobody has, or solves it in a way nobody wants. The financial cost is significant, but the opportunity cost is worse. Time spent building the wrong thing is time not spent finding the right thing.
A two-week validation sprint can surface insights that would otherwise take months to learn through a failed launch and a pivot. That gap is what makes validation worth the calendar time.
A focused validation effort runs two to four weeks. The calendar breaks down roughly as follows: segment definition and problem hypothesis take a couple of days, discovery interviews take one to two weeks depending on how reachable the segment is, the feasibility spike takes one to three days, and prototyping plus testing takes about a week.
Cost is driven by team composition rather than by the calendar. Validation typically needs a product strategist, a designer and a slice of an engineer's time, which is a materially smaller team than a delivery squad. That is the whole economic argument for doing it: a small team spending weeks to establish whether a large team should spend months.
For context on the other side of that decision, most MVPs land between $60,000 and $400,000, with simpler web and mobile products at the lower end and integration-heavy or regulated platforms at the top. Validation ahead of that runs at a small fraction of even the lower bound, because a three-person team working for a month is not comparable to a full delivery squad working for two quarters. It is also the only spend in the sequence that can pay for itself by preventing the larger one.
The first mistake is interviewing too broadly. Mixing enterprise clients with SMB owners, or primary users with secondary stakeholders, produces contradictory signals that feel like ambiguity but are actually category confusion.
The second is asking hypothetical questions. "Would you pay for this?" invites social desirability bias. People tell you what they think you want to hear. Past-behaviour questions surface what they actually do.
Four more patterns show up repeatedly:
Each of these is recoverable if caught early. Setting boundaries before development begins is usually cheaper than renegotiating them halfway through, which is the same decision underneath the MVP or MMP question.
Thinslices is a product development company that has shipped over 220 projects for funded startups and scaleups since 2010, with teams in Iasi, London and New York.
Our product validation sprint compresses discovery into a structured engagement that delivers evidence rather than opinions. We work with founders and product leaders to define problem hypotheses, run user research and test technical feasibility before engineering resources are committed. For teams building in financial services, our fintech work covers the regulatory, security and integration constraints that make early validation harder to skip.
Talk to our team about validating your product idea.
A focused validation effort typically takes two to four weeks. The exact timeline depends on how accessible the target users are and how complex the technical assumptions are. A product with a hard-to-reach segment or a novel integration will take longer than one with both readily available.
Yes. The purpose of validation is to test assumptions, not to build software. Pain, behaviour and even solution direction can be validated through interviews, competitor analysis and clickable prototypes. Code comes after there is evidence the product should exist.
Market research describes the size and characteristics of a market. Validation answers whether one specific product idea solves a real problem for a specific audience. Market research can look encouraging while validation fails, which is why the two are not substitutes.
Five to ten interviews within one specific segment is a practical starting point. Quality matters more than quantity. Look for repeated pain patterns and consistent language across conversations. If signals are still mixed after ten, the segment is probably too broad.
An idea killed after a two-week validation sprint costs two weeks. The same idea killed after six months of engineering costs a quarter and a chunk of team morale. The evidence usually points somewhere: a related problem, a different target segment, or a clean exit. All three are better outcomes than a launch nobody responds to.