Validate the sale before you build the product

Founders with commercial instincts tend to be good at describing a product and bad at delaying it. The idea is clear, the market is obvious, and the only thing standing between here and revenue appears to be a build. So the build starts, and months later the product exists and the customers do not.

The problem is almost never the code. It's that the purchase was assumed rather than tested. Validation isn't a survey or a landing page with an email box. It's evidence that a specific person, with a specific budget, will move when the thing exists.

What counts as evidence

Interest is cheap. People will tell you an idea is great because the conversation is more pleasant that way. Look instead for signals that cost the other person something:

• A named person who has described the problem in their own words, unprompted, and can quantify what it costs them.
• An existing workaround they're paying for — a spreadsheet, a contractor, a tool they hate. Someone already spending is someone already sold on the problem.
• A willingness to commit ahead of the product: a deposit, a letter of intent, a pilot slot on the calendar, an agreement to be the first paying account.
• A repeatable pattern. One enthusiastic buyer is a relationship. Five with the same story is a market.

Sell the outcome manually first

Before any product exists, deliver the outcome by hand for one or two customers. Do the work in a spreadsheet, over email, on a call — whatever it takes. It is slow and unglamorous and it teaches you more in three weeks than three months of building will.

You learn where the real friction sits, which parts of your assumed workflow nobody cares about, and what people actually pay for versus what they said they wanted. Then the first version of the software automates something you've already proven someone buys.

Write down what would change your mind

Before you start testing, write the specific result that would make you stop. "If I can't get three companies to agree to a paid pilot in six weeks, the positioning is wrong." Founders who skip this step invariably reinterpret weak signals as encouragement, because the alternative is admitting the plan needs work.

Validation is not permission to build. It's evidence about what to build, and for whom, and in what order.

When validation is done

You're finished when you can name the customer, describe the moment the problem hurts, state what they currently spend on it, and point to people who have committed before the product exists. At that point, building stops being a bet and becomes execution — which is where a technical partner earns their place.