Most discovery interviews go well and teach nothing. The other person is friendly, agrees the problem is real, says they would use it, and the founder leaves encouraged and no better informed. A great interview has a shape: six questions asked in a fixed order, each with a yes branch and a no branch, ending in an ask for a real commitment, a date to start and terms to start on. Founders tend to stop at the first no. The ones who learn fastest treat every no as the start of a better question.

Who this is for

Founders who are about to talk to a potential customer and want the conversation to change what they know. It goes one level deeper than the customer discovery guide: that one covers the whole process, this one covers the thirty minutes in the room.

The process, in order

1
Draw the tree before you book the call
A discovery conversation is a decision tree, and it helps to draw it. Six questions, left to right. Is this person the customer I think I am building for. Is the problem I am solving one of their top three. Would they pay to have it solved. Are the features I have in mind the right ones. Is this the right price for this bundle of features. And will they actually start, on a date they name, on terms you both write down.
The sixth question is the one the other five are walking toward. Everything before it is said; only the last one costs the other person something, which is why it is the only answer you can really trust.
Each question has a yes and a no. Yes moves you one step to the right. No drops you to a second row of questions that is just as valuable: what are your other problems, why would you not pay that, which features would you want instead, what would have to be true for you to start. That is what makes the conversation problem validation rather than a chat, because every step has an answer you would not like and a plan for what to ask when you get it.
Do not expect to reach the right-hand end in one sitting. With most people the first two questions fill the whole conversation, and that is a good interview.
2
Open as someone learning, not someone selling
The first two minutes decide which conversation you get. Say you are trying to understand how people in their role handle a particular thing, that you are not selling anything today, and that the most useful thing they can do is describe how it really goes. Then stop explaining.
Hold your idea back until the first three questions are answered. The moment they know what you are building, every answer about their problems bends toward it, and the commonest source of leading questions is a founder who has already shown their hand. A customer discovery interview starts with their work. Your product enters at question four, and only if the first three earned it.
3
Question one: are you who I think my customer is?
Start by confirming you are talking to the person you meant to reach. You wrote down an ideal customer profile before the call; now check it against the human in front of you. What do they do, at what kind of company, at what stage, and do they actually live with the situation you care about.
Learn how a decision would get made while you are here. Who feels the problem, who controls the money, and who would have to say yes are often three people, and the user vs buyer vs champion distinction is easiest to learn by asking about the last thing their team bought: how they found it, who approved it, how long it took.
If the answer is no (they are not your customer), the conversation is not wasted. Ask who does have this situation, and what theirs looks like instead. Either you get an introduction or you learn that the profile needs redrawing.
Do this in Lev
Walk in with people who already match your profile on paper. Lev turns your profile into a list of real people who match it, so every conversation starts with someone you meant to reach.
Find people who match your ICP with Lev
4
Question two: is this one of your top three problems?
A problem someone agrees with is not a problem they will act on. The test is whether it ranks: of everything on their plate, is this in the top three. Do not ask it that way first. Ask what is hardest about their work right now and see whether your problem comes up unprompted.
Then get to facts. Opinions about the future are free and unreliable; accounts of the past are specific and checkable. Ask for one real occasion and stay on it: when did this last come up, what did they do, who got pulled in, how long did it take. When an answer turns general, with a usually or an always, bring it back to the last specific time.
The measure of the problem is what they have already spent on it. What have they tried, what do they pay for today, what did they build themselves. That is the painkiller vs vitamin judgment, made from behavior rather than from how warmly they talk about it.
If the answer is no (it is not in their top three), ask what is. You are talking to exactly the kind of person you want to serve, and they are about to tell you what they care about more than your idea.
- What is the hardest part of your work right now?
- Tell me about the last time that happened.
- What did you do next, and who else was involved?
- What have you tried so far to fix it?
- What are you using for this today, and what does it cost you?
5
Question three: would you pay to have it solved?
Ask this once the problem has ranked, and when it has, always ask: whether they could pay, whether they would, and how much. A conversation that goes well and never gets to money has skipped the question that matters most. The strongest evidence of willingness to pay is not a figure they offer, it is money, a tool, or a person's time that already goes to the problem today.
Then put a real number on the table. Say what you expect to charge and watch what happens. A number makes the question concrete in a way that asking whether they would pay something never does.
If the answer is no, ask why not, and ask what they could pay. I cannot afford it, it is not in my budget, and it is not worth that to me are three different answers. Each one teaches you about your own price and your own value, and none of them is available to the founder who hears no and changes the subject.
6
Question four: are these the right features?
This is the first point where you describe what you are building, and you describe it briefly: here are the three things it does. Then ask whether those feel like the right three.
The common answer is some version of not really. Say tell me more, and listen for what they name instead. You came in believing A, B and C mattered most; several conversations later you may find that everyone asks for D and F. That is one of the most valuable things an interview can return, and it only appears if you ask the question in a way that makes it easy to disagree with you.
Treat praise and requests with care here. A compliment tells you the person is kind. A feature request is their guess at a solution, so ask what it would let them do that they cannot do now, and what they did the last time they needed it. That is the working form of jobs to be done: the request is the surface, the job underneath is what you are there to find.
7
Question five: is this the right price for this package?
The fifth question joins the previous two. Name a price for a specific set of features: this much for the first two, this much more with the next two added. Now you are testing pricing and packaging together, which is how the customer will meet them.
Listen for where the line falls. Which features would they pay the lower price for, which would move them to the higher one, and which do they not value at all. Bundling vs. unbundling stops being an abstract choice when three customers in a row draw the line in the same place.
Few conversations get this far, and the answers here are the softest in the tree, because nobody has had to pay yet. Treat them as a draft of your price list, to be confirmed by what people do when you ask for a commitment.
8
Question six: will you start on a set date, on set terms?
Everything before this was talk. The last question asks for a commitment with a shape to it: will you start using this, beginning on a date, on terms we both write down. Not would you be interested, not keep me posted, but a day in the calendar and what each side is agreeing to.
Say the terms out loud, because vagueness is what lets a yes mean nothing. What they get and when, what you need from them, who on their team is involved, how long the arrangement runs, and what it costs, including when the honest answer is nothing for the first month. A design partner arrangement is the usual shape this early, and the act of agreeing to specifics is itself the test. Write it down while you are still in the room and send it the same day.
The answer separates the people who have the problem from the people who were being pleasant about it. An early adopter negotiates: they push the date, ask for a different term, want someone else included. That is a yes with edges on it, and it is the most valuable thing you can leave with. Someone who agrees warmly to all of it and will not name a date has told you the problem is not in their top three after all, whatever they said at question two.
When the pull is strong, ask for the order. Pull is unmistakable once you have felt it: they want to know when, not whether, and they are solving your problems for you. That is the moment to put the whole deal on the table rather than a next meeting: the price, the package, the date you could deploy, and the question that closes it, what, if anything, is standing in the way of a successful, paid deployment. Ask it plainly. The answer is either nothing, in which case you have a customer, or a specific thing you can go and remove.
The founder is the right person to ask it, and the only one who can act on the answer in the same breath. Nobody else in the company can change the price, promise a feature, or move a contract term or a timeline on the spot, and nobody else hears the buying signals as clearly, because the buyer is talking to the person who built it. What you hear in these conversations, which objections are real, which terms move people, what they ask for first, is the sharpest input you will get on what to prioritize.
If the answer is no, ask what would have to be true for them to start. A missing capability, a budget cycle, a person who has to approve, a quarter that is already committed: each is a specific obstacle rather than a verdict, and several people naming the same obstacle is a roadmap.
- What day could you start?
- What would you need from us before then?
- Who else on your team has to be involved?
- How long would we run it before we both decide?
- What happens at the end of that, and what does it cost?
- What, if anything, is standing in the way of a paid deployment?
9
Follow every no
Most founders stop when they hear no. The conversation winds down, they thank the person, and they leave with one bit of information: not this one. The whole bottom row of the tree goes unasked.
Every no has a follow-up that is worth as much as the yes would have been. Not my customer: who is. Not a top problem: what is. Would not pay that: why, and what would you pay. Not those features: which ones. Not that price for that bundle: where would you draw the line. Not ready to start: what would have to be true.
The pattern across many conversations is what matters. One person saying no to your price is an anecdote. Eight people saying no for the same reason is your pricing. A no at the first question, repeated, means the ideal customer profile is wrong, and it is far cheaper to learn that here than after building.
10
Ask for something before you leave
Most conversations never reach question six, and those still need an ending. A meeting that closes on this was great, keep me posted has not told you where you stand. Ask instead for something smaller that still costs them a little: time for a follow-up with a colleague in the room, an introduction to someone with the same problem, or a look at the spreadsheet or the workflow itself.
What they do with the ask is the result of the interview, and it is the check on everything they said about paying. An early adopter says yes to something specific. Someone being polite says they are interested and offers nothing, and it is better to learn that now than after a quarter of follow-ups.
11
After the call: write it up, then add it to the tracker
Record every call, asking permission at the top and getting the yes on the recording, and have it transcribed and summarized the same day, while you can still correct the summary from memory. Memory edits interviews in your favor, and it does it quickly. Keep the summary to what they said in their words, what they have already done or spent, what surprised you, and what they committed to, with your interpretation on a separate line. The surprise line is the one that pays, because it is where a pattern you were not looking for shows up first.
Then mark the tree. How far to the right did this person get, where did the no come, and what did the follow-up return. Ten marked trees side by side show you where people fall off, which is the thing to fix next. If ten interviews in a row all end in a comfortable yes, the questions were too safe, and that is not problem validation.
Last, add a row to your tracker: a column for each attribute in your ideal customer profile, and your honest guess at how likely this person is to be an early adopter. Once a week, read that week's summaries together and write down the thread that keeps coming up: the phrase people repeat, the workaround in every call, the objection you have now heard four times. Review often and change rarely: hold the profile steady for your first ten calls, so you have something to compare against. How Picking an ICP Actually Works covers scoring the tracker and changing the profile; How Customer Discovery Actually Works covers the weekly rhythm this feeds.
Do this in Lev
Lev keeps that tracker for you. Everyone it found and everyone you added sits on one board, moving from contacted to discovery call to interviewed, with your notes on each, and when the pattern says your profile should change, changing it refreshes the people Lev finds next.
Track your interviews in Lev

