A tactical, step-by-step guide on how to actually "talk to users" - Part 1
Knowing what to build means actually talking to users.
Software is the cheapest it has ever been to build. That is exactly why so much of it is wrong.
You can describe a product over coffee and have a working prototype by dinner. The constraint that used to protect you, the months of engineering between an idea and a shipped thing, is gone. What is left is a faster path to building something nobody wants. The most expensive mistake in software is no longer a failed launch. It is burning weeks and tokens to build the wrong thing well.
The standard advice for avoiding this is “talk to users.” It is correct and almost useless as advice because nobody explains the part that matters: what to actually say, who to say it to, and what to do with the answers.
This is that part.
The Cheapest Part of Software Is Now the Building
For most of software history, the validation step got skipped because building was the expensive part. You committed to an idea because backing out cost real money. Now the reverse is true. AI coding tools let anyone ship a prototype in an afternoon, so people build first and ask questions never.
“Move fast and break things” assumed iteration was cheap and throwaway work was viable. That logic is under quiet pressure. Token economics are tightening, and the era of unlimited free inference is not permanent. When a company dumps a thousand PowerPoints into an AI to spit out PDFs, somebody is paying for every one of those calls. When building is cheap, the only scarce thing left is being right about what to build. Open-source local models complicate the cost picture, but they do not change the core skill. You still have to know whether the thing is worth building at all.
Here are the full, tactical steps on how to actually talk to users.
Write the Bet Down Before You Write Any Code
Before you build anything, write down the problem you are solving and who you are solving it for. One or two sentences, specific enough that someone could prove you wrong.
Treat that sentence as a null hypothesis. Everything you do next is an attempt to disprove it, not defend it. Do not outsource this step to AI, because the act of writing it yourself is what forces the clarity. Vague ideas never fail, which is precisely why they are worthless: a bet you cannot state in one line is a bet you cannot test. If it takes you a paragraph, you do not understand your own idea yet.
Name Who It’s For, Specifically Enough to Be Wrong
Next comes your ICP, your ideal customer profile: who are the first people who will use and buy this. The trap is staying vague. “HR people” is not an ICP. “HR middle managers at Series C tech companies” is. You can carry two or three of these at once, but treat each as its own hypothesis.
Getting this specific feels limiting, which is why people skip it. It is the opposite of limiting. A name this precise tells you exactly whose calendar to chase, and watching it shift as you learn is how you know the research is working. A target you would be embarrassed to define this narrowly is the only kind worth having. There is a bonus here too. A sharp ICP is durable context you can feed your AI for the rest of the build, long after the interviews are done.
The Interview Guide Is Discovery, Not a Pitch
Write roughly ten questions and aim for thirty to forty minutes per session. This is discovery, not a survey and not a sales call. The fastest way to ruin it is to ask “would you use this,” because people are polite and they will say yes, and you will learn nothing. Ask how they handle the problem today. Ask what is frustrating, what actually works, and which tools they reach for.
The mindset is the hard part. They are the expert and you are the student, which is a brutal flip for working professionals who are used to being the smartest person in the room. Your ego is going to take a beating across this whole process, and that is the job. Being wrong early is not the failure mode, it is the entire point, because finding out now costs you a coffee and finding out later costs you the build.
They are the expert and you are the student
Remove Every Excuse Not to Show Up
Logistics decide whether any of this happens. Put a Calendly or Cal.com link in front of people so booking takes one click instead of a thread. Use Zoom or Google Meet, and record with a transcriber like Granola so you can stay present in the conversation instead of scrambling to take notes. The transcript becomes an asset later, not a chore now.
Then there is the part people are squeamish about: incentives. Someone has to decide to give you their time, and a small payment moves a calendar faster than charm does. A twenty dollar Amazon gift card works, but cash can pull in the wrong participants, the people who show up for the gift card and not the topic. For high-value professionals, a fifty to a hundred dollar donation to a charity on their behalf often works better. It gets a five-hundred-dollar-an-hour expert in the room and keeps the exchange clean. For underserved audiences, a mid-level accountant who rarely gets asked their opinion, the chance to be heard is sometimes enough on its own.
Your earliest interviewees are usually your first customers, so treat them like it: be generous, and offer them free or early access.
Show the Prototype Last, Not First
People cannot react to a description, so at some point you have to show them something. The question is not whether to show a prototype, it is when. Lead with open discussion and no visuals, because you want their unfiltered view before a screen anchors them to your idea. Introduce the visual afterward, and the gap between what they said and how they react to the mockup is where the real signal lives. In a multi-session format, the visuals often belong in session two or three, not session one.
AI is bending this step in a strange direction. Prototypes are now cheap enough to generate live, mid-interview, by feeding the transcribed conversation into a prompt and building against it in real time. That is powerful and dangerous in the same breath.
One strongly opinionated user can steer a live prototype straight off a cliff, which is why patterns matter more than any single voice.
Those patterns start showing up around six to ten interviews, and twenty is usually the ceiling before you are just confirming what you already know.
Being Wrong Early Is the Whole Point
None of this protects you from a bad idea. It protects you from spending six months finding out it was bad. The discipline is simple to say and hard to do: write the bet down, name who it is for, and go looking for the people who will tell you it is wrong before the market tells you for free.
You have defined the bet and named your ICP. The harder problem is next: getting thirty strangers to sit down and be honest with you, when your network only gets you to the first five.
Part 2 - Conducting the interviews - is coming up next.
Subscribe to get it when we publish.
Use This Today
Take whatever you are building right now and write the bet in one sentence: what problem, for whom, specific enough to be proven wrong. Then sharpen the “for whom” until you could name five real people who fit, and put a thirty-minute call with one of them on your calendar this week.
Try This Prompt
You are a product discovery coach. I am going to give you a one-sentence
bet about a product I want to build, in the form "problem, for whom."
Here is my bet: [paste your one-sentence bet]
Do the following, in order:
1. Tell me where my bet is still vague, and rewrite it so it is specific
enough to be proven wrong.
2. Name the riskiest assumption hidden inside it, the one that, if false,
kills the idea.
3. Draft a 10-question discovery interview guide for a 30-minute call.
The questions must uncover how the person solves this problem today,
what frustrates them, and what tools they use. Do not include any
question that asks whether they would use my product.
4. Flag any question I might be tempted to ask that would bias the answer.
If anything about my bet is unclear, ask me one clarifying question at a
time before continuing.
About Us
Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of tase, and improve their craft when building products.
Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.
David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.