The cheapest way to test a product idea rarely involves an engineer. A practical framework for validating demand first.
The shortest version.
The cheapest way to test a product idea rarely involves an engineer. A practical framework for validating demand first.
First-time founders
Product managers scoping a new initiative
Engineering leads asked to build 'just an MVP'
Separate validating demand from validating feasibility
Choose the cheapest experiment that would genuinely change your decision
Recognize when 'more validation' is actually procrastination
Founders often equate 'building an MVP' with writing the smallest version of the final product, then discover after months of work that nobody wanted it in the first place.
Engineering time is the most expensive resource in an early-stage company. Validating demand before writing code turns an expensive bet into a cheap experiment, and prevents a technically well-built product from failing for a non-technical reason.
Investors and early customers rarely fund or adopt a product because it's technically impressive — they respond to evidence that a real problem is being solved for people who will actually pay or switch.
Most early 'MVP' failures aren't caused by bad code — they're caused by building the wrong thing well. Validation exists to catch this before engineering time is spent, since fixing a wrong product assumption after launch costs far more than testing it before writing any code.
The founders who move fastest after validation are usually the ones who ran the cheapest possible test first — a landing page, a concierge process, or a handful of customer conversations — rather than the ones who built the most polished prototype.
Demand validation vs. feasibility validation
Demand validation asks whether anyone wants this; feasibility validation asks whether it can be built. Teams often validate feasibility first because it's the comfortable, familiar work — but demand is usually the riskier unknown and should be tested first.
The concierge test
Manually deliver the product's outcome to a handful of real customers without building any software — a person doing the work a system would eventually automate. It's slow and doesn't scale, but it proves demand and reveals requirements no one could have guessed upfront.
Signal vs. noise in early feedback
Polite interest ('this is cool') is noise; a customer paying money, changing their workflow, or introducing you to someone else is signal. Validation frameworks fail when they only collect the former.
Define the riskiest assumption
Identify the single belief that, if wrong, would make the whole product idea pointless — usually about who has the problem and how badly they want it solved, not about a specific feature.
A team planning a two-sided marketplace publishes a landing page describing the product and collects paid deposits from early customers before writing any matching logic — proving willingness to pay before building the harder engineering problem.
A founder manually matches customers to service providers over email for the first twenty transactions, refining the exact matching criteria that later gets encoded into software — because the criteria weren't knowable until real transactions happened.
Asking people if they would use the product instead of watching what they do
Hypothetical interest is nearly free to express and a poor predictor of real adoption, leading teams to build for demand that never materializes.
Validating with friends, family, or existing users instead of the actual target customer
Feedback from people who already like you or the company is systematically more positive than feedback from a stranger with the actual problem.
Treating validation as a one-time gate instead of an ongoing practice
Assumptions that were true at initial validation can stop being true as the product and market evolve, and teams that stop validating after launch miss the moment their fit degrades.
BuildPath turns this into a personalized roadmap in about three minutes — or talk to Byld first if you still have questions.