Where founders get the process wrong

Stopping at the first no. The follow-up question is where the learning is, and it is the one most founders never ask.
Skipping the conversations and starting to build. An engineer can go from idea to writing code in minutes, which is exactly why this step gets skipped and exactly why it matters.
Pitching. Once the idea is on the table the other person is reviewing it, and you have swapped information about their life for an opinion about yours.
Asking about features and price before the problem has ranked. If it is not in their top three, their views on your feature list are politeness.
Asking whether they would pay something, instead of naming a number. A vague question gets a generous answer because it costs nothing to give.
Accepting a general answer. Usually and always are where the facts stop. Ask for the last specific time.
Talking more than they do. If you hold the floor for more than a quarter of the conversation, you ran a presentation.
Hearing a feature request as a requirement. Build from the reason behind it, which they will only give you if you ask.
Leaving without an ask. With no next step requested, a polite meeting and a promising one look identical.
Accepting a warm yes with no date on it. Enthusiasm that will not name a day to start, or the terms to start on, is interest rather than commitment, and question six exists to find that out while you are still in the room.
Reading the calls one at a time and never together. The common thread across five conversations is the finding; any single transcript is an anecdote, however good the quotes in it are.
Bringing a formal script to what should be a conversation. The tree is a map in your head, not a form to read aloud.
Trusting your memory. Notes written the next day record what you hoped to hear.

