Sell before you build is an existing product validation methodology, not something I came up with. It sits in the same family as customer discovery, pre-selling, landing page smoke tests, founder-led sales, and Lean Startup validation. The version I care about is simple: put the awkward buying decision in front of someone before the team spends months making the product feel inevitable.
I keep coming back to it after working around dozens of MVPs, looking at my own ideas, and seeing products built by founders I know. A PoC often drifts toward the question engineers are best prepared to answer: can we make a smaller version of this work? Sometimes that is worth answering. Sometimes the expensive unknown is sitting somewhere else entirely.
When A PoC Feels Too Productive
A product-shaped PoC is attractive because it gives everyone something to look at.
Build the core flow. Add a rough interface. Connect the important data source. Put a dashboard in front of the team. For an engineering team this feels like movement, and in a narrow sense it is. There is more software than there was last week.
In some projects, that is exactly the right work. If the unknown is data quality, latency, hardware reliability, model accuracy, or whether an integration can be made usable at all, a technical PoC can save the team from selling a fantasy.
The trouble starts when the hardest part is not technical. A prototype can make an idea easier to demo while leaving the buyer’s actual decision untouched.
One Project That Looked Wrong Early
One example was a project I worked on that felt doomed from the moment I saw the assumptions behind it.
I do not want to share the identifying details, because the specific product is not the interesting part. The idea was buildable, and that made it tempting to treat engineering as the main problem. What worried me was that customers had to commit before they could know whether it would save them anything.
It was not a small weekend prototype either. Months went into research, design, infrastructure, DevOps work, data pipelines, and monitoring before the market gave a real answer. The system needed to collect data, move it somewhere reliable, make it visible, and alert someone when things stopped working. None of that was fake work. It was just work done before the painful part of the product had been tested.
Early research sounded positive. People liked the outcome. They agreed the problem mattered. Some said they would pay for help understanding it better.
I remember being uncomfortable with that read because the conversations skipped the uncertainty in the offer. It is easy to like the promised outcome in a conversation. The first few weeks, however, might reveal interesting patterns without producing any meaningful saving.
Would people still move forward once that uncertainty was stated plainly? I wanted that tested much earlier.
Research Can Be Too Polite
People are often generous in research conversations.
They picture the product working well. The setup feels smaller when it is only being described. The benefit arrives quickly in their head because the demo or survey has no waiting period. In some contexts, a direct no also feels rude, especially when the person asking is clearly excited about the idea.
I would not throw that feedback away. I would just be careful about what it actually says.
There is a big practical gap between:
- “This sounds useful.”
- “I would try this.”
- “I would pay for this.”
- “I would pay before I have proof it works for me.”
Those answers live near each other in a survey, but they lead to very different product plans. A person can honestly say yes to the first three and still disappear at the fourth.
What I Would Test First Now
Sell before you build is easier to say than to do. In practice, I do not think it asks engineers to stop writing code until money appears. I try to find the part of the product where the customer has to give up something: budget, time, data, internal effort, or trust. Test that before the team spends months making the technical version impressive.
For that kind of product, I would start with a very plain offer: the problem we think we can help with, what the first version would require from the buyer, the likely price or range, and the part we cannot prove yet.
Then I would ask for a step that costs something. A paid pilot is the cleanest version, but not the only one. A deposit, a booked installation slot, access to real data, an introduction to the budget owner, or internal time from the team that will actually use the product can all tell you more than another friendly demo.
The weak answers are easy to recognize once you start listening for them: keep me posted, send me the deck, come back when it is ready, maybe when we have budget. None of those are bad answers. They are just not the same as someone making room for the product in their calendar, process, or wallet.
You can do this without pretending the product already exists. In fact, the conversation is cleaner when you say the opposite. We are considering building this. We want to know whether the setup and price make sense before we spend the next few months making it production-ready.
Build After The Awkward Answer
Some code will still be needed. A landing page, a mockup, a small integration test, a spreadsheet-backed service, or a manual process can make the offer easier to understand. I am not arguing for sitting in sales calls with no artefact at all.
I am arguing against hiding inside the artefact. If the product asks a buyer to commit before the value is clear, the PoC should test that decision directly. Otherwise the team may only learn that it is good at building a believable version of its own assumption.
For the project I described earlier, I would now try to sell the pilot before building most of the system. I would be open about the uncertainty in the first serious conversation. If the buyer hesitates there, that hesitation is worth understanding before building the app.
That is uncomfortable for engineers because it moves the rejection earlier. It is also kinder to the team. Finding out after a sales conversation hurts less than finding out after months of work and a product launch nobody signs up for.