How To Talk To Users | Startup School

Business-focused summary (startup user research & MVP discovery)

Why top founders talk to users (and how it changes execution)

• Continuous customer contact throughout the company lifetime keeps founders “honest” because users are the only paying stakeholders.
• Avoid the “build first, ask later” trap—contrasting a movie-like origin story (e.g., The Social Network) with real early execution (e.g., Airbnb).
• Personal, non-anonymous access to founders and customer support drives better learning:
  • Example: Airbnb founders used real phone/email access (not hidden “do-not-reply” channels), so hosts could reach them directly.

Real-world examples / case studies used

• Airbnb (Brian Chesky + founders + first hosts)
  • Chesky and the early team learned from direct conversations with hosts, including early calls from personal cell numbers.
  • Early insight: some guest requests (like host phone numbers) pointed to trust gaps, not straightforward “feature requests.”
• Gmail (Paul Buchheit)
  • Early users asked for inbox + email being readable on the same screen because Gmail felt too slow.
  • These were performance/problem needs, not necessarily “UI feature preference” requests.

---

Framework / playbook: “How to find and interview users”

1) Identify the right people to talk to

• Don’t only interview your network—network users may be easy but can be less honest.
• Sources mentioned for early users / future customers:
  • LinkedIn
  • Reddit communities
  • Slack / Discord
  • In-person events
• For outbound targeting, look for people with domain-relevant titles (e.g., carbon / climate / sustainability roles).

2) How to reach out (example message pattern)

• Outreach approach:
  • Introduce yourself (optionally referencing past shared context, e.g., Airbnb)
  • Briefly say you’re starting a project (minimal detail)
  • Ask for a 20-minute call (phone/video) with a clear, low-friction ask
• Two tone variants:
  • To someone you know (warm reference)
  • To someone you don’t know (more general, still respectful)

3) Conduct the interview (what to do)

• Use phone/video/in-person; emphasize that a 5-minute video interview can yield more insight than hundreds/thousands of “sugar responses.”
• Build rapport first so they feel comfortable sharing candidly.
• Listen more than you talk.
• Don’t introduce your idea too early (or at all), since it can bias answers.
• Take notes or record and transcribe—don’t rely on memory.

4) High-signal questions to ask (examples)

Use open-ended prompts and dive deep:

• “Tell me how you do X today”
• What is the hardest thing about X?
• Why is it hard?
• How often do you have to do X?
• Why is X important to your company?
• What do you do to solve it today for yourself?

Optional “behavior” prompts:

• Ask them to show their laptop/screen (e.g., how they generate a report)
• Have them describe what they’re doing in real time

Follow-up technique guidance:

• “What do you mean by that?”
• “Can you tell me more?”
• “Why is that important to you?”

5) Questions to avoid

• Asking about willingness to buy your product:
  • “Will you use our product?” is usually meaningless.
• Feature-led questioning:
  • “Which features would make product X better?” / “What would a better product look like?”
  • The speaker argues users aren’t responsible for roadmaps; they should describe jobs-to-be-done / problems, not your UI spec.
• Yes/No questions (low signal).
• Double questions (asking two things at once) → confuses interpretation.

Core danger / principle

Don’t optimize for features; optimize for underlying problems. Users may say “add X,” but you need the problem motivation behind X.

---

Turning insights into an MVP (process)

1) Synthesize after ~5–10 interviews

• Organize notes (sticky notes or software).
• Bucket learnings into problem themes and identify what’s “actually the thing that matters most.”
• Produce a testable hypothesis about the likely solution direction.
• Don’t over-intellectualize—start the MVP quickly, but based on accurate info.

2) Validate problem value (before building a lot)

Three concrete checks:

1. Are people paying for adjacent solutions today?
   • Example: assess carbon-emissions PDF/reporting products and their success.
2. Do people already have workable solutions (even if “basic”)?
   • Example: Excel/Google Sheets competitors can be hard to displace unless your product is dramatically better.
3. Can you sell to this audience easily?
   • Selling to startups is often easier than selling to plumbers/contractors, because those teams may not switch tools often.

3) MVP prototype + early testing

• Show something before it’s fully built:
  • clickable prototypes (e.g., Figma/InVision)
  • staged demos via a phone prototype (speaker references earlier YC-style internal testing)
• Key testing instruction:
  • Don’t tell them exactly how to use/solve each screen.
  • Provide a goal (e.g., in Airbnb terms: “try to make a booking/search”), then observe.
• Add an observation layer:
  • Have users speak their mind while interacting.
  • Look for:
    • words they understand vs. don’t
    • misunderstandings about what a screen is for

4) Keep users involved (reduce churn risk in the research loop)

• Suggestion: create a Slack/WhatsApp group with customers:
  • Make them feel special/exclusive
  • Share progress and respond quickly to feedback
  • Build trust by showing you ship new screens rapidly in response
• For some users, this also enables community effects (people enjoy connecting with peers doing similar work).

---

Metrics / KPIs / targets

• No explicit numeric KPIs (revenue, CAC, LTV, churn, growth rates) were stated.
• Time target mentioned:
  • 20-minute calls for outreach / first interviews
• Interview volume mentioned:
  • 5–10 interviews to synthesize learning into hypotheses

---

Presenters / sources

• Gustav (Y Combinator Group Partner) — main presenter.
• Brian Chesky (Airbnb co-founder/CEO) — cited example/source.
• Amal — Airbnb’s very first guest (cited as a real early user).
• Joe and Nate — referenced as early Airbnb founders/team members (names only).
• Paul Buchheit — cited as founder of Gmail (early-user example).
• Brian — appears again as “Brian Chesky” (same person as above).