Related guides

The process, in order

Draw the tree before you book the call

A discovery conversation is a decision tree, and it helps to draw it. Six questions, left to right. Is this person the customer I think I am building for. Is the problem I am solving one of their top three. Would they pay to have it solved. Are the features I have in mind the right ones. Is this the right price for this bundle of features. And will they actually start, on a date they name, on terms you both write down.

The sixth question is the one the other five are walking toward. Everything before it is said; only the last one costs the other person something, which is why it is the only answer you can really trust.

Each question has a yes and a no. Yes moves you one step to the right. No drops you to a second row of questions that is just as valuable: what are your other problems, why would you not pay that, which features would you want instead, what would have to be true for you to start. That is what makes the conversation problem validation rather than a chat, because every step has an answer you would not like and a plan for what to ask when you get it.

Do not expect to reach the right-hand end in one sitting. With most people the first two questions fill the whole conversation, and that is a good interview.

Open as someone learning, not someone selling

The first two minutes decide which conversation you get. Say you are trying to understand how people in their role handle a particular thing, that you are not selling anything today, and that the most useful thing they can do is describe how it really goes. Then stop explaining.

Hold your idea back until the first three questions are answered. The moment they know what you are building, every answer about their problems bends toward it, and the commonest source of leading questions is a founder who has already shown their hand. A customer discovery interview starts with their work. Your product enters at question four, and only if the first three earned it.

