Seven User Interviews That Flipped My Core Assumptions: A Lean Validation Framework for Small Teams

Don't Let 'Users Say They Want It' Fool You

A few years ago I built an AI writing assistant. The first two months were pure guesswork. I listed a dozen features, convinced each was a must-have. When the prototype was ready, I showed it to friends. They all said "great" or "useful." I was confident until month three, when I finally dragged a stranger at a café for a 20‑minute chat. That single talk overturned my three most prized assumptions.

Since then I've made it a rule: before writing the first line of code, run at least three rounds of user interviews, 2–3 people each, no more than ten total. It's not a statistically significant sample, but it's enough to expose blind spots. And these interviews aren't casual chats about "which color do you like." They are systematic hypothesis tests.

Interviews Are Bets, Not Chats

Most small teams skip interviews because they think they can't afford time/money, or they believe "I'm in this industry, I know the user." That's usually an illusion. The gap between what users actually do and what you think they do is wide. Projects that skip this step often launch only to discover nobody cares about the problem they solved.

My approach is to write product hypotheses as "If … then …" statements. For example: "If users spend 20 minutes daily manually summarizing meeting notes, then an auto‑summary tool will be considered essential." Then I take that bet to people, not to prove myself right, but to find evidence that could disprove it.

Three Preparation Steps

1. List Your Three Most Uncertain Hypotheses

Don't write trivial things like "users go online." Focus on what core value depends on and what you're least sure about. For instance:

• Users will pay for this feature. (Not "might" – give a concrete price range.)
• Users encounter this pain point at least three times a week.
• Users have already tried other solutions (including manual workarounds) and are dissatisfied.

2. Find 'Cold‑Start' Users in Your Target Audience

Avoid friends, colleagues, or existing users. They're too polite. Go to industry forums or communities and look for people who have the background problem but no connection to you. Conditions: they don't know you, aren't in your circle, but face the problem you want to solve. When I built a language learning app, I specifically sought out beginners in Russian learning groups — anxious, hadn't bought any course yet. They were the most honest.

3. Design a Guided Conversation Script

Not a questionnaire. A flow. I usually structure it like this:

• Background: What's been the most annoying part of your day/week? (Don't mention your product.)
• Current solutions: What have you tried? Why didn't it stick?
• Then show an extremely crude demo: a sketch on paper, a low‑fi prototype, or even just a one‑page description. Don't call it a 'product.' Say 'I'm looking at this problem – could you give me your take on this idea?'
• Finally ask about willingness to pay: If this cost you a cup of coffee per month, would you buy? What about a meal?

Traps to Avoid During Interviews

• Avoid 'Do you think …' – it invites fabricated answers. Replace with 'When did you last encounter X? What did you do?'
• Don't explain the product logic. Once users feel you're selling, they'll lie to be polite.
• Never argue. If a user says 'I don't need this,' nod, take notes, then ask 'Can you give me an example?' That's more valuable than any defense.
• Keep each interview under 20 minutes. After that, attention drops and information quality plummets.

How to Extract Decision Signals from Notes

After three rounds, I have piles of notes. My simplest method: put each hypothesis on a separate sheet; list supporting evidence on one side and refuting evidence on the other. If refuting outweighs supporting, or if supporting comes only from obviously biased answers, drop or adjust the hypothesis.

One counter‑intuitive point: If a user says 'I'd pay for that' when asked directly, that's almost useless. Real signals are users who ask 'Can I use it now?' or 'How do I buy?' Another strong signal is when they add you on WeChat voluntarily after the call, asking when it'll launch. Passive agreement is not a signal; active action is.

How Assumptions Shifted – A Concrete Example

Imagine my AI writing assistant was supposed to 'auto‑generate marketing copy.' In the first round I interviewed three small business owners. Two said 'I write it myself; I don't have time to learn a new tool.' The third said 'I need custom templates – the generic output isn't good enough.' This flipped two assumptions: 1) Writing itself isn't the biggest pain point (it does take time), but editing to fit is more painful; 2) Pure generation isn't enough – editable templates are required. I pivoted from pure generation to 'semi‑generation + template library.' The second round of interviews confirmed this direction.

I used zero analytics tools, just seven interviews (three in round one, two in round two, two in round three) to change the core direction. If I had started coding right away, I'd have wasted at least two months.

When Is Enough? When to Continue?

There is no magic number. My rule of thumb:

• If after three rounds you still can't pinpoint the core pain, you've either recruited the wrong people or the problem definition itself is flawed. Go back to rewriting hypotheses.
• If most users behave as you predicted and at least 2–3 show strong action signals (asking to buy, proactively referring), you're good enough.
• Never wait for 'statistical significance' before deciding. A small team's time is money. It's better to move with 70% confidence and iterate than to wait for 95% confidence while the market is taken.

Final Thoughts

User interviews should not be a one‑time task; they become a recurring beat in product iteration. Whenever a major feature or direction change is on the table, run two‑three rounds of interviews. The cost is low, and the payoff could save months of development.

The tools don't matter: your phone's recorder, a notebook, a quiet café. What matters is having the courage to hear uncomfortable feedback and the ability to shift from 'proving yourself right' to 'finding where you're wrong.'

PaxLee