How to Run User Interviews That Guide Products

TL;DR

Effective user interviews begin with carefully choosing people who can reveal the target market’s real problems. Ask about their current behavior, workflows, priorities, and pain points instead of pitching features or requesting speculative opinions. Compare patterns across user groups, then validate promising solutions with prototypes, lightweight implementations, or the money test before investing heavily in development.

Transcript

All right, good afternoon. Today's guest speaker is >> Hello. talk about how to do great Thank you very much for >> Contact server knows where right out of college we, started this company called well, it, it went, all right. We, we, we built it we sold that's not necessarily, the We learned a lot, we learned a During the period of time, So that wa... Read More

Key Insights

• Selecting interview participants is a product decision because different groups provide fundamentally different feedback. Founders should use judgment to identify target users, list several relevant participant types, and determine where each group can be found before beginning interviews.
• Current behavior is more informative than abstract feature preferences. Questions about which tools people use, how they complete tasks, when they revisit their work, and what frustrates them expose genuine workflows without encouraging participants to endorse an imagined product.
• User interviews are designed to reveal problems and goals, not to collect a feature specification. Participants may describe desired functions, but founders must interpret those requests and identify the underlying obstacle that a useful product or experiment should address.
• Feature-first interviewing can create a horseless-carriage effect because participants respond within the boundaries of an existing solution. Beginning with a proposed feature can distract both parties from discovering whether the underlying problem matters enough to justify building anything.
• Repeated patterns across participants strengthen interview findings. A single conversation can generate useful hypotheses, but comparing groups and observing whether the same pain appears repeatedly helps distinguish meaningful needs from preferences unique to one person.
• Prototype validation is useful when a proposed workflow can be drawn or demonstrated before full development. However, favorable reactions are weak evidence because people may call an idea useful and still decide that switching products requires too much effort.
• The money test is a strong measure of commitment because stated enthusiasm does not necessarily predict action. Asking whether someone will pay, or otherwise testing a meaningful commitment, helps reveal whether the perceived value is sufficient to change behavior.
• Twitch’s research separated active broadcasters, broadcasters using competing services, and people who had considered broadcasting. Their feedback exposed different priorities and barriers, allowing the team to focus on problems that affected adoption rather than simply reproducing every requested feature.

Questions & Answers

Q: How should a startup choose people for user interviews?

A startup should begin by deciding which people can provide the most relevant information about the target market. It should identify several participant types and determine where each group can be found. For a lecture-focused note-taking product, relevant groups could include students from different subjects, college IT staff, professors, and parents, because each group sees different workflows, constraints, and purchasing considerations.

Q: What questions should you ask during a user interview?

Ask participants what they currently do, which tools they use, how their workflow operates, when they return to previous work, what they share with others, and where they experience difficulty. The lecture’s note-taking interview asks about pen and paper, Google Docs, Evernote, combining other people’s notes, reviewing notes later, and the purpose served by taking them.

Q: Why should user interviews focus on problems instead of features?

Problem-focused interviews leave room to discover what actually blocks users from achieving a goal. Feature-focused questions can constrain the conversation to a proposed implementation and encourage polite approval. A participant may request a function without caring enough to adopt it. Founders therefore need to interpret feature suggestions as clues, identify the underlying pain, and decide whether solving it would change behavior.

Q: How can founders avoid leading users during interviews?

Founders can avoid leading participants by asking about concrete past and present behavior before describing a solution. They should invite detailed accounts of existing tools, routines, frustrations, and goals, then ask follow-up questions about important moments. Keeping a favored feature out of the opening discussion reduces the risk that participants merely react to the founder’s framing or try to provide agreeable answers.

Q: How many user interviews are needed to find useful patterns?

The lecture does not prescribe a universal interview count. It describes talking to many people, notes that a set of roughly eight participants can often reveal useful information, and describes Twitch research involving about twelve to fifteen people. The practical objective is to compare participants and determine whether important pains and goals recur, rather than treating any single interview as decisive.

Q: How can a startup validate an idea before building the full product?

A startup can draw the proposed workflow, show it to relevant users, and ask how it fits their existing behavior. When possible, it can also create a lightweight implementation, such as a browser extension, to test the crucial function without rebuilding an entire product. These methods provide stronger evidence than discussion alone because participants can respond to something closer to actual use.

Q: What is the money test in product validation?

The money test asks whether a participant will make a meaningful financial commitment instead of merely saying that an idea sounds useful. The lecture presents it as a powerful test because people can appear enthusiastic during an interview without caring enough to switch products or act. Willingness to pay supplies clearer evidence that the proposed solution addresses a sufficiently valuable problem.

Q: What did Twitch learn by interviewing different broadcaster groups?

Twitch compared existing Justin.tv broadcasters, people broadcasting through competitors, and people who had considered broadcasting but had not started. Active broadcasters discussed issues such as moderation and audience interaction. Competitor users emphasized areas including video stability, while prospective broadcasters described barriers such as computer performance, software, training, and other practical requirements that prevented them from beginning.

Summary & Key Takeaways

• Early startup work should focus on building the product and talking to users. Interviews provide information that usage data alone cannot supply, especially the reasons behind behavior, the problems users experience, and the goals they pursue. Their value depends heavily on identifying the right target users and finding where those people can be reached.

• Strong interviews investigate what people currently do. The note-taking example explores tools, sharing practices, collaboration, later retrieval, and the personal value of taking notes without immediately proposing a product. This approach helps founders uncover workflows and obstacles before narrowing their attention to a particular feature or reproducing an existing tool with minor additions.

• Interview findings should guide experiments rather than automatically dictate features. The Twitch research compared existing broadcasters, competitor broadcasters, and people who had considered broadcasting. Those groups revealed different concerns, including moderation, interaction, video stability, computer performance, software, and training. The team addressed important barriers and checked demand through prototypes, practical tests, and commitment.