Question one: are you who I think my customer is?

Start by confirming you are talking to the person you meant to reach. You wrote down an ideal customer profile before the call; now check it against the human in front of you. What do they do, at what kind of company, at what stage, and do they actually live with the situation you care about.

Learn how a decision would get made while you are here. Who feels the problem, who controls the money, and who would have to say yes are often three people, and the user vs buyer vs champion distinction is easiest to learn by asking about the last thing their team bought: how they found it, who approved it, how long it took.

If the answer is no (they are not your customer), the conversation is not wasted. Ask who does have this situation, and what theirs looks like instead. Either you get an introduction or you learn that the profile needs redrawing.

Do this in Lev

Walk in with people who already match your profile on paper. Lev turns your profile into a list of real people who match it, so every conversation starts with someone you meant to reach.

Find people who match your ICP with Lev

Question two: is this one of your top three problems?

A problem someone agrees with is not a problem they will act on. The test is whether it ranks: of everything on their plate, is this in the top three. Do not ask it that way first. Ask what is hardest about their work right now and see whether your problem comes up unprompted.

Then get to facts. Opinions about the future are free and unreliable; accounts of the past are specific and checkable. Ask for one real occasion and stay on it: when did this last come up, what did they do, who got pulled in, how long did it take. When an answer turns general, with a usually or an always, bring it back to the last specific time.

The measure of the problem is what they have already spent on it. What have they tried, what do they pay for today, what did they build themselves. That is the painkiller vs vitamin judgment, made from behavior rather than from how warmly they talk about it.

If the answer is no (it is not in their top three), ask what is. You are talking to exactly the kind of person you want to serve, and they are about to tell you what they care about more than your idea.

What is the hardest part of your work right now?
Tell me about the last time that happened.
What did you do next, and who else was involved?
What have you tried so far to fix it?
What are you using for this today, and what does it cost you?

Question three: would you pay to have it solved?

Ask this once the problem has ranked, and when it has, always ask: whether they could pay, whether they would, and how much. A conversation that goes well and never gets to money has skipped the question that matters most. The strongest evidence of willingness to pay is not a figure they offer, it is money, a tool, or a person's time that already goes to the problem today.

Then put a real number on the table. Say what you expect to charge and watch what happens. A number makes the question concrete in a way that asking whether they would pay something never does.

If the answer is no, ask why not, and ask what they could pay. I cannot afford it, it is not in my budget, and it is not worth that to me are three different answers. Each one teaches you about your own price and your own value, and none of them is available to the founder who hears no and changes the subject.

Question four: are these the right features?

This is the first point where you describe what you are building, and you describe it briefly: here are the three things it does. Then ask whether those feel like the right three.

The common answer is some version of not really. Say tell me more, and listen for what they name instead. You came in believing A, B and C mattered most; several conversations later you may find that everyone asks for D and F. That is one of the most valuable things an interview can return, and it only appears if you ask the question in a way that makes it easy to disagree with you.

