How to talk to users: a practical guide for early-stage founders

Executive overview

Most founders avoid direct user contact, hiding behind no-reply emails and scalable growth tactics. The founders who build enduring companies do the opposite — they speak to users before they have a product and never stop.

This talk gives a repeatable process for finding users, running interviews, and translating what you learn into an MVP.

The best founders treat user conversations as a permanent competitive advantage, not a one-time research task.

Why user conversations matter

• Users are the only stakeholders paying you — they will tell you the truth
• Great founders learn directly from users throughout the life of the company
• Brian Chesky lived in 50 Airbnbs to get honest host feedback at scale
• Chesky and Joe Gebbia shared their personal cell numbers with hosts from day one — radical transparency, not anonymous support

Finding users to interview

• Start with your network: most likely to respond, but may soften feedback to avoid offence
• Former coworkers: often know the problem domain well
• Outside your network: LinkedIn, Reddit, Slack/Discord communities, in-person events
• Search for job titles that signal relevance (e.g. "sustainability", "carbon", "climate")

Running the interview

• Always use video, phone, or in-person — a 5-minute call beats 5,000 survey responses
• Build rapport first; interviewees will answer questions no one has asked them before
• Do not introduce your idea until the end — or not at all — to avoid biasing answers
• Your role is to listen, not to pitch
• Ask open-ended follow-ups: "Tell me about that", "What do you mean by that?", "Why is that important to you?"
• Record or take detailed notes; you will need to translate recordings to notes anyway

Questions to ask

1. Tell me how you do X today
2. What is the hardest thing about doing X?
3. Why is it hard?
4. How often do you have to do X?
5. Why is it important for your company to do X?
6. What do you do to solve this problem today?

If possible, watch them do it — screen share, show their workflow, show the actual output.

Questions to avoid

• "Will you use our product?" — answers are meaningless
• "Which features would make this better?" — that is your job, not theirs
• Yes/no questions — push for concrete examples
• "How would a better version look?" — users are not product designers
• Two questions at once — confuses both them and your notes

Interpreting what users tell you

• Users have good problems but generally bad solutions
• Gmail users asked to see inbox and email simultaneously — the real problem was slow load times, not layout
• Early Airbnb guests wanted host phone numbers — the real problem was insufficient trust signals
• Users will say yes to every feature request; you must decide what matters
• Focus the interview on understanding problems, not generating solutions — that is a separate exercise

Turning interviews into an MVP

• After 5–10 interviews, use sticky notes or similar tools to bucket problems by theme
• Write down conclusions: what did you actually learn?
• Form a hypothesis about the solution, then design the MVP as fast as possible
• Test the prototype with the same users — even an InVision clickthrough works
• Hand them the device, give them a goal, and do not tell them what to do; just watch
• Ask them to think aloud — reveals which words, screens, and steps confuse them

Evaluating whether the problem is worth solving

• Are people already paying for imperfect solutions in this space? Existing spend signals real value.
• Do users have solutions they are happy with (e.g. Excel)? You need to be dramatically better.
• How easy is this audience to sell to? Plumbers and contractors rarely switch tools; startups do.

Keeping users involved after interviews

• Create a Slack or WhatsApp group with early interviewees
• Make them feel they have exclusive access to something world-changing
• Ship updates in response to their feedback — builds trust fast
• Facilitate connections between users; they rarely meet peers doing the same job