Last semester, I ran two idea validation sprints — each targeting a different problem I'd observed on campus. The first was a scheduling tool for student organizations. The second was a peer skill-exchange platform. One had real demand. One didn't. The process that helped me figure out which was which: 14 carefully structured customer conversations.
This isn't a post about the ideas — one is still in development, one is dead. It's a post about the process, because I found a repeatable approach that cuts through a lot of the noise that usually surrounds "market research."
Why most early-stage research fails
The most common mistake is asking people if they would use your product. The answer is almost always yes. People are polite. They don't want to disappoint you. They're also bad at predicting their own behavior, especially for hypothetical products they've never seen.
Mom Test principle, for those unfamiliar: never ask your mom (or anyone) if they like your idea. Ask about their life. The signal is in behavior and past experience, not in hypothetical preference. "Would you use an app that did X?" is a bad question. "Walk me through the last time you tried to solve X" is a good one.
The other failure mode: confirmation bias. You go in hoping to hear that your idea is great. You emphasize questions that make it easy for people to say yes. You discount the no signals because they're uncomfortable. Customer research that confirms a bad idea is more dangerous than doing no research at all — it gives you false confidence.
The script I used
I structured each conversation around four questions, with follow-ups that varied by response:
1. "Tell me about the last time you experienced [the problem domain]."
Not "do you have this problem" — "tell me about the last time." This forces specificity. Vague answers ("yeah, I guess it's sometimes annoying") are signal. Detailed, animated stories ("oh god, last Tuesday I spent two hours on this and still didn't solve it") are signal too — but much stronger signal.
2. "What did you do about it?"
The response tells you what existing solutions they already use or considered. If they already have a satisfactory workaround, your product is competing with that workaround, not with the raw problem. Also: if they did nothing, that's data. Severity of pain correlates with how much effort they put into solving it.
3. "What was the most frustrating part of that experience?"
This surfaces the specific pain points, not the general category of pain. You're looking for the crack in the current solution — the thing your product might specifically address. You're also listening for emotion. Frustration and intensity of language predict willingness to pay and willingness to change behavior.
4. "If this problem were magically solved, what would that be worth to you?"
Not "what would you pay for a product that did X." Magic solution, no implementation details. This separates pain intensity from price anchoring. You can always talk price later. First you need to know if the problem is worth solving from their perspective.
What I learned from the scheduling tool interviews
I interviewed 7 student organization leaders. Five of them gave me detailed, specific stories about scheduling conflicts, availability coordination, and calendar chaos. They were using spreadsheets, group chats, and Doodle polls — none satisfactorily. Two of them had built their own systems (a spreadsheet plus a form) that were failing as their org scaled.
Strong signal: real problem, inadequate existing solutions, specific and emotional stories.
I also asked: "Have you ever paid for any tool that helped with organization management?" Three of the five said yes — one was paying for Notion Pro, one had used Eventbrite for ticketing. Demonstrated willingness to pay for adjacent tools is a strong proxy for willingness to pay in this space.
What I learned from the skill-exchange interviews
I interviewed 7 students who I thought had diverse skill sets and had expressed interest in learning new things. The conversations were polite, even enthusiastic about the concept. But here's what I noticed:
- Only 2 could recall a specific time they had sought out peer skill-exchange
- When asked what they did about skill gaps, most said "watched YouTube" or "asked a friend"
- None had paid for any peer learning tool
- The most common response to "what would a magic solution be worth": "I'd probably use it if it were free"
Classic pain that isn't really pain. The problem domain (learning new skills) is real, but the intensity of pain around peer exchange specifically was low. People had satisfactory substitutes. There was no crack to wedge into.
The decision rule I used
After each round of 7 interviews, I used a simple scoring rubric:
- Specificity of stories: Could they describe a real recent instance? (0–2)
- Effort spent on existing solutions: Did they try to fix it themselves? (0–2)
- Emotional intensity: Were they frustrated, animated, genuinely bothered? (0–2)
- Adjacent payment history: Have they paid for anything in this domain? (0–2)
Max score: 8. Scheduling tool average: 6.1. Skill-exchange average: 2.7.
Not a scientific instrument. But a structured way to compare signals across conversations without letting enthusiasm cloud judgment.
What 14 conversations can and can't tell you
Fourteen conversations can tell you whether the problem is real and whether pain is high enough to motivate behavior change. They cannot tell you whether your specific solution is the right one, what features to prioritize, or what price will work. Those questions require different methods: prototype testing, landing page experiments, willingness-to-pay surveys.
But they can save you months of building the wrong thing. That's the point. Validate the problem before you validate the solution. Most founders do it in reverse — they build something, then try to find the market. The 14-conversation sprint is a forcing function to do it right.