Treat praise and requests with care here. A compliment tells you the person is kind. A feature request is their guess at a solution, so ask what it would let them do that they cannot do now, and what they did the last time they needed it. That is the working form of jobs to be done: the request is the surface, the job underneath is what you are there to find.

Question five: is this the right price for this package?

The fifth question joins the previous two. Name a price for a specific set of features: this much for the first two, this much more with the next two added. Now you are testing pricing and packaging together, which is how the customer will meet them.

Listen for where the line falls. Which features would they pay the lower price for, which would move them to the higher one, and which do they not value at all. Bundling vs. unbundling stops being an abstract choice when three customers in a row draw the line in the same place.

Few conversations get this far, and the answers here are the softest in the tree, because nobody has had to pay yet. Treat them as a draft of your price list, to be confirmed by what people do when you ask for a commitment.

Question six: will you start on a set date, on set terms?

Everything before this was talk. The last question asks for a commitment with a shape to it: will you start using this, beginning on a date, on terms we both write down. Not would you be interested, not keep me posted, but a day in the calendar and what each side is agreeing to.

Say the terms out loud, because vagueness is what lets a yes mean nothing. What they get and when, what you need from them, who on their team is involved, how long the arrangement runs, and what it costs, including when the honest answer is nothing for the first month. A design partner arrangement is the usual shape this early, and the act of agreeing to specifics is itself the test. Write it down while you are still in the room and send it the same day.

The answer separates the people who have the problem from the people who were being pleasant about it. An early adopter negotiates: they push the date, ask for a different term, want someone else included. That is a yes with edges on it, and it is the most valuable thing you can leave with. Someone who agrees warmly to all of it and will not name a date has told you the problem is not in their top three after all, whatever they said at question two.

When the pull is strong, ask for the order. Pull is unmistakable once you have felt it: they want to know when, not whether, and they are solving your problems for you. That is the moment to put the whole deal on the table rather than a next meeting: the price, the package, the date you could deploy, and the question that closes it, what, if anything, is standing in the way of a successful, paid deployment. Ask it plainly. The answer is either nothing, in which case you have a customer, or a specific thing you can go and remove.

The founder is the right person to ask it, and the only one who can act on the answer in the same breath. Nobody else in the company can change the price, promise a feature, or move a contract term or a timeline on the spot, and nobody else hears the buying signals as clearly, because the buyer is talking to the person who built it. What you hear in these conversations, which objections are real, which terms move people, what they ask for first, is the sharpest input you will get on what to prioritize.

If the answer is no, ask what would have to be true for them to start. A missing capability, a budget cycle, a person who has to approve, a quarter that is already committed: each is a specific obstacle rather than a verdict, and several people naming the same obstacle is a roadmap.

What day could you start?
What would you need from us before then?
Who else on your team has to be involved?
How long would we run it before we both decide?
What happens at the end of that, and what does it cost?
What, if anything, is standing in the way of a paid deployment?

Follow every no

Most founders stop when they hear no. The conversation winds down, they thank the person, and they leave with one bit of information: not this one. The whole bottom row of the tree goes unasked.

Every no has a follow-up that is worth as much as the yes would have been. Not my customer: who is. Not a top problem: what is. Would not pay that: why, and what would you pay. Not those features: which ones. Not that price for that bundle: where would you draw the line. Not ready to start: what would have to be true.

The pattern across many conversations is what matters. One person saying no to your price is an anecdote. Eight people saying no for the same reason is your pricing. A no at the first question, repeated, means the ideal customer profile is wrong, and it is far cheaper to learn that here than after building.

Ask for something before you leave

Most conversations never reach question six, and those still need an ending. A meeting that closes on this was great, keep me posted has not told you where you stand. Ask instead for something smaller that still costs them a little: time for a follow-up with a colleague in the room, an introduction to someone with the same problem, or a look at the spreadsheet or the workflow itself.

