TL;DR: Using low-fidelity UX prototypes during customer discovery interviews forces people to react to reality instead of abstract ideas. A product discovery UX session is not about rating a design. It uses a prototype to get customers talking about how they solved their problems in the past. It also forces you to clarify what you are building. You only need enough design to give the customer something concrete to react to — a low-fidelity prototype is fine.
What is product discovery UX?
Product discovery UX uses early design mockups and prototypes to uncover real customer behaviors. It helps clarify your product's value before you write any code. Rather than asking users to imagine a solution, you provide a tangible artifact. This grounds the conversation in their actual workflows and past decisions.
What to ask instead of 'what do you think?'
Most founders ask the wrong discovery interview questions when they show a prototype. They ask for opinions, which forces polite lies instead of actionable insight.
When you ask people to judge a screen, they will try to be helpful. They will give you feedback on the design. You do not want to study their perception of your screens, and you definitely do not want to study hypotheticals like "would you use this?"
Instead, use the prototype as a prompt to understand their past behavior. This draws on the core idea from The Mom Test — you must ask about specific past actions rather than future promises. When you do this right, you walk out of the room with a clear mental model of the customer. This shift in questioning is a crucial part of any product discovery framework for B2B.
Questions that produce polite lies vs. questions that produce behavior
Polite Lies (Do Not Ask) | Behavior (Ask These Instead) |
|---|---|
"What do you think of this feature?" | "How did you solve this problem last time?" |
"Would you use this product?" | "Can you show me the tool you use for this today?" |
"Does this workflow make sense?" | "Where did this step fit into your day yesterday?" |
"Do you like the way this looks?" | "What was the hardest part about doing this manually?" |
Prototyping Clarifies the Product
Before you even show a screen to a user, making the prototype forces a decision. Applying principles from NNGroup User Interviews 101 helps you evaluate ideas early on. The discipline of prototyping makes you clarify what the product should be. When you start assembling the pieces, you quickly realize if you are thinking about the problem wrong. That realization happens before any user sees the mockups.
AI tools now make it easy to write code quickly. This means it is faster than ever to build things people do not need. Prototyping prevents you from building cheap features — like a dark theme — when you should be fixing the most painful problem. Keeping the scope tight is critical when deciding how to build a minimum viable product (MVP) in B2B.
Practical framework: How to run a prototype-driven discovery interview
To make a prototype customer interview useful, control the environment and the questions. Here is a decision rule to follow when validating an idea with a prototype:
Tell the customer you are trying to understand their workflow. You are not testing a finished app. They need to know this so they focus on their own tasks rather than your design skills.
Watch them navigate. Ask them to complete a task using the prototype. Observe where they click and where they pause. Steve Blank Customer Development principles rely on watching behavior over listening to opinions.
Ask about the past. When they hesitate, ask: "How did you handle this specific step the last time you had to do it?"
Ignore feature requests. If they say, "It would be great if it did X," ask them how often they currently do X and how they manage it today.
Look for the failure cost. If the prototype shows a nonstandard workflow or edge case, check how often users actually hit that case. Find out how costly the failure is. Do not assume a demo reaction proves a market.
The goal at this stage is deep understanding of the customer's context, workflow, and team. It is not about impressing them. Once you validate the core workflows, you can transition from research to onboarding. Go where the first alpha customers are, invite them, and onboard them manually to watch them get actual value. This process is intentionally not scalable at this stage.
FAQ
How much design do I need before a discovery interview?
You only need a basic, low-fidelity prototype. The goal is to give the customer something concrete to react to so they can talk about their actual workflows. You do not need to show them a polished final product.
Should I show a prototype in a first discovery call?
Yes, if it helps ground the conversation in reality. A rough prototype can prevent the discussion from drifting into abstract hypotheticals.
Does showing a prototype bias the feedback?
It only biases the feedback if you ask the wrong questions. If you ask for their opinion on the prototype, you will get polite lies. The questioning method — focusing on their past behavior rather than their thoughts on the design — is what prevents bias. The artifact itself does not cause bias.
If I put a rough prototype in front of someone, won't they just tell me they like it?
Yes, if you ask for their opinion, you will get polite lies. The prototype is not there to be rated. Use the screen as a prompt to dig into their past behavior and understand why they acted that way.
Why prototype at all when AI can just build the app?
Prototyping earns its keep because it forces you to clarify the product vision before you write code. You start assembling it and realize you were thinking about it wrong. That matters more now because AI makes it very fast to build things people don't want.
