One question that reveals real demand
A question I’ve started asking earlier in projects:
“If this didn’t exist, what would people do instead?”
If the answer is
“nothing” or “they’d just tolerate it”
that’s a warning.
If the answer is
“we hacked together a spreadsheet, script, or ugly workaround”
that’s real demand.
Features are easy to imagine.
Workarounds are harder to fake.
This is the "hair on fire" diagnostic. The spreadsheet-script-ugly-workaround answer is gold because it reveals two things at once: the problem is painful enough to warrant effort, AND people haven't found a good enough solution to stop hacking.
The "nothing/tolerate it" answer is tricky though - sometimes that means low demand, but sometimes it means the pain is so normalized people don't even recognize it as fixable. I've seen products succeed by making people aware of problems they'd been tolerating unconsciously.
One variation I've found useful: "What are you doing right now to solve this?" Present tense forces honesty. Future tense ("what would you do") lets people imagine solutions they'd never actually build.
What's the clearest workaround signal you've seen that later turned into a real product?
This is a great way to frame it. I especially like the present-tense question it cuts through hypothetical answers fast.
I’ve seen the “ugly but working” workaround show up a lot in design and ops: people duplicating Figma files endlessly, naming layers inconsistently, or maintaining side docs just to keep layouts aligned. It’s not elegant, but it ships which is exactly the signal.
The normalized-pain point is interesting too. Some problems don’t feel urgent until someone reframes them as solvable.
Curious have you noticed cases where awareness alone unlocked demand, even before a strong solution existed?
Yes - awareness unlocking demand before solutions is a real pattern. I've seen it happen when someone articulates a problem in a way that suddenly makes it feel fixable rather than just "how things are."
The Figma example is perfect. Nobody thought "I wish I had a design system tool" - they thought "copying frames is annoying but manageable." Then tools like Figma's components (and others) showed what organized design could look like, and suddenly the messy workarounds felt intolerable.
The reframe often comes from:
The tricky part: awareness without a solution can create frustration rather than demand. Timing matters - you want to name the problem right when a viable solution is ready, not before.
This is such a sharp way to frame it. The “fixable vs inevitable” shift really resonates once people can see the problem clearly, the workaround stops feeling acceptable.
The timing point is important too. I’ve noticed that naming the problem too early can actually backfire it just creates frustration. But when a viable solution exists, that same awareness suddenly turns into pull.
It’s made me think less about pushing solutions and more about helping people recognize the hidden cost of what they’re already tolerating. When that clicks, the demand almost takes care of itself.
Exactly - "helping people recognize the hidden cost" is the real skill. Most founders default to pushing features, but the better play is surfacing the pain that's already there.
The shift from "pushing solutions" to "illuminating costs" is subtle but powerful. When you quantify the workaround ("you're spending 4 hours/week on this"), you're not selling - you're just making the invisible visible. The decision to buy becomes obvious instead of persuasive.
This thread is a good example of how validation thinking evolves: start with "is there demand?" → refine to "is there painful-enough demand?" → land on "can I make the pain visible enough that demand creates itself?"
That last question is the hard one. Most of us skip it and go straight to building.
That framing really clicks. Making the invisible visible changes the whole dynamic it stops being about convincing and starts being about clarity.
I like how you laid out that progression too. Most of the mistakes I’ve seen (and made) come from jumping straight to “can we build this?” instead of sitting with “is this pain actually sharp enough yet?”
When the cost is clear, the decision feels obvious. When it’s fuzzy, building just becomes a way to avoid the harder thinking.
Nailed it - "building as a way to avoid the harder thinking" is one of those uncomfortable truths. It feels like progress but can actually be procrastination with extra steps.
The progression you described (is there demand → is it painful enough → can I make pain visible) is basically the difference between founders who validate once and founders who keep validating as they go. The last question never stops being relevant.
This has been a good thread. Appreciate the back-and-forth - these exchanges are where the real thinking sharpens.
Appreciate that. You’re right validation isn’t a phase you “finish,” it’s a posture you keep. The moment it stops feeling relevant is usually when drift starts.
Well said. "Validation as posture" is the mindset shift that separates builders who stay relevant from those who drift into building for its own sake.
The drift usually happens slowly - you stop asking "is this still solving the right problem?" and start asking "how do I ship this faster?" Both feel productive, but only one keeps you honest.
Good thread. These conversations are where the real calibration happens.
That distinction really stuck with me. Speed is seductive because it’s measurable, but relevance requires constant checking in with reality. Staying in that “is this still the right problem?” mode feels slower, but it’s probably the only way to avoid drifting. Appreciate the thoughtful back-and-forth here.