What they do with the ask is the result of the interview, and it is the check on everything they said about paying. An early adopter says yes to something specific. Someone being polite says they are interested and offers nothing, and it is better to learn that now than after a quarter of follow-ups.

After the call: write it up, then add it to the tracker

Record every call, asking permission at the top and getting the yes on the recording, and have it transcribed and summarized the same day, while you can still correct the summary from memory. Memory edits interviews in your favor, and it does it quickly. Keep the summary to what they said in their words, what they have already done or spent, what surprised you, and what they committed to, with your interpretation on a separate line. The surprise line is the one that pays, because it is where a pattern you were not looking for shows up first.

Then mark the tree. How far to the right did this person get, where did the no come, and what did the follow-up return. Ten marked trees side by side show you where people fall off, which is the thing to fix next. If ten interviews in a row all end in a comfortable yes, the questions were too safe, and that is not problem validation.

Last, add a row to your tracker: a column for each attribute in your ideal customer profile, and your honest guess at how likely this person is to be an early adopter. Once a week, read that week's summaries together and write down the thread that keeps coming up: the phrase people repeat, the workaround in every call, the objection you have now heard four times. Review often and change rarely: hold the profile steady for your first ten calls, so you have something to compare against. How Picking an ICP Actually Works covers scoring the tracker and changing the profile; How Customer Discovery Actually Works covers the weekly rhythm this feeds.

Do this in Lev

Lev keeps that tracker for you. Everyone it found and everyone you added sits on one board, moving from contacted to discovery call to interviewed, with your notes on each, and when the pattern says your profile should change, changing it refreshes the people Lev finds next.

Track your interviews in Lev

Where founders get the process wrong

Stopping at the first no. The follow-up question is where the learning is, and it is the one most founders never ask.
Skipping the conversations and starting to build. An engineer can go from idea to writing code in minutes, which is exactly why this step gets skipped and exactly why it matters.
Pitching. Once the idea is on the table the other person is reviewing it, and you have swapped information about their life for an opinion about yours.
Asking about features and price before the problem has ranked. If it is not in their top three, their views on your feature list are politeness.
Asking whether they would pay something, instead of naming a number. A vague question gets a generous answer because it costs nothing to give.
Accepting a general answer. Usually and always are where the facts stop. Ask for the last specific time.
Talking more than they do. If you hold the floor for more than a quarter of the conversation, you ran a presentation.
Hearing a feature request as a requirement. Build from the reason behind it, which they will only give you if you ask.
Leaving without an ask. With no next step requested, a polite meeting and a promising one look identical.
Accepting a warm yes with no date on it. Enthusiasm that will not name a day to start, or the terms to start on, is interest rather than commitment, and question six exists to find that out while you are still in the room.
Reading the calls one at a time and never together. The common thread across five conversations is the finding; any single transcript is an anecdote, however good the quotes in it are.
Bringing a formal script to what should be a conversation. The tree is a map in your head, not a form to read aloud.
Trusting your memory. Notes written the next day record what you hoped to hear.

How a Great Customer Discovery Interview Actually Works

The process, in order

Draw the tree before you book the call

Open as someone learning, not someone selling

Question one: are you who I think my customer is?

Question two: is this one of your top three problems?

Question three: would you pay to have it solved?

Question four: are these the right features?

Question five: is this the right price for this package?

Question six: will you start on a set date, on set terms?

Follow every no

Ask for something before you leave

After the call: write it up, then add it to the tracker

Where founders get the process wrong

Further reading

Related guides

Not seeing what you need?

Stop looking these up one at a time

How a Great Customer Discovery Interview Actually Works

The process, in order

Draw the tree before you book the call

Open as someone learning, not someone selling

Question one: are you who I think my customer is?

Question two: is this one of your top three problems?

Question three: would you pay to have it solved?

Question four: are these the right features?

Question five: is this the right price for this package?

Question six: will you start on a set date, on set terms?

Follow every no

Ask for something before you leave

After the call: write it up, then add it to the tracker

Where founders get the process wrong

Further reading

Related guides

Not seeing what you need?

Stop looking these up one at a time