The 5 questions every founder should ask their first 20 users

You have 87 signups, 23 weekly active users, and a neat activation chart. What you do not have is the story behind the numbers.

Why did one user go looking for a product like yours? What made the old way intolerable? Why did another user sign up, open one screen, and disappear?

Your first users can answer those questions while their decisions are still recent. The advantage is temporary. As Paul Graham argues in Do Things that Don’t Scale, early-stage founders can recruit and learn from users one by one in a way that becomes harder as the company grows.

This guide gives you five questions to ask your first users, the follow-ups that make each question useful, and a simple way to learn across 20 conversations. The sequence comes from Eric Migicovsky’s Y Combinator lecture on how to talk to users. It is short enough to keep beside you during a call and broad enough to work for most early B2B products.

The rule behind all five questions

Ask about what happened, not what might happen.

Teresa Torres distinguishes between a research question and an interview question. Your research question might be, “Why do trials stall during setup?” Asking that directly invites the participant to produce a tidy explanation. A better interview question asks for a specific story: “Tell me about the last time you tried to set this up.”

That shift matters because general answers are unreliable. Nielsen Norman Group warns that people often describe an idealised workflow when asked what they usually do. It recommends asking about specific critical incidents to recover the details, shortcuts, and failures that summaries leave out.

The same principle sits at the heart of The Mom Test for founders: talk about the participant’s life, stay with past specifics, and listen more than you explain.

The five-question user interview script

Use the bracketed phrase to name the job your product helps with: preparing client reports, onboarding a teammate, reconciling invoices, or whatever the participant was trying to accomplish.

Do not rush through the list. A good answer to question two may take most of the conversation. The guide is a route through the story, not a questionnaire you must complete.

Question 1: What’s the hardest part about [doing the job]?

Ask about the job, not your product.

If you built an uptime monitor, do not ask, “What’s the hardest part of our alerting?” Ask, “What’s the hardest part of responding when a client-facing service goes down?” The first question keeps the participant inside your interface. The second gives them room to tell you that the hardest part is explaining the incident to a non-technical client.

That difference can change the problem you solve. Better alert routing and a client-ready status update are two different roadmaps.

Useful follow-ups:

• “Which part is most unpredictable?”
• “Who else gets involved?”
• “What tends to go wrong?”
• “How often does that happen?”

Treat the answer as a doorway, not a finding. “Reporting is frustrating” is still a summary. Your next job is to locate a real instance.

Question 2: Tell me about the last time that happened

This is the question that turns an interview into evidence.

Suppose the participant says onboarding a client is painful. Ask them to reconstruct the most recent onboarding:

• What started it?
• What did they do first?
• Which tools did they open?
• Where did they pause or ask for help?
• What happened next?

Stay chronological. If they jump to a conclusion — “the permissions are confusing” — return to the scene: “What were you trying to give them access to? What did you click? What did they see?”

Bob Moesta’s Jobs-to-be-Done interviews use this kind of reconstruction to understand the progress behind a switch. His interview with Intercom emphasises actions over opinions: what someone did, stopped doing, or chose instead tells you more than whether they say they like a product.

For a deeper version of the timeline, use Maren’s Jobs-to-be-Done interview guide.

Question 3: Why was that hard?

The visible problem and the expensive problem are often different.

“The export took too long” describes friction. “I missed the reporting deadline and had to explain it to a client” describes the consequence. One suggests a performance improvement. The other tells you why speed matters and who feels the cost.

Keep asking for consequence without interrogating the participant:

• “What did that mean for the rest of the task?”
• “What happened because of the delay?”
• “How did you work around it?”
• “Who noticed?”

Do not assume every inconvenience is urgent. A problem may be frequent but harmless, or rare but costly. You are trying to understand the combination of frequency, consequence, and effort already spent.

This is also where useful positioning language appears. “Automated reporting” is a feature description. “Send the board pack without rebuilding the numbers on Sunday” is a reason to care. Keep the participant’s exact wording in your notes, with permission to record when appropriate.

Question 4: What, if anything, have you done to solve it?

The phrase if anything matters. It gives the participant permission to say they did nothing.

That answer is useful. If a problem sounds severe but the participant has never searched for a tool, changed a workflow, built a spreadsheet, asked a colleague, or allocated budget, the problem may not be urgent enough to drive action. That is a signal to investigate, not proof that no market exists.

When action has happened, map it carefully:

• Which products did they compare?
• What manual workaround did they create?
• How much time or money did they spend?
• Who approved the decision?
• What are they still using today?

Your real competitor may be a spreadsheet, a weekly Slack reminder, a contractor, or acceptance that the task will remain painful. Do not limit the conversation to the companies on your competitor slide.

For an early product, prior action is usually stronger evidence than enthusiasm. “I spent two Fridays building a workaround” tells you more than “I would probably pay for that.”

Question 5: What don’t you love about the solutions you’ve tried?

