How to Validate a Digital Product Before You Build It

The most expensive mistake in digital products is not a bad product. It is a good product nobody asked for. Someone spends three weekends building a course, launches it to silence, and concludes the model is broken. The model is fine. The order of operations was wrong. Validation is just doing the cheap test before the expensive build.

The short version#

Validating a digital product means getting real evidence that a specific group of people will pay for a solution before you build the solution. Not "would you buy this?" evidence, which is polite and worthless, but "here is my money" evidence or the closest honest version of it.

The whole idea rests on one uncomfortable truth: people are generous with encouragement and stingy with money. Ten friends can tell you your idea is great and zero of them will buy. So validation is the art of separating what people say from what they do. The closer your test gets to an actual purchase decision, the more you can trust it.

You do not validate to feel confident. You validate to find out you are wrong while it is still cheap to change course. A weekend spent testing an idea that flops is a win. Three months spent building it would have been the loss.

Where does the money actually come from?#

Before you can validate anything, you have to know what you are validating. The money in a digital product comes from a specific person paying to solve a specific problem they already know they have.

A specific person
  ↓
who has a specific, painful, recurring problem
  ↓
sees that your product solves exactly that problem
  ↓
decides the price is less than the pain
  ↓
pays

Validation tests every link in that chain except the last one, before you build. Is the person specific enough to reach? Is the problem painful enough that they are already trying to solve it? Does your solution obviously match the problem in their eyes, not just yours? If any link is weak, the sale never happens, and no amount of polish on the product fixes a broken link earlier in the chain. This is the same mechanism behind how digital products make money: the file is the easy half, and the demand is the business.

How it actually works#

Validation runs on a ladder of signals, from weak to strong. The higher you climb, the more the signal is worth, because it costs the person more to give it.

• Opinions (weakest). "That sounds useful." Free to say, means almost nothing. Discard.
• Stated intent. "I would totally buy that." Still free, still cheap talk. Barely counts.
• Attention. Someone clicks a link, reads the whole pitch, watches the video to the end. They spent time. That is a real signal.
• Contact. Someone gives you their email to be told when it launches, or joins a waitlist. They spent a small piece of trust.
• Money (strongest). Someone preorders, puts down a deposit, or buys an early version. This is the only signal that fully counts, because it is the exact behavior you are betting the business on.

The trick is to design a test that reaches as high up this ladder as you can afford, as early as you can. A landing page that collects emails is good. A landing page with a real "buy now" button that takes actual preorders is far better, even if you refund everyone and say the launch is delayed. What you learn from a real payment is worth more than what you learn from a hundred surveys.

There is a specific trap worth naming here. Asking "would you pay $30 for this?" is not validation, because the person answering risks nothing by saying yes. Watching whether they click a $30 checkout button is validation, because now saying yes has a cost.

A simple example with numbers#

These numbers are hypothetical and exist to show how a validation test reads, not to promise a result.

Say you want to sell a $39 spreadsheet-and-guide bundle for freelance bookkeepers who struggle to price their services. Instead of building it, you spend a weekend on a one-page pitch that describes exactly what the bundle does, with a real checkout button, and you drive a small amount of traffic to it: a few relevant online communities, a handful of dollars in ads, whatever you can reach honestly.

Visitors to the pitch page          200
  ↓
Clicked the "buy" button             14   (7% wanted it enough to try)
  ↓
Actually entered checkout             5   (2.5% reached for a card)

Now read the signals. Fourteen people clicking buy is real interest. Five people reaching checkout is a strong signal that the problem and price line up, and you have not built anything yet. You can either take those five real preorders and build the product for people who already paid, or, if you would rather not sell something that does not exist, capture their emails, tell them it launches in two weeks, and build with genuine demand waiting.

Compare that to the version where you build first: three weekends of work, then you find out only five in two hundred wanted it. Same information, wildly different cost. Validation just moves the discovery to the front.

What you need#

• A specific audience you can actually reach. "Freelance bookkeepers" is reachable. "People who want to be productive" is not.
• A clearly stated problem and solution. You need to describe the product well enough that someone can decide, even though it does not exist yet.
• A simple pitch page. One page, one offer, one button. A landing page builder or even a basic site is enough. See what a landing page is.
• A small amount of traffic. You cannot validate demand with zero visitors. This is where most tests quietly fail, because getting eyeballs is the same hard problem the finished product would face.

What it costs#

Required:

• Your time to write an honest, specific pitch.
• A free or cheap way to put up a page and collect emails or preorders.

Optional:

• A small ad budget to buy a first trickle of traffic quickly instead of waiting for it.
• A checkout tool that can take real preorders if you want the strongest signal.

Nice to have:

• A tiny existing audience or email list, which makes the whole test faster and cheaper because you are not starting from zero traffic.

How long it takes#

A basic validation test can run in a weekend to set up and a week or two to gather enough responses to read. The variable is traffic. If you already have an audience, you can learn what you need in days. If you are starting cold, budget longer, because you are testing your ability to reach the audience at the same time, and that is useful information too. If you cannot get anyone to the page at all, that is your answer before you have built a thing.

What beginners usually get wrong#

• Building first, asking later. The default mistake. It feels productive because you are making something, but you are making it blind.
• Trusting compliments. Friends, family, and social media comments will encourage you into a product nobody buys. Only behavior counts.
• Asking leading questions. "Isn't this a great idea?" gets you the answer you want, not the truth. Ask what they currently do about the problem and what they have paid to solve it before.
• Validating the wrong thing. A validated audience with a validated problem is not the same as a validated price. Test whether they will pay, not just whether they care. That is what how to price a digital product is for.
• Calling one lukewarm test a failure. Sometimes the idea is fine and the pitch was weak. Learn to tell a demand problem from a messaging problem.

How I would start#

1. Pick one specific group of people I can actually reach and one real problem they already spend time or money trying to solve.
2. Write a one-page pitch that describes the exact product and outcome, honestly, as if it already existed.
3. Put a real button on it: a preorder, a waitlist, or an email capture, ranked by how strong a signal I want.
4. Send a small, real amount of traffic to it from places those people already gather.
5. Read the behavior, not the compliments. Clicks and checkouts over comments and likes.
6. Only build the product once the test shows people reaching for their wallets, and build it for the people who already raised their hands.

What I would not do#

I would not spend a single weekend building the product before I had evidence someone would pay for it. I would not treat "that sounds cool" as demand. And I would not run a validation test with no traffic and then blame the idea, because a test nobody sees proves nothing. Validation is not a formality you do to feel safe. It is the cheapest research you will ever run, and it exists to save you from building the wrong thing beautifully.