Last month a product designer showed me her new prototype. She’d spent two weeks vibe-coding a tool for tracking “gratitude journaling streaks.” The interface was beautiful. Confetti animations for seven-day streaks. Gentle notifications.
Then she showed it to users.
“I don’t really journal,” said the first one.
“Gratitude journaling felt performative,” said the second.
“What’s a streak?”
She’d spent two weeks building the wrong thing and was about to spend more weeks building another thing that might also be wrong. She called this process “need-finding.”
It wasn’t.
The Difference Matters
Need-finding happens before you have a solution. You’re listening to people describe their lives, their frustrations, their workarounds. You’re hunting for problems that actually exist—problems people care enough about that they’re already trying to solve them with spreadsheets and sticky notes and whatever else they’ve cobbled together.
Validation happens after you have a hypothesis. You’re testing whether your specific solution addresses a known problem.
Showing someone a finished prototype and watching them shrug isn’t research. It’s a slow, expensive way to discover you guessed wrong. And when they shrug, you don’t learn what problem to solve instead. You just learn this guess was wrong.
Why Vibe-Coding Makes This Worse
I get it. Vibe-coding is fun. You describe what you want, code appears, and building feels like progress.
That satisfaction is a trap. You’re accumulating artifacts that may have nothing to do with what anyone needs.
The actual fast path is unsexy: sit down with five to ten people. Ask them about their lives. Shut up and listen. Use those three magic words—”tell me more”—every time something interesting surfaces. Don’t show them anything. Don’t pitch. Just listen.
Then, once you’ve heard the same frustration from multiple people, once you understand the workarounds they’re already using—then start building. You’ll build less. It’ll be the right thing.
What Good Interviewing Looks Like
The core skill: treat an interview as a conversation, not a survey.
The instinct is to write down questions and march through them. But the magic happens in follow-up. When someone says “No, I don’t use any task management software,” you don’t move on. You say: “Tell me more?”
Then you might learn they tried three tools and abandoned all of them. Or they’ve built an elaborate system in Google Docs because nothing else fit. In that follow-up, entire universes of insight live.
The best resource I know for learning this properly is Observing the User Experience by Elizabeth Goodman, Mike Kuniavsky, and Andrea Moed. It’ll teach you how to listen without leading, how to find the real problem hiding behind the stated one.
The Right Problem Is Specific
“Finding the right problem” gets thrown around without definition. Here’s what it actually means:
- For UX: A problem people care about enough that they’re already seeking solutions
- For product: A problem people care about enough to pay to have solved
- For business: A problem that enough people have, that your company can actually solve, that fits your brand and capabilities
A problem that meets all three is rare. That’s why finding one is worth spending time on before you start building.
The vibe-coded prototype might be delightful. But if it solves a problem nobody has, or one people won’t pay to fix, or one that doesn’t fit your company—it doesn’t matter how fast you built it.