The Talk-to-Users Playbook. Seven interview frameworks from the people who wrote the books.

Eric Migicovsky founded Pebble and now teaches the canonical Y Combinator guide on how to talk to users, and the whole method starts before the product exists: first find out if the problem is even real. The questions that get you there are about the user's life, not your idea. Tell me how you do this today. What is the hardest part about it.

When did it last go wrong. The pitfalls are exactly the questions founders love most. Leading questions that fish for a yes, feature questions that ask would you use this, yes-or-no questions, and the worst one, asking the user to design your solution. Their job is to describe the problem in their own words.

The moment you hand them the solution, you have stopped learning and started selling, and the signal goes dark.

Bob Moesta co-created Jobs to Be Done, and his core move is to interview the switch instead of the wish. People do not buy products, they hire them to make progress, and the only way to see that progress is to study someone who actually moved. Moesta maps four forces on every switch: the push of the struggling moment they were in, the pull of the new thing, the anxiety of changing, and the habit of staying put. For a customer to switch, push plus pull has to outweigh anxiety plus habit.

Stated preference cannot show you any of that. He recommends interviewing people who recently made a switch and reconstructing the causal story, even borrowing techniques from criminal interrogation to get past the polished surface answer to what really happened.

Teresa Torres wrote the book on continuous discovery, and her interviewing rule is blunt: collect specific stories about past behavior, never ask hypotheticals. The question would you use this invites a polite lie. The question tell me about the last time you faced this gets you a real timeline you can mine. She runs interviews with curiosity rather than a rigid script, following the user's actual experience instead of marching through a list of questions, because the deep insight almost always lives in a detail the shallow, question-heavy protocol would have skipped past.

The discipline is not the question list. It is refusing to accept an answer about the imagined future when a story about the real past is sitting right there.

Michael Margolis runs user research at GV and has watched founders burn months arguing about who the customer even is. His fix is a recruiting-and-interviewing system that turns discovery into something a team can run in a day. Write a screener and recruit five or six real participants through a platform built for it, rather than grabbing whoever is convenient. Interview with humble inquiry and genuine curiosity, anchored on past behavior over predictions.

Then the part most teams skip: the watch party. Get the whole team observing the same interviews live, and have everyone write down predictions beforehand. The predictions surface the team's hidden biases, and watching the same person fail to care ends the internal debate on its own, because everyone saw it at once.

Gustaf Alströmer scaled growth at Airbnb before becoming a YC partner, and the trap he watches founders fall into is their own certainty. On day one you believe you understand the problem, the customer, and the solution completely. You have to, he says, overconfident foolishness is part of starting anything ambitious. The error is staying there.

The founders who learn the most flip fast, from we have it figured out to maybe we know nothing, and then go talk to people. The lesson underneath the Airbnb, Brex, and Twitch examples he walks through is the same: founders overweight money and complex dashboards when the real unlock is reducing the layers between themselves and the customer. Care about them directly, and the learning accelerates.

Judd Antin ran research at Airbnb and Meta, and he is the contrarian in this lineup. He pushes back on the tropes from both sides. Research is not too slow to matter, and PMs cannot simply do it all themselves in their spare time, but he also refuses to pretend intuition is worthless. Good research validates or challenges a product instinct, it does not replace it.

He even debunks the famous Henry Ford faster-horses quote and the everything-is-obvious-in-hindsight bias that founders use to dismiss talking to users. The takeaway is not to worship interviews or to worship your gut. It is to hold a real intuition, then run the interviews specifically to try to break it, and keep it only if it survives.

Oji Udezue helped build Typeform and Calendly, and his frame raises the bar on what you are even listening for. Genuine, durable growth comes from solving a sharp problem, a pain a customer feels deeply, not a vague nice-to-have that earns a shrug. That is why continuous customer discovery is not optional for him: you weave customer conversations into the daily workflow of the product team, listening constantly to reduce friction and find the sharp edge. A vague problem produces vague interviews and a product nobody talks about.

A sharp problem is the thing word of mouth actually carries, the way Slack spread, so the job of talking to users is to keep cutting until the problem you hear is unmistakably sharp.