Now you can discuss alternatives without asking the participant to design your product.

Suppose they tried a competitor and disliked its exports. Do not jump to “What export feature should we build?” Ask what they were trying to do, what the export produced, and what they had to do next. The useful requirement lives in the failure, not in the adjective.

Try these follow-ups:

• “Can you show me what you mean?”
• “What did you expect to happen?”
• “What did you do instead?”
• “What do you tolerate because the rest of the solution is useful?”

The final question is about trade-offs. Every current solution has them. A participant may accept weak reporting because migration feels risky, or pay more because procurement has already approved the vendor. A feature list misses those constraints. A story exposes them.

Two useful post-launch questions

Once the five-question sequence is complete, two additional questions can help if the participant has already chosen and used your product.

What almost stopped you from signing up?

This asks about a hesitation they actually experienced. It can reveal missing security information, unclear pricing, migration anxiety, or an internal approval step.

Follow with “What helped you continue?” and “Who else was involved?” Avoid turning “What would have made it easier?” into a promise about future behaviour. Use the answer to locate the real objection, then verify it with other participants and behaviour.

How would you feel if you could no longer use this product?

Sean Ellis’s product-market-fit survey asks users whether they would be very disappointed, somewhat disappointed, or not disappointed if they could no longer use a product. Rahul Vohra’s Superhuman case study describes the 40% “very disappointed” benchmark and notes that results begin to become directionally useful at around 40 respondents.

With only 20 answers, one person moves the score by five percentage points. Do not declare product-market fit from that number. Ask the question for the follow-up: “What would you miss most, and why?” The explanation can reveal the product’s core value in the user’s own language. Run the formal survey separately when you have enough qualified users.

How to run the first 20 conversations

Twenty is a practical cadence, not a universal sample-size rule. The goal is to learn, adjust, and compare — not to hit a number and declare the research complete.

Before conversation one

Write down:

1. The decision this research should inform.
2. The type of user whose experience is relevant.
3. What you currently believe.
4. What evidence would make you less confident.

Then recruit across meaningful states. If you only interview your most active users, you will mostly learn why active users stay. Include people who reached value, stalled during setup, used the product once, or chose another approach where your research question requires those perspectives.

Conversations 1–5: improve the guide

Listen for questions participants misunderstand and places where you accidentally lead them. Do not rewrite the guide around the most colourful story. Make small changes that help participants reach specifics.

Migicovsky’s YC lecture recommends starting with a small number of conversations and improving your method as you learn. That is more useful than booking 20 identical calls before you know whether the guide works.

Conversations 6–15: compare patterns

Use the same core questions so the stories are comparable. After each call, capture:

Keep contradictions. They often show that you have mixed two segments or two different jobs.

Conversations 16–20: test the pattern

Use the final conversations to look for cases that do not fit your emerging explanation. If you think buyers switch because reporting takes too long, deliberately recruit someone who reports frequently but has not looked for an alternative. Their story can reveal a missing condition.

Christina Cacioppo describes a useful practitioner heuristic in First Round’s account of Vanta’s path to product-market fit: keep talking until much of the next conversation is predictable. Treat that as a sign of growing understanding, not a statistical stopping rule. If conversation 20 still produces entirely new triggers, your segment may be too broad or your guide may still be shallow.

Turn 20 interviews into findings

Put all participants on one surface. Group similar triggers, consequences, workarounds, and trade-offs. For every theme, keep a list of the participants and evidence that support it. Do not convert one memorable quote into a pattern.

Then write findings in a form that can guide a decision:

Six of 15 trial users tried to invite a colleague before connecting data. Four abandoned setup when the colleague could not see the empty workspace.

That is more useful than “collaboration is important” because it names the group, behaviour, moment, and consequence.

Maren’s guide to synthesising user interviews into themes shows the full workflow, including coding, clustering, negative cases, and traceable evidence.

Questions to leave out

NN/g calls one reason these questions fail the query effect: people can form an opinion when asked, even about something they had not previously considered important. A confident answer is not necessarily a stable preference.

If you hear a hypothetical, bring the participant back gently: “Can you tell me about the last time that happened?”

Keep the founder in learning mode

Steve Portigal’s interview guidance is a useful final check: set aside your own view, try to understand the participant’s view, build rapport, and listen. The interview stops producing clean evidence when you explain the roadmap, correct the participant, or defend a design choice.

You can still be warm. Warmth means paying attention, not agreeing with every answer.

If time or founder presence makes these conversations difficult, Maren can run the same adaptive research guide asynchronously, ask follow-ups, and synthesise themes across interviews. You still choose the participants, define the research decision, and review the evidence. Maren handles the repeated conversations without turning them into a fixed questionnaire.

Start with one person. Ask what is hardest. Find the last real example. Stay with the story long enough to understand what it cost, what they tried, and why the current answer still falls short. Then do it again until your view of the problem belongs as much to your users as it does to you.