The first user interview is the one you keep putting off. You know you should do it. You have read The Mom Test. You have watched at least one Teresa Torres talk on 1.5x. You have told yourself you will start talking to users “after this next ship cycle.” But you open Amplitude instead, because Amplitude never asks a follow-up question, and Amplitude never makes you feel like an intruder.
This piece is for the technical founder of a bootstrapped B2B SaaS product with somewhere between fifty and a thousand users — post-launch, pre-researcher, with no background in interviewing anyone. The goal is not to turn you into a qualitative researcher. It is to get you through your first real user interview without doing three things that would make it useless.
Why your analytics can’t tell you this
You already have a lot of behavioural data. You can see who signed up, who churned, who uses the feature you spent six weeks on. What you cannot see is the reason anyone does any of it. Analytics tell you what happened; they do not tell you why. A funnel diagram cannot tell you that a user bounced because the word “workspace” sounded like it cost money. A retention curve cannot tell you that the three people who renewed last week did so because a colleague recommended a Slack-channel workaround you did not know existed.
Paul Graham made this the defining mandate of the early-stage founder more than a decade ago. In Do Things That Don’t Scale, he observed that the founders of Airbnb, Stripe and Doordash all spent their first months personally recruiting and interviewing users — not because it was efficient, but because nothing else produced the understanding they needed. For a founder with fewer than a thousand users, the bottleneck is almost never engineering throughput; it is whether the thing you are about to build matches the thing a real person needs.
One interview, done properly, can reset a roadmap. Done badly, it can justify the wrong roadmap for a quarter. The difference sits in four decisions that you make before, during, and after the call.
Decide what you are trying to learn
The most common founder mistake is not bad interviewing; it is interviewing without a research question. First Round Review describes this pattern: founders say they have talked to “dozens or hundreds of customers” but end up with little of substance, because they went in without a plan, did not check their biases, and did not think about who they were interviewing and why.
Before you schedule anything, pick one of three focuses. They require different questions and produce different conclusions, so mixing them into one conversation is how you end up with an hour of warm chat and no decisions.
Problem discovery. You want to understand how people currently deal with a problem you believe exists — what they do, how often, what it costs them, what they have already tried. This is the right choice if you are thinking about a new product area or a pivot. The output is a story about a real problem, not a feature request.
Feature feedback. You have shipped something. You want to know whether it fits into a real workflow. The output is a ground-truth description of how real users used the thing, in their own words.
Churn or switching insight. Somebody cancelled, downgraded, or chose a competitor. You want to reconstruct the decision. Bob Moesta, co-creator of Jobs-to-be-Done, puts it cleanly: “The greatest single step you can make is to actually talk to somebody who recently purchased you, and talk to somebody who recently quit you.” The output is the four forces — what pushed them to look, what pulled them to their choice, what held them back, what they gave up.
Pick one. Write down, in a single sentence, the decision this round is meant to inform. If you cannot finish the sentence “After this round, I will be able to decide whether to…”, you are not ready to pick up the phone yet.
Find five people to talk to (and stop there)
The first interview feels heavy partly because you think you need to organise a sample. You do not. You need one participant, then another, then three more.
The folk wisdom that “five users is enough” comes from Jakob Nielsen’s usability work and applies imperfectly to interviews. Nielsen Norman Group is explicit that because interviews surface experiences and needs rather than interface defects, the point of saturation is usually higher than for a usability test, and it depends on how varied your users are. In practice, five to eight interviews is the right size for your first round — small enough to finish in a fortnight, large enough to notice when two people say the same thing.
Three recruiting channels work better than anything else. First, the inbox: email a short, specific note to ten recent sign-ups, paying customers, or churned users. Offer nothing; ask for fifteen minutes. “I’m trying to understand how teams like yours decide what to build next — would you be up for walking me through how you do it?” In an early round, ten specific emails can be enough to get a couple of useful calls.
Second, the product itself. Teresa Torres’s best recruiting trick is to recruit from inside the product flow — a small prompt that asks, in her words, “Do you have 20 minutes to talk with us about your experience?” Once wired up, interviews arrive on your calendar without effort.
Third, the people who just left. Churned users are the most generous participants you will ever recruit, because the pressure to be polite is gone. They also have a story with a shape: they were in, something happened, they are out.
Who not to talk to: friends, investors, people at conferences who say “that’s such a great idea”, and your co-founder’s cousin. Rob Fitzpatrick’s insight in The Mom Test is that these people lie — not maliciously, but socially. You do not need support; you need truth. Talk to the people who would actually pay money if your product did its job.
Write an interview guide in 30 minutes
A guide is not a script. You will not read from it. It is a safety net — something to glance at when you feel yourself drifting into salesperson mode. Nielsen Norman Group recommends a structure of 5–8 primary open-ended questions, each with a handful of follow-up probes for when a participant gives a thin answer.
The structural principle that matters most is the one NN/G calls the funnel technique: broad questions first, narrow ones later. If you ask “what do you think of our pricing page” in the first minute, you have told the participant that your pricing page is the topic. Every later question is now contaminated. Start with “walk me through how you ended up signing up last month” and the pricing page gets mentioned when it genuinely mattered — or not at all, which is a finding in itself.
The workhorse question in founder interviews is not a question. It is a prompt: “Tell me about the last time you [did the thing].” Teresa Torres, who built her story-based interviewing approach around this move, argues it is the only way to get past what people say they do and down to what they actually did. “What do you usually do when you need to schedule a meeting across time zones?” gets a sanitised hypothetical. “Tell me about the last meeting you had to schedule across time zones” gets a story, a tool name, a workaround, and an emotion.
For your first interview, a guide might look like this, with a problem-discovery focus for a product in the project-management space.
Warm-up. Tell me a bit about what you do day to day.
The big open story. Walk me through the last week on your current project — what were you actually doing?
Specific recent event. Tell me about the last time you had to chase someone for a status update. What happened?
Current process. How are you tracking who owes you what right now? What do you use? What do you not use?
Workarounds. What have you tried before that didn’t work for this?
The scary question. Why do you bother with this at all? What happens if you don’t?
Close. Is there anything important about this that I should have asked but didn’t?
The “why do you bother” question is Fitzpatrick’s, and it is the one that distinguishes an annoyance from a paying problem. If the answer is “oh, I just like things to be organised”, the problem is not yours to solve. If the answer is “because the last time I dropped a thread, we missed a deadline and lost a client”, you are somewhere useful.
Run the conversation like a curious stranger
Technical founders tend to struggle here, because an engineering background trains you to close loops, give answers, and correct imprecision. In an interview, you have to do the opposite.
Three rules. First, do not sell. The moment the participant realises you want them to like your product, the quality of the data drops to zero. They switch into polite-stranger mode. Erika Hall’s Just Enough Research makes the underlying point plainly: neutrality is a practised skill, and it is easy to let your own opinion leak into the room. If you cannot trust yourself to stay neutral about your own product, ask somebody else to run those calls.
Second, do not ask hypotheticals. “Would you use a feature that did X?” feels reasonable and is the most reliably misleading question in interviewing. People are terrible forecasters of their own behaviour, and they want to be kind. The Mom Test’s three rules — talk about their life instead of your idea, ask about specifics in the past instead of generics or opinions about the future, talk less and listen more — all point at the same trap. Swap the hypothetical for a past-tense version: “Have you ever tried to do something like X? Walk me through it.”
Third, do not lead. NN/G has a whole article on leading questions, and the examples are ones you catch yourself writing by accident: “How much do you like our onboarding?” (assumes they like it), “Don’t you think it’s a bit slow?” (assumes it is slow), “What do you think of our beautiful new dashboard?” (assumes a feeling). Strip the assumption: “What was the sign-up experience like?”, “Tell me about the performance”, “Open the dashboard and walk me through what you notice.”
And then, most difficult of all, let there be silence. Steve Portigal devotes a good chunk of Interviewing Users to this: after a participant finishes a thought, do not fill the gap. Count to four. People will often keep talking, and the second thing they say is usually closer to the real story than the first.
Two small moves worth stealing. When someone says something vague, reflect it back and let them correct you: “So you mostly use spreadsheets because Jira was too heavy for your team — is that right?” They will either agree or say “no, it’s more like…” and give you the real version. And when someone tells you something critical, lean in rather than defend: “Tell me more about that.” Indi Young calls this posture a “listening session” — the interviewer’s job is to absorb, not to convert.
Make sense of what you heard
The hour on the call is worth very little if you do not process it within 24 hours. Memory for the specifics decays fast, and the difference between “I think she said Jira” and a verbatim quote is the difference between anecdote and evidence.
Record every call with permission, and if you can, get a transcript. A recording without a transcript is a recording you will never listen to again. Within the first day, do three things: write a short summary in your own words (three to five sentences), pull out three to five verbatim quotes that struck you, and note one surprise — something you did not expect to hear.
After five interviews, stop and look for patterns. The word “theme” is doing a lot of work here; it just means “something more than one person said”. If two of five people described the same workaround, that is a theme. Three of five in the same words is a stronger one. If you hear something only once, mark it as an outlier and decide whether to probe it in the next round.
You do not need a synthesis method yet. A single shared document, organised by question or theme, with verbatim quotes attached, is fine for your first five conversations. The rigour is in not skipping the step, not in the tooling.
What your first user interview actually changes
The value of the first interview is rarely a feature idea. It is a correction to your internal model of who your users are. You will have assumed, without realising it, that they all think like you — that they know what a webhook is, that they dislike the same competitors, that they find the same workflow obvious. The first interview breaks that assumption. Every interview after that is easier, because “I do not yet know what they’ll say” gets more natural each time.
A bootstrapped SaaS founder has no researcher, no research-agency budget, and limited time. That is the reason to keep each round small, structured, and frequent. Five interviews a month, done properly, is more consistent than many larger product organisations manage. It is also enough to stop you building the wrong thing for six weeks in a row.
If the overhead of five interviews a month is what is stopping you — the scheduling, the moderating, the transcribing, the synthesising — that is what Maren exists for. But the first interview is the one you should run yourself. Listening to a real user tell you, in their own words, that the thing you believed is not quite true, is the experience that makes you a better founder. You cannot skip to the insight.
Start this week. Email three users. Book one call. Write seven questions. Ask the first one. You already know how to listen — you have been doing it in every code review, every pairing session, every incident post-mortem. This is the same skill pointed at a different target.