Why do people say they'd use your product and then never buy it?

I validated Mailyond before writing any code. People described the pain in detail: support email for several products landing in a personal Gmail, replies going out from the wrong address, the same DNS setup done again for every new domain. I had 5 separate signals and all of them described the same problem.

So I built it. Then I gave 10 people free access, and 0 of them used it. Price was never the problem, since it was free.

The pain was real. What I hadn't validated was whether anyone would switch.

"I'd use this" and "I'll switch to this" are different answers

People are polite, and they're honest about their problems, so you get the first yes easily. Only the second one pays, and for that they need a reason to stop using whatever they have today.

For Mailyond, what they had was a messy setup that worked well enough: Cloudflare forwarding into Gmail, a send-as alias and a separate service for sending. Nobody loved it, but everybody had already paid the cost of setting it up, and switching meant paying a new cost to fix something they could live with.

I think that's the real competitor for most products, the setup people already have that works, even if badly.

4 questions that test the switch

Ask these in every validation conversation, after they've told you about the pain. They follow the rule from Rob Fitzpatrick's The Mom Test: ask about what people do today, never whether they like your idea.

1. What do you use today? Ask for the actual tools and steps, not only the category.
2. What would changing cost you? Time, migrating data, the risk of breaking something, teaching it to someone else.
3. What would force the change this month? A deadline, a bill, a broken workflow, a client asking for it.
4. Have you already tried to fix it? People who already tried a workaround tend to switch, people who only describe the pain often don't.

If nobody can name a cost of staying put, the pain is real and the sale isn't.

Check the buyer before the pain

There are two questions I now ask before any of the above, because an idea can pass every other check and still fail here.

Who buys, and why now?

People pay when revenue is attached to the outcome (it makes or saves them money they can see), or when a deadline or a regulation forces the purchase, like tax season, a compliance date or a contract. Buyers with neither are the most crowded market there is, and they pay badly.

Is it a painkiller or a vitamin?

A painkiller fixes something that has to be fixed now. A vitamin is annoying, but it can wait and people survive it with a workaround. Vitamins get "I'd use this" and rarely "I'll switch".

Two of my products handle support for founders, which is a vitamin sold to a buyer with no deadline. One ranked on Google and got over 2,500 visitors for 1 sale. The other is Mailyond, with 0 paying customers so far.

Money is the only willingness-to-pay signal

People who join a waitlist are mostly being polite, and paying is the only signal that they actually want it. If a paid pre-order feels too heavy for where the idea is, run the waitlist, but count it as a pain signal and nothing more.

In B2B you can sell before you build. Marc Lou cold-emailed escape room owners about a tool that didn't exist yet. One 42-minute call ended with a $99/month subscription, and that product went on to make around $100K.

Write the kill criterion before the conversations

One sentence, with a date. For example: "If 10 conversations inside the buyer group produce nobody who names a reason to switch now, and no paid pre-order, I kill this idea at the end of next month."

If you write it down before the calls, you have to respect it. If you decide after, you'll always find a reason to keep going.

This has worked for me before. I killed a profit tracker for founders after validation showed they were happy with their spreadsheets, before I spent months on it. Mailyond passed the pain check, and the question for it now is the switch one: does anyone outside me connect a real domain and keep using it.

My minimum before writing product code now is about 10 conversations inside the actual buyer group, plus one written kill criterion.

When you can skip all of this

If you're solving your own problem, the build takes days and you already have an audience to launch to, shipping is the validation. Marc Lou's ShipFast, a boilerplate for developers like him, made $40K in its first month that way.

Being the user tells you what to build, though, and says nothing about whether the market pays. Pair it with a real payment early, a paid pre-order or charging from launch day.

Where this fits

Validation sits before everything else. If you're past it and outreach gets nothing back, debug the outreach in order, starting with who you're messaging. If you haven't picked who to message yet, score your segments first.

The switch questions are one page of the validation chapter in the Distribution Framework, the playbook I use for my own products.