Proof of demand validation - most of yours has already happened

Picture the standard validation exercise. A landing page goes up describing a product that does not exist, a modest advertising budget pushes some strangers towards it, a few dozen of them leave an email address, and after six weeks you have a spreadsheet and a conclusion: there might be something here. If you have spent the last decade being paid by the people you intend to sell to, you have just spent six weeks establishing something you already knew.

This is the part of the received wisdom that costs expert businesses the most, because it is not obviously wrong. Testing before building is sound advice. The difficulty is that the standard programme is designed for somebody with no customers and no evidence, so it starts from zero, and if you start from zero when you are not at zero, you spend real money learning things your invoices could have told you in an afternoon. Worse, you finish the exercise feeling validated, when the question that could actually sink the product was never on the list.

In this blog, Elliott Prince, Managing Director at Ferrous Labs, explains which parts of demand validation your track record has already settled, the one question it genuinely cannot answer, and how to test that question properly rather than testing everything.

Most of your validation has already happened

Demand validation is really a stack of separate questions that usually get treated as one. Does this problem exist? Does it recur, or was it a bad quarter? Do people experience it as painful enough to act on? Will they pay to have it solved, and roughly how much? A business starting cold has to answer all four, and each one costs time and money.

An established consultancy has answered all four, repeatedly, under the most demanding conditions available. Every engagement was somebody with a budget deciding this problem was worth money. Every repeat client was the same decision made again with full information about what they got last time. Every project you declined for lack of capacity was demand that presented itself and went unserved, which is about as clean a signal as exists. You even have price discovery, because you have been quoting for this work for years and you know which quotes were accepted without argument and which ones were negotiated.

That evidence is stronger than anything a landing page produces, and it is worth being clear about why. A stranger giving an email address has risked nothing and promised nothing, in response to a description of something they cannot use yet. A client paying an invoice has committed budget, accepted a delivery date and staked some internal credibility on the choice. These are not the same quality of signal, and only one of them is sitting in your accounting system already.

The one question your history cannot answer

So if the demand is established, what is left? One thing, and it is the thing that actually decides whether this works: does the value survive without you in the room?

Your clients are buying a bundle. Some of it is the method, and that is the part you intend to productise. But some of it is you, and the rest is everything around you: the relationship, the reputation that made them call in the first place, the fact that a named person is accountable when it goes wrong, and the conversations that happen either side of the formal work. Separate the method from that bundle and sell it as software to somebody who has never met you, and you are asking a genuinely different question of the market.

Sometimes the answer is yes, and those are the products worth building. Often the answer is that the method was never really separable, and the value was in the judgement applied to the particular case rather than in the procedure itself. That is not a failure, but it is much better discovered before the build than afterwards, and no amount of asking existing clients whether they like the idea will reveal it. They like you.

How to test the thing you do not know

Once the question narrows, the testing gets both cheaper and more informative, because you are no longer trying to establish demand in general.

Start by defining precisely who you are testing on, and make it people who do not already know you. Feedback from your own client base is contaminated for this specific purpose: they will be encouraging, because they like working with you and because being asked is flattering. You need the reaction of somebody with no relationship to protect.

Then put something in front of them that they can react to. An interactive prototype, an offer-led page describing the product in the terms a buyer would use, or a single-feature tool that does one useful thing properly. It needs to be concrete enough that a reaction means something, which a description of a concept rarely is.

When you gather responses, separate what people say from what they do. Asking "would you use this?" and "what would you pay?" is worth doing, but treat the answers as colour rather than evidence, because people are generous in the abstract and careful with actual budget. Look instead for behaviour that costs something: a prototype somebody returns to unprompted, a waiting list somebody joins with a work email address, a pre-commitment somebody is willing to put in writing, an introduction to a colleague. And look for consistency across responses rather than the memorable single conversation, which is usually the one you wanted to hear.

The honest test throughout is whether anybody is enthusiastic or merely polite. Politeness is the default setting in professional conversation, and it produces feedback that feels encouraging and predicts nothing.

What a proper experiment is actually for

In our own method this work has a stage of its own. Product Experiment sits after Product Hypothesis and before anything gets built properly, and it exists to answer two questions together: will people pay for this, and can the technology do the job to the standard your own experts would accept? Those belong in the same stage because either one can end the project, and finding out about the second after committing to the first is how budgets get spent on products that work commercially and disappoint technically.

It is worth saying what this is not. None of the above is demand forecasting, which is the separate exercise of predicting volumes for something you already sell, and which we cover in our piece on how accurate AI demand forecasting really is. Proving that anybody wants a thing that does not exist yet, and predicting how much of an existing thing will sell next quarter, are different problems with different methods, and conflating them tends to produce confident forecasts of imaginary demand.

Stop proving what you already know

There is a comfort in the standard validation programme, which is that it feels like progress and cannot really fail. You will always find some interest, the spreadsheet will always support carrying on, and none of it commits you to anything. Testing the question that could actually stop you is a good deal less pleasant, which is exactly why it gets left until the product is built and the answer is expensive.

So before you set up anything, spend a few days with your own records. Mark which engagements of the last two years were substantially the same job, what you charged, what you turned away and why. That is your demand evidence, and it is better than anything you could go and collect. Then take what is left over, which will be one uncomfortable question about whether the method travels without you, and design the smallest honest test of that single thing.

Get that right and you are not gambling on whether anybody wants this. You already know they do. You are finding out whether they want it from a piece of software rather than from you, which is a question worth a few weeks and a proper answer.