Quick Answer
Doing real research before you build (interviews, shadowing, site visits) proves you found a problem. It doesn't prove anyone wants it fixed badly enough to change what they're doing. Before you write a line of code, run five questions past the people you talked to. If they can't answer at least three of them with a real, specific moment, you're holding a vitamin, not a painkiller, and building will not fix that.
Real Research Still Isn't the Same as Real Demand
You did the legwork. You shadowed someone doing the job, sat in on their day, visited a handful of locations, took notes on where things broke down. That's boots-on-the-ground validation most people skip before they build anything, and it should count for something.
Here's the problem. Watching someone struggle with a process and confirming the process has a gap in it is not the same as confirming they want that gap closed. You can walk away from a full day of shadowing with an accurate diagnosis of a workflow problem and still have found something nobody's asking to be rescued from.
That gap is the difference between a vitamin and a painkiller. A painkiller gets taken because something already hurts. A vitamin gets taken because it might help someday, if you remember, if it's not too much trouble. Most people don't reorganize their week around a vitamin.
Good research makes this hard to see. You did the interviews. It feels like proof. But proof a problem exists and proof someone will act to fix it are two different questions, and the second one is the only one that predicts whether you get any traction at all.
Free Doesn't Mean Frictionless
There's a second trap right behind the first one. You build the thing, give it away for free to remove any excuse not to try it, and still can't get anyone to open it.
Price is only one kind of cost. A busy person also has to spend time learning something new and decide whether to trust a tool they've never used before. Neither of those shows up on a price tag, and neither disappears just because the checkout number is zero.
If someone has run their process a certain way for years without a visible problem, a free tool that asks for a process change is still asking for something. It's asking for trust and a new habit, and those cost more than most builders budget for.
The 5-Question Vitamin or Painkiller Test
Run these against conversations you've already had, or use them in your next round of interviews before you build anything new. You're not looking for polite agreement. You're looking for a specific, remembered moment.
1. Did they bring the problem up first?
Go back through your notes. Did the person describe this problem in their own words before you mentioned it, or did they only agree it was a problem after you described it to them? Agreement after a leading description is worth far less than a problem they volunteered on their own.
2. Are they already paying a cost to work around it?
Ask what they currently do instead. If the honest answer is "nothing, it's just kind of annoying," that's a vitamin. If they're already spending money, time, or a workaround of their own to deal with it, that's a painkiller. People only build workarounds for problems that actually cost them something.
3. Can they name one specific time it hurt them?
Ask for a date, a dollar amount, or a specific incident. Not "does this happen sometimes" but "when's the last time this actually went wrong for you, and what did it cost." A real pain has a memory attached to it. A theoretical one doesn't.
4. Would they use the fix today, unprompted?
If you handed them the finished thing right now, would they open it and start using it this week without you checking in, reminding them, or walking them through it by hand? If the honest answer requires you to stay involved to keep them using it, the demand isn't there yet. It's borrowed from your effort, not theirs.
5. Would they go looking for another fix if you vanished?
If you disappeared tomorrow, would they actively go find another way to solve this, or would they just quietly go back to how they were doing it before you showed up? A real painkiller leaves a gap when it's gone. A vitamin just gets forgotten.
If you can answer three or more of these with a specific, remembered example rather than a guess, you're looking at a real pain worth building for. If most of your answers are guesses or "probably," you've found a real problem that doesn't have real urgency behind it yet, and that's worth knowing before you spend the next few months on it.
What to Do If It's a Vitamin
Finding out early is the good outcome, not a failure. Skip the build and go back to the people you already talked to with a harder question. What version of this would make them act today, not eventually? Sometimes that means narrowing to a smaller group already in visible pain. Sometimes it means you stop lead-generating for self-serve active users and go set the fix up in person, by hand, for the handful of people who already feel the pain point, because a hand-delivered fix proves demand before software has to.
If you're not sure whether what you're holding right now, a handful of signups, a few interested replies, a "yeah that'd be useful," counts as real signal or just polite interest, that's exactly what The Real Signal Checklist is built to sort out. It ranks what you've already gotten by what it cost the person who gave it, and gives you two tests to run this week instead of guessing. It's free.
FAQ
I already built it. Is it too late to run this test?
No. Go back to the people who have it, or the people you originally interviewed, and ask the five questions about the version that exists now. If most of the answers are guesses, you've learned where to spend your next round of effort. Usually that's distribution to the people who feel the pain most, not more features.
What if only one or two people pass the test, not a whole audience?
That's normal, and it's not a bad sign. One person with a real, remembered, costly version of the problem is worth more than fifty who politely agreed it sounded useful. Go find more people who look like that one person before you assume the market is bigger or smaller than it is.
Isn't "make it free" supposed to remove all the risk?
It removes the financial risk to you, not the adoption risk. The person still has to spend time and trust to try something new, and free doesn't refund either one if it doesn't help them.
How is this different from asking for feedback after I launch?
Feedback after launch tells you what's wrong with something people already agreed to try. This test happens before that, while you can still change course for free. Post-launch feedback assumes people showed up in the first place, and a vitamin usually means they didn't.