Here's the most expensive mistake in software, and nearly everyone makes it at least once.
You have an idea. You're excited. You build it for three months. You launch. Then nothing happens, and the silence is somehow louder than a rejection would have been.
What stings is realising you could have known in a week.
This lesson is about how people find out early. It's the least enjoyable part of the whole process and it saves more time than anything else here.
Why asking people doesn't work
The obvious move is to describe your idea and ask whether they'd use it.
That doesn't work, and it isn't because people are liars. It's that they're being kind, and that predicting your own future behaviour turns out to be genuinely difficult for everyone.
When you ask somebody about a thing you clearly care about, what they actually hear is "please approve of me." So they say "yeah, that sounds useful," and you walk away encouraged. That sentence is worth nothing. It cost them nothing and committed them to nothing.
The fix is to stop asking about the future and start asking about the past.
Past behaviour instead of future intent
Compare these two.
| What you ask | What you get back |
|---|---|
| "Would you use an app that tracks your invoices?" | Politeness |
| "Walk me through the last time you sent an invoice. What did you do?" | The truth |
The second one is more awkward to ask and enormously more useful. People are excellent at describing last Tuesday and hopeless at predicting next month.
Questions that tend to work: when did you last run into this, and what happened? What do you use for it now? Which bit is the most annoying? Have you ever gone looking for something better, and how did that go? Have you paid for anything to help?
Notice you never describe your idea. That's deliberate. The moment you pitch, it stops being research and becomes a sales call, and they go straight back to being nice to you.
Five or six of these conversations will teach you more than a month of thinking will.
Reading the signals
After a few conversations you're listening for particular things.
Encouraging: they've already tried to solve it themselves, badly. There's a workaround, a spreadsheet, a routine. They got visibly annoyed while telling you about it. They've paid for something adjacent.
Discouraging: it's "interesting" but they can't remember the last time it came up. They've never gone looking for a fix. They describe it as a nice-to-have. Everyone is vaguely positive and nobody is specific.
That last one is the real trap, because broad mild enthusiasm feels like validation. A handful of people who are genuinely irritated is a better sign than a crowd of people who are mildly interested, because irritation is what makes somebody reach for their card.
The cheapest possible test
Conversations tell you about the problem. They don't prove anybody will act.
For that you want the smallest thing that asks someone to do something slightly inconvenient. Not "would you use this," but an actual small action. A one page site describing the thing with an email box, and see if anyone signs up. A post in a community where these people already gather, and see if anyone replies asking when it's ready. Or the brave version: a pre-order, and see if anyone actually pays.
Money is by some distance the strongest signal. Ten people paying you five dollars tells you more than a thousand saying "cool idea." An email address is weaker but still real, because it costs them something small.
One thing that matters more than the test itself: decide what counts as a pass before you run it. Say out loud that if fewer than twenty people sign up in two weeks, you'll rethink. Skip that and whatever number arrives will feel like enough, because by then you'll want it to be.
A quick story. With my own app I did the building part properly and the checking part not at all. I had a waitlist page, a landing site, the whole thing. I never once put a price in front of a human being.
So I learned that people will hand over an email address for something free, which is nice but not information. The actual question, whether anyone would pay for this, stayed open the entire time I was building. Months of work, and the one thing I most needed to know was still unanswered at the end.
If I were doing it again I'd have asked for money in week one, badly, on an ugly page. The answer would have been useful whichever way it went.
What a "no" actually means
If the signals come back weak, that isn't the end of it. It usually means one of three things, and all of them are fixable.
You might be talking to the wrong people. The problem might be real but mild. Or the problem is real and your particular solution isn't the shape people want.
Each of those is worth knowing in week one rather than month six, which is the entire reason for doing any of this.
If you want help with the questions
The "don't let me pitch" line is doing real work in there. Resisting the urge to explain your idea is much harder than it sounds when you're excited about it.
Next: Deciding what not to build →
Go deeper: Chapter 4, Talking to Users and Chapter 5, Validating Demand