One of the biggest mistakes a founder can make is starting to build a product in order to start collecting feedback.
An MVP is often described as the cheapest way to learn. But building software is rarely the cheapest way to collect feedback. By the time a functioning product exists, you may have already spent months of time, money, and energy validating an assumption that was never strong enough to build on.
Reduce uncertainty before you build.
Before writing software, founders should be having deep conversations with potential customers. Understand their workflows, identify painful problems, explore the outcomes they want, and learn what they do today to solve the problem—or live with it.
Prototypes make these conversations more concrete. They let people react to an idea without requiring you to build the entire system behind it. Landing pages, manual services, and early sales conversations can reveal other useful signals.
None of this creates certainty. Customer feedback needs to be treated with a grain of salt. People can be enthusiastic about an idea without changing their behavior, paying for it, or using it consistently.
The goal is not to collect compliments. It is to reduce the most important unknowns before making an expensive commitment.
Find the opportunity. Prove the value. Then build.
Our framework has three stages:
FIND THE OPPORTUNITY → PROVE THE VALUE → BUILD & COMMERCIALIZE
Find the opportunity: understand the customer, the problem, the current alternatives, and the outcome they actually want.
Prove the value: test whether the problem matters, whether the proposed solution resonates, and whether the message is strong enough to create interest or commitment.
Build and commercialize: create the product and sell it in tandem, using real customer behavior to guide what gets built next.
The order matters. We have seen founders invest heavily in developing an idea, launch it, and then discover that very few people find the initial product helpful. This creates a catch-22: you cannot learn what customers want because they do not use the product, and you cannot get them to use the product because you do not yet know what to build for them.
The answer is not to eliminate uncertainty before building. That is impossible. The goal is to answer as many important unknowns as you can so you can invest more confidently when it is time to build.
Build when you have enough confidence to create a useful learning loop—not simply because building feels like progress.