The advice to "validate before you build" has been repeated so often it has lost meaning. Founders hear it, nod, and then spend eight months building something nobody asked for. This article is not another abstract argument for validation — it is a collection of real failure patterns with specific, concrete alternatives that could have changed the outcomes.
The "Obviously Needed" Problem
One of the most common failure patterns: a founder experiences a problem personally, concludes that millions of people must have the same problem, and builds a solution without checking whether those millions of people experience the problem the same way or care enough to pay to solve it.
A freelance developer built a time-tracking tool because they found existing tools "too complex." They spent 9 months building a beautifully simple alternative. At launch, they discovered two things: first, the people who found existing tools complex were exactly the people who did not pay for any time-tracking tool at all (they were tracking hours in spreadsheets and had no urgency to change). Second, the paying market — agencies and studios that tracked billable hours for clients — required precisely the features they had removed in the name of simplicity. The product had no path to revenue.
What validation would have found: Ten customer interviews with people who actually paid for time-tracking tools would have revealed that "simplicity" was not the top request from the paying segment. Their actual requests were better client-facing reports, integrated invoicing, and team management features. The product they built solved the wrong problem for the wrong customer.
The "Field of Dreams" Launch
Another pattern: a founder builds a complete, polished product and launches expecting customers to discover it organically. Three months after launch: 50 signups, 3 paying customers, and a slowly dwindling bank account.
A product-market fit problem and a distribution problem are often confused. The founder assumes the lack of growth is a distribution problem ("I need better SEO, more content, a Product Hunt launch") when it is actually a product-market fit problem — the product exists in a category with many alternatives and offers no compelling reason for customers to switch.
What validation would have found: Competitive review analysis on the 5 existing tools in the category would have shown that users were mostly satisfied with existing options. The 2-star and 3-star reviews would have revealed specific pain points — but they were pain points the founder's product also did not solve. The category had 80% satisfied customers and 20% who were frustrated with the same 3 specific things. A product that directly addressed those 3 things had a story. A product that was "simpler" in a category where simplicity was not the primary complaint had no story.
The Premature Scaling Failure
A founder raises a seed round, hires a small team, and builds aggressively for 12 months. The product launches to initial customers who are enthusiastic. The team scales marketing spend. Growth stalls at 200 customers. Investigation reveals that the 200 customers who signed up were all early adopters drawn by novelty — the mainstream customer has different needs that the product doesn't address.
This failure is expensive because it involves investor money and a team's time. The core validation gap: the founder validated with early adopters (who will try anything new) rather than mainstream buyers (who need a strong reason to switch from an existing solution). These are different populations with different decision criteria.
What validation would have found: If the founder had conducted customer interviews that specifically targeted mainstream buyers — people who had been using an existing solution for 2+ years — they would have discovered that switching cost objections were significant and that the product's differentiation was insufficient to overcome them. This finding is available before building through careful interviews and competitive positioning work.
The Technical Solution in Search of a Problem
A technical founder builds a novel infrastructure tool using a new technology they find exciting. The technology is genuinely impressive. The problem it solves is one that 0.1% of engineering teams encounter at a scale most companies never reach. Market size: too small to build a business.
What validation would have found: Bottom-up market sizing before building. If the addressable customer is "engineering teams at companies processing more than 10TB of data per day," and there are 500 such companies globally, and the realistic capture rate is 20%, and the pricing is $2K/month — that is $2.4M in potential ARR. That might be a consulting project or a feature for an existing platform; it is not a venture-backed company. This arithmetic is available before writing any code.
What Good Pre-Build Validation Actually Looks Like
The goal of validation is not to achieve certainty — it is to collect enough evidence to make a confident decision about whether to invest significant time and money. Good pre-build validation includes:
- Competitor review analysis: Read or use tools like GoShipOrSkip to analyze what real paying customers of existing products say — what works, what doesn't, what they wish existed. This tells you whether the market is underserved and what a winning product would need to do.
- Customer interviews: 10–15 conversations with people in your target segment, focused entirely on their current workflow and frustrations — not on your product idea. These conversations reveal whether the problem you identified is real and how urgent it is.
- Willingness-to-pay signal: Ask a subset of interview subjects directly: "If a product solved this problem, what would you pay per month?" This conversation is uncomfortable and the numbers are imprecise, but they are far more informative than assuming.
- Landing page test: Describe the product and its core value proposition on a landing page and drive traffic to it. Email capture rate is a weak signal; pre-order conversion rate is a strong signal.
The entire validation process above should take 3–6 weeks and cost very little. The products described in this article cost 6–18 months of development time and, in some cases, investor capital. Front-loading validation is the highest-leverage investment a founder can make.