Discovery that
proves something

Steve Blank defines a startup as a temporary organization designed to search for a repeatable and scalable business model, and the definition only does its work when you set it beside its opposite: an established company is a permanent organization designed to execute one. Two nearly identical sentences, and the difference determines almost everything about how you should be spending your week: searching.

If you are executing, the answers are already inside your building. You know who the customer is, what they pay, how they buy, and which channel reaches them, so the job is to run the play faster and cheaper than you ran it last quarter. If you are searching, none of that is settled. You have a set of beliefs, written down in a deck, about people you have not met. What you call a plan is a stack of guesses.

Blank learned this the hard way, and so did I a few times over for some damn reason. Ninety days into his job at Ardent, sitting in a system planning meeting, he offered an opinion about what customers would want from the graphics subsystem. His CEO threw him out of the room, out of the building, and told him not to come back until he could report something the engineers did not already know. The lessons Blank took from it have outlived the company: an intelligent opinion is still a guess, the person holding a fact beats anyone holding an opinion, and there are no facts inside the building.

The consequence of ignoring it is not that you build slowly. It is that you build confidently in a direction nobody asked for, and you find out after launch, when none of the targets land because the thing you shipped is relevant to nobody. Blank’s argument is that the biggest risk in a startup was never technical: companies die from a missing customer and a missing business model, not from a missing product. Plenty of dead companies shipped on time.

That argument carries more weight now than when he made it. Inside an AI-native company, where writing software has become close to a commodity, the constraint moves almost entirely to knowing what to build, why it should exist, and who receives the value when it does. When building is cheap you get elaborate products that solve nothing, made for no better reason than that they were easy to make.

Blank calls it Customer Development. We call the first phase customer discovery.

His model runs in four steps. Customer discovery puts the founders in front of real customers to test hypotheses and understand problems. Customer validation builds a sales model that repeats and scales. Customer creation drives end user demand into that model. Company building converts an organization designed for learning into one designed for execution. Everything in this guide lives inside step one, which is both the cheapest step and the one founders are most likely to hand wave rather than do.

Discovery is not feedback collection. You are testing beliefs you already hold, not gathering suggestions from people who have never seen your product and have no reason to be right about it. Nor is it a feature request queue: customers are precise about problems and unreliable about solutions, so take the problem and leave the specification alone.

It is also not delegable, and this is the one that quietly kills companies. Blank’s critique of the traditional model is that it hands validation of the founders’ own hypotheses to the sales and marketing team. The modern upgrade is worse: a fractional CRO or a GTM consultant who carries neither accountability for the outcome nor the intellectual honesty required to properly build what is a critical table stake of your company. Either way, the people whose beliefs are being tested never hear the results directly. Someone else sits through the conversation where a customer explains why this is unsellable, summarizes it into a slide, and the summary arrives softened. If you outsource discovery you outsource the only mechanism you have for changing your mind.

Finally, it is not linear. Blank draws the model as a loop with recursive arrows because you will be wrong more than once, and the wrongness is the process working. Founders who expect a straight line treat each correction as a crisis and start looking for someone to blame.

One thing to settle before you start. Blank’s concept of Market Type changes what you are listening for. In an existing market, customers can name the category and rank the features that matter, so your discovery has to cover incumbents in real detail: what they charge, how they distribute, how they create demand, where they are weak. In a new market nobody can name the category yet, and what you are excavating is a workaround that has no product name attached to it, assembled out of spreadsheets and someone’s patience. The method is the same in both cases.

Here is the reframe that fixes most bad discovery calls, and it has nothing to do with which questions you ask.

You are following a lead. A reporting lead, not a sales lead.

A reporter with a lead does not know the story yet, which is the entire reason to go. They know roughly where something interesting might be, they go find out, and the piece they file is frequently not the piece they expected to file. A reporter who arrives with the headline already written and spends the day collecting quotes to support it has produced propaganda.

Your discovery call works the same way. You are there to find out what the story is, and if you already know, you have wasted a stranger’s afternoon and corrupted your own data at the same time.

The mechanism is worth understanding, since founders who understand it stop needing willpower to obey the rule. If you are holding your pitch in your head waiting for an opening, it leaks into everything: your follow-up questions narrow, you stop asking about the parts of their world that do not touch your product, and you start hearing confirmation in sentences that were not confirmation. Justin Wilcox describes the second half of the problem, which most founders never consider at all. The person across the table picks up on what you are hoping to hear, and because they are a decent person who agreed to help you, they help. They become your unwitting accomplice, feeding you exactly the validation you came for and pointing you somewhere expensive.

The cruelty of it is that you cannot separate the help from the signal afterward. The transcript looks identical either way. The only fix is to never generate it.

Journalism supplies the collection framework too. The five Ws transfer almost directly.

You assemble this across a set of conversations rather than inside any single one. The arc is a verdict instrument. Across enough conversations it answers three questions.

Is the problem big enough? What and Where give you scope. A problem contained inside one person’s job is a different problem from one sitting on a handoff between three teams and an outside vendor. Both get described with feeling. Only one has a budget behind it.

Is it urgent? When and How answer this. A weekly problem with a workaround attached to it is urgent. A weekly problem with nothing attached to it is a topic.

Will anyone pay? Who and Why get you there: who owns the problem, who funds the fix, and why an organization full of competent people has allowed this to persist. That last question is the most useful one in the set and the one least likely to get asked, because the answer is usually uncomfortable and tends to be political.

There is a failure state worth learning to recognize early. The Ws come back, but they never come back the same way twice: five conversations produce five different Whos, the How is different every time or missing entirely, and no vocabulary repeats. You have not failed at interviewing. You are either talking to more than one segment, or you have not found the problem yet. Narrow the segment and go again.

The opposite failure is more seductive, and it hits founders with limited sales experience hardest, because nothing in their background has taught them to distrust a good conversation. You get on a call with somebody who uses your vocabulary, has clearly read about the space, follows every point you make, and is excellent company for thirty minutes. You come off that call lit up. The arc looks complete, because they answered every W fluently and did it in language you recognized.

That feeling is not nothing, and you should not talk yourself out of it. Sometimes the person who lights you up on call four is the one who becomes your first design partner, and the instinct that made you excited was picking up something real. Keep the call. Just refuse to let it count until it clears the same bar every other call has to clear.

Three things have to hold. Fluency is not among them.

• They have the problem inside their own operation, right now. Not in their industry generally, and not at the company they worked at before this one.
• They are doing something about it today. There is a workaround with a cost, a tool, or a person’s name attached to it.
• The specifics repeat. The same problem, described in roughly the same language, by people you have not met yet.

The trap is that being well read on a problem space produces almost exactly the same conversational texture as owning the problem. Both people are articulate. Both use the vocabulary correctly. Both will say the problem is significant and mean it. Only one of them has a budget, and the tell is never in how well they talk. A thoughtful commentator can describe your market more clearly than most of your actual buyers can, and will never purchase anything, because nothing in their week is broken.

So when you catch yourself doing revenue math after one great conversation, treat that impulse as the signal it is. Not that you found something. That you found something worth going to check.

Founders produce elaborate reasons they cannot find people to interview. The reasons are articulate, frequently structural, and occasionally sound as though they were researched. They are still excuses, and the way to see it is to look at what you are actually asking for.

Thirty minutes. No money, no commitment, no procurement, no security review, no legal. You are asking a stranger to talk about their own problems, which is a subject most people enjoy and rarely get an attentive audience for.

This is the cheapest rehearsal for distribution you will ever get, and the muscle you build here is the same one you will need later at a much higher price. Founders who skip it do not avoid the difficulty; they defer it to the moment when the difficulty is attached to a revenue number.

The list is the experiment. A sloppy list produces a sloppy arc, and you will spend a month blaming your questions for a problem that was upstream of the call.

Write the segment down before you open a search tool, and write down three things: the firmographics that actually vary the problem, the role that owns it inside their org chart rather than inside yours, and the evidence you can observe from outside that this specific person is already dealing with it. That third criterion is what separates a list of people who ought to care from a list of people who demonstrably do. Wilcox calls it an externally observable behavior: something visible to an outsider that indicates someone is actively looking for a way out. A job posting. A conference talk. A tool showing up in their stack. A complaint made in public.

If you cannot hand the criteria to somebody else and have them rebuild the same list, you do not have a segment. You have a vibe.

What follows is my process. It is not the only way and it may not be the right one for you. You can source targets somewhere else entirely or go full cold email if that is where you are comfortable.

I use Sales Navigator for two reasons. The first is that I do not want to spend three weeks warming up mailboxes before I am allowed to talk to anybody. The second is that it lets me spend social equity I already have: when my message lands in someone’s inbox they can see who we know in common, and that shared context does more for a reply rate than any subject line I could write.

Run it in waves.

That advantage decays as you move away from your own network, so I structure outreach in waves and let the degree of connection do the segmenting early on. The first wave is first-degree connections, people who already know me and for whom saying yes costs almost nothing. The second is second-degree connections in greater Seattle, my geography and my ecosystem, where the connection we share is usually somebody real rather than an artifact of the algorithm, and where being visibly part of the same startup community shows up in the reply rate. The third wave goes beyond my network entirely, and at that point the degree of connection has stopped filtering anything. You are doing ordinary outbound, and everything below has to carry the message on its own.

Build the account list first.

Before you touch a filter, have your ICP written down. Then open the accounts object and set the firmographic boundary: industry, headcount, revenue.

Then add headcount growth of at least 10% in a specific function or department, choosing the function that owns the problem you solve. What you are looking for is expenditure already moving toward your problem area in the form of people. A company hiring into that function has decided the problem is worth spending money on, which is the workaround signal from a discovery call, visible from outside before you have spoken to anybody.

Save the list and name it so you can still parse it in three months. Mine combines company size, revenue band, and the date I built it. Choose a convention now, because cohorts stack up faster than you expect and an unnamed list is one you will end up rebuilding. I cap each account list at 500.

Then move to leads.

In the leads object, bring your saved account list in as the first filter. Everything after that applies ICP criteria to people instead of companies: current job title most of the time, and geography when your market has a shape that makes it useful.

I keep lead-level result sets under 2,500 to stay compliant with the terms of service. Anything above that will likely get you in trouble.

When a search comes back at 8,000 the reflex is to loosen the ICP definition until the list feels workable, and that is backwards. Tighten instead. Location filters are the cleanest instrument for it: if you know where your buyers concentrate, name those metros and drop the rest. Protect the ICP definition and cut somewhere else. The list gets smaller and more coherent, and you find out where your market actually sits.

Track which filters produced which list. This gets messy quickly, and a list you cannot reconstruct is a result you cannot reason about later.

Getting the list out.

Once the lead search is filtered down and you are happy with it, the thing you actually need is the URL of that search. Sales Navigator will hold the result set for you, but a saved search inside Sales Navigator is not a list you can work with. Copy the full URL and run it through PhantomBuster, which walks the search and extracts the leads into something you can enrich, sequence, and track.

I do not touch PhantomBuster directly. Their MCP is a native integration in Atlas, so what I do is tell Atlas to go build the list. Atlas knows which search to run, knows PhantomBuster is the tool for it, and handles the extraction without me opening another tab or configuring anything. The extraction is PhantomBuster’s work, start to finish.

Once PhantomBuster finishes the extraction, Atlas takes the results and adds them to the lead object inside Atlas and to the company’s memory. From there it preps the data for enrichment, which is the next step in the curation process.

The first pass is disqualification. I run the extracted list through an LLM carrying logic I built against our competitive matrix, looking for keywords and company properties that suggest a collision course with what we are building, whether that collision is happening now, coming soon, or somewhere further out.

You can reproduce the general version of it easily enough. Fill in the brackets below, run it against your extraction output, and keep the ones marked KEEP.

The prompt defaults to KEEP. A competitor who slips through costs you one awkward call, and you will find out inside two minutes. A prospect wrongly dropped never shows up again and you never learn you lost them. The confidence rating exists for the same reason, so you can review the low-confidence rows yourself rather than trusting the whole pass.

Sales Navigator gives you a name, a title, a company, and a one-line headline. That is nowhere near enough to know whether the person is worth a connection request.

What is missing is everything topical. Recent news about the company. Funding, and how recently. What they actually build, in their own words. The movements that tell you whether this company is in a moment where your problem is live for them. Navigator does not carry any of it, and those are the properties I most want before deciding a company is a real target.

Any enrichment source will do this. Clay and Apollo are both fine. We use Apollo, and like PhantomBuster it is integrated into Atlas, so by this point Atlas already knows enrichment is the next step, knows Apollo is the tool for it, and runs our strategy inside Apollo without me directing it.

Run the cheap filters before the expensive ones.

Every stage costs more than the one before it, so the ordering is where the savings are.

A row that fails on title should never reach a paid enrichment call, and a company plainly outside your size band should never reach a model. On a real list this cuts paid volume by more than half before you spend a credit.

Parse. Map the exporter’s columns to a stable shape, split full names into first and last for later personalization, and drop any row without a public profile URL. The profile URL is the join key for everything downstream and the address the outreach tool eventually sends to, so a row without one cannot be enriched and cannot be contacted.

Pre-screen.Before spending anything, throw out what the export’s own text already disqualifies. Seniority first, since title is the deepest single cut in the funnel.

Then a second competitor sweep. You already ran a disqualification pass during curation, but that pass only had names, titles, and headlines to work from, so it caught the obvious cases and nothing else. This one costs nothing and runs against a deny-list you have already built, which makes it worth running again on the same rows.

Then keyword matching against company name, industry, and headline for the company types that are structurally not your buyer.

Precision matters more than recall here, because a drop at this stage has no appeal and no model reviewing it. A sloppy keyword deletes real leads silently and you never find out. When you are unsure about a keyword, leave it out. Let the ambiguous row cost you an enrichment credit and reach the judge. A wasted credit is cheap. A deleted customer is not.

Enrich.Match on the profile URL rather than the company name. Company names in an export are messy, Acme and Acme Inc. and Acme Technologies, and matching on them returns the wrong company often enough to poison everything after it. A people-match lookup keyed on the profile URL returns the person’s current employer, which is also fresher than the export.

If your curation prompt asked about funding, hiring, or roadmap signals, this is where those answers actually arrive. Treat the earlier verdict as provisional until the enriched data confirms it.

Three things about this step that took us a while to get right.

Cache every lookup on disk, keyed by profile URL, and cache the misses too. Runs overlap, lists overlap, and you will re-run after tuning a keyword. Without a cache you pay for the same company repeatedly, and without caching misses you re-pay for every company the provider does not know.

Your budget decides which endpoint you can use, and that silently changes what your criteria can test. Person-level and organization-level enrichment are usually separate calls with separate credits. Our person-level call did not return funding data, and adding the organization call to get it doubled the per-company cost and blew the plan’s budget. We went without and let the judge infer instead.

Have a fallback when the domain is missing. A web search step can resolve it, cached like everything else. Guard it by explicitly rejecting social and directory domains, since LinkedIn and Crunchbase are what a model returns when it cannot find the real answer.

Pre-filter. Now that the facts exist, re-apply the hard rules the facts can settle. Title contradicting the seniority rule, a company on the deny-list, or a known headcount outside your band are all hard fails. Unknown headcount, unconfirmed sector, and unconfirmed funding stage pass through with a flag.

Judge. Whatever survives goes to a model in batches of about twenty with the enriched fields attached, returning a verdict, a one-clause reason, and a competitor flag per lead.

The model answers what a regex cannot: whether this is a business you sell to at all, as opposed to an agency, a consultancy, or a nonprofit carrying a software industry tag.

It also settles the competitor question that the earlier passes could only approximate. Curation ran on a one-line headline, which is enough to catch a company whose name is on your list and not much else. The judge is the first step with the company’s own description, keywords, and funding position in front of it, which is what it takes to separate a company that builds what you build from one that merely uses the same category of tool. Those look nearly identical in a headline and only one is disqualifying. Too permissive and you reach out to your competitors. Too strict and you delete your market.

Four setup details worth copying. Use structured output with one verdict per input index, so nothing is ambiguous about which verdict belongs to which lead. Enforce the competitor flag in code after the response rather than trusting the model’s own consistency. Instruct it to judge only from the fields provided and never fill in from its own recollection of the company. And retry failed batches with backoff rather than aborting, because a ninety-minute run should not die on one network blip.

Keep the audit files and read them. The outreach file gets only what the sending tool needs. Separately, write every lead with its stage and its reason, accepted and rejected both. Reading the rejection reasons is how you find the over-broad keyword that ate a segment. Reading the accepted reasons is how you find the criterion that is too loose. Before running a full list, run about twenty-five rows and read both files end to end.

Keep segmentation in config, not in code. Seniority keywords, size band, sectors, funding stages, competitor definition, and exclusion keywords all belong in one file, so tuning your ICP never means touching the pipeline. Two entries deserve more care than the rest. The competitor definition is prose, because its reader is a model, so write it as an instruction including the builds-versus-uses distinction and an explicit statement of what does not count. And the exclusion keyword list is the only thing here that can delete a lead with no recourse, so treat additions to it as the highest-risk edit you can make.

We run LinkedIn outbound through Dripify. Atlas hands over the list it generated, curated, and enriched, prepped for Dripify to ingest. My co-founder and I both have our profiles configured there, and we split every batch of leads 50/50 into our respective campaigns.

The sequence is simple, and simple is the point.

The first touch is the connection request. In the invitation I say who I am, why I am reaching out, that I am not going to pitch, and that I would like thirty minutes of their perspective. Then I ask whether they are open to a call.

That runs at a 25 to 30% acceptance rate, 5 to 8% reply rate, and about half of those replies convert to a meeting. It puts seven to ten meetings on the calendar a week, which is the right weekly sprint volume for where we are.

From there the sequence forks.

If they have not accepted, a set of soft touches runs on a timer. Three days after the invitation goes out, it likes one of their posts. Two days after that, still no connection, it views their profile. Three days later, another post like. If nothing has happened by then, the sequence ends.

One setting worth changing before you run this: make your profile visits visible rather than private or anonymous. The profile view only does anything if they can see it was you.

If they accept, a direct message goes out an hour later. It restates the ask, because the invitation was short and people accept connections without reading them. What I am doing, what I am trying to learn, thirty minutes of their perspective, no pitch. Then I ask what time this week or early next week works, and offer my calendar link as the easier option if they would rather not go back and forth.

That last part matters more than it sounds. Being sent a booking link is a pet peeve of mine, because it puts the work on the recipient and reads as though your time is the scarce one. Asking for a time and offering the link as a convenience is the same mechanism without the posture.

If they have not replied or booked, the follow-up chain runs: three days later it endorses a skill, five days later a message, seven days later a post like, seven days after that a final message. If no meeting comes out of it, the sequence ends there.

Whatever the sequence looks like, one principle governs the copy: the ask is the conversation, and the message should be answerable by somebody who has no idea what you build. The moment your outreach has to explain your company in order to make sense, you have converted discovery into cold sales, and your reply rate will tell you about it within a week.

Once someone accepts, confirm the calendar, send almost no context, and record the call, because everything in the analysis section later depends on having a transcript. Ask for the referral afterward, every time, without exception.

One thing worth saying plainly about this whole exercise. Every person you interview is a warm contact for a design partnership, a first customer, or an introduction to someone better, which means none of this outreach is disposable. Founders who treat discovery lists as throwaway end up rebuilding the identical list six months later under considerably more pressure.

What follows is one way to run a discovery call. It is the way we run them, and it works, and you should still expect to modify it, because a script delivered by somebody uncomfortable with the script produces worse conversations than no script at all. Find the version that sounds like you talking.

What does not move is the shape underneath. Excavate, then reveal, in that order, roughly two thirds and one third of a thirty minute call. Three movements: the opener, the excavation, the reveal.

You name a domain, and you do not name a solution.

Naming the domain gives the interviewee a reference point, and without one the conversation drifts into territory that cannot help you, leaving you to steer gently for twenty minutes, which is its own form of leading. Here is ours, word for word:

Notice what it withholds. There is no product in it, no category, no solution, and nothing that tells them which answer would please me. What it does is fence the territory and then hand them the next move, so that everything afterward is their choice of direction inside a space I care about. Every question I ask later inherits that frame, which means I never have to reset the conversation or apologize for a tangent.

They will ask what you are building, usually inside the first five minutes. Break the fourth wall and tell them the truth:

People respect this, and more of them than you expect have sat through a fake discovery call that turned out to be a demo in disguise, so naming the difference out loud buys you credibility for the next twenty minutes. It also does something useful for you at the other end of the call, because it turns the reveal into an event the conversation has been building toward, and people listen harder to things they have been waiting for.

Your job for the next twenty minutes is to listen. Not to impress anybody with how good the idea is, how clever the architecture turned out, or how long you have been thinking about this. Listening is the work; everything else is a way of avoiding it.

You are listening for one thing above all others, which is evidence that they are already doing something about this.

It sounds like this. Here’s what we do today. We put a thing together with an LLM. We’re running MCP servers for it. We hired somebody. There’s a spreadsheet. One of the ops people just handles it. The instant you hear any of it, stop and dig, because somebody is spending money or hours on this problem right now, which means the problem cleared a bar inside a company that has no shortage of other problems. Your job is to find out where that bar sits.

The follow-ups are simple and you should use them as prompts inside a conversation rather than as a list to march through:

• What’s working well?
• What’s not working well?
• What do you wish was different?
• Why is that working well?
• Why is that not working well?

The two “why” questions are the ones founders skip, usually because the answer feels obvious after the first four, and they are the ones that produce the sentences you will eventually put on your website.

People will also offer you opinions and hypotheticals, neither of which helps you understand a customer segment, and you have to actively defend your understanding of the problem space against both. When somebody discusses a problem from an intellectual distance, start excavating, and if it turns out they are doing nothing at all about it, that is your finding. It is a better finding than the articulate description they just gave you, and it is worth more precisely because it disappoints you.

One mechanical guardrail is worth borrowing. Wilcox refuses to ask any question containing the word “would,” which is a clean tell for the same failure. The moment “would” appears you have left their reality and entered a simulation in which they predict their own future behavior, something people are consistently and confidently bad at.

If a problem is painful enough to matter, they are already doing something about it. The something may be inefficient, expensive, and hated by everyone who touches it; they may complain about it in the same breath they describe it. None of that matters. If solving it is required to run the company, something exists.

The absence of a workaround is not an invitation to go educate the market, and founders reach for that interpretation because it is the only one that lets them keep going. It is a warning about urgency, it is the most reliable signal available to you inside a discovery call, and it should be taken seriously the first time you see it rather than the fifth.

We define a company as people, process, and technology, and the triad works as an excavation schema. For any problem they raise, get all three: who is involved and who is accountable and who complains, how they solve it today step by step in the order it actually happens, and which tools and systems sit in the middle of that process.

Four questions in and you are still talking about their problem, which is where you want to be. But a complete triad has quietly handed you a competitive inventory described by the people currently paying for it, a workflow you can reference in sales conversations because you know what it looks like from the inside, the roles that will make up your buying committee if you end up running a sales-led motion, and the personas you will need to reach with content if you go product-led instead.

Four go-to-market assets out of three questions, collected while you were doing something else entirely.

This section is aimed at technical founders building vertical applications, because that is where the failure is most common and most expensive.

Your articulation of the problem is not the market’s articulation of the problem. You have been staring at this from the inside for months and you have built a precise internal vocabulary around it, usually organized around the mechanism of your solution rather than the experience of the pain. They live the problem from the outside and call it something else entirely, generally something less elegant and considerably more operational.

You go to market in your language, and buyers do not reject the value; they fail to parse it, and you get a shrug where you were expecting a yes or a no. A shrug is unfalsifiable. So you conclude that the market is early, or the ICP is wrong, or you need more content and a better landing page, and you spend two quarters fixing a problem you do not have. The actual problem was that nobody could tell what you were talking about.

Harvest their vocabulary: literal phrases, written down word for word, kept separate from your summary of what you think they meant. Those exact words become your website copy, your outbound subject lines, and eventually your category framing. Pay particular attention to the answers to “why is that not working,” which is where the usable language is densest, because that is the sentence people have already said out loud to their colleagues.

Blank’s line applies to your words as much as to your roadmap: inside a startup there are no facts, only opinions. Your description of the problem remains an opinion until the market says it back to you.

Two thirds excavation and one third reveal puts the turn somewhere around minute twenty on a thirty minute call. Treat it as a target rather than a rule, since plenty of conversations will not get there and that is fine. The boundary worth defending is the early one: if minute twenty arrives and you are still excavating, you are having a good call, and if minute twelve arrives and you have already pitched, the remainder of the call is worthless to you.

You earn the reveal by pulling a thread from something they said, and this is the part you cannot fake. If you have not been listening it lands flat, everybody in the room registers that it landed flat, and there is no recovering it inside the call. The callback functions as proof of the previous twenty minutes, which is why it comes first and why their words go in front of your solution.

What follows is not a demo. It is not a click-through and it is not a tutorial, and you are not showing anyone where the buttons live or what happens when you press this thing over here. A reveal completes the pair: they named a problem, you map your solution onto it, and that is the entire move. Ours goes like this:

Then the big idea, where this goes if it works, in a minute or less.

Before you ask for a reaction, read the room, because some people are polite in a way that will destroy your data. They will not tell you it is a bad idea, because they do not want to be the person who told a founder their idea was bad. So say it out loud:

You are establishing that honesty is the currency of the conversation, and most people take the permission when you offer it explicitly.

Let them react first, open-ended, with no framing from you, and let whatever they say run all the way out. Truthfully the content of that reaction matters less than founders imagine; you are not looking for a straight opinion on the idea and you are certainly not looking for intellectual validation. Listen anyway. How fast they answer, whether they hedge, and what they reach for first all tell you something the words do not.

Then ask the question that matters:

That question moves them out of evaluating your idea and into imagining their own use of it, and the answers come back specific, grounded in their workflow, and frequently containing the objection that would never have surfaced any other way.

What you never ask is whether they will buy it. It is among the least useful questions available to you, because nobody knows and everybody answers. When you are ready to sell, if they buy, that is your answer about willingness to pay.

There is a compounding effect here worth planning for. Run this reveal across a large number of conversations and a map emerges: which problems attach to which parts of your solution, and how often. That map becomes your positioning and your roadmap priority, derived from the field rather than argued about in a room, and it is the highest-value artifact the entire process produces. It only appears in volume, which is one more argument against stopping at six calls.

You excavate willingness to pay twice. Once before the reveal, once after.

Before, while you are still inside their problem, you are sizing it in their terms and their numbers: what this costs the way it works today, what happens if it simply stays like this, and whether they are paying for anything right now that is meant to help. Nothing they say at that point is contaminated by your pricing, because they do not know what you sell yet.

After the reveal you still do not ask whether they will pay. You ask how valuable this would be to them today, which budget line it would come out of, and who else would need to be in that conversation. That last question hands you the buying committee without requiring you to ask anybody for an org chart.

All of it has a ceiling, and you should hold it loosely. Everything above is stated intent. You learn where the money would come from and who would have to sign. You do not learn whether anyone will. It does not give you the number. The number comes from selling, and no amount of careful questioning substitutes for somebody signing something.

Your recollection of a conversation is not neutral. It over-weights the vivid moment, the person you liked talking to, and the sentence that sounded most like validation. The transcript is the only unbiased record you have, which means it needs to be read by something other than the person who was in the room hoping for a particular answer. Analyze it against a fixed rubric, identically, every time.

Push the transcript through an LLM. Claude, ChatGPT, whatever you already have open, with the rubric as the prompt. That is the whole implementation: no tooling to buy, no permission to ask for, and a well-specified rubric will outperform your memory of the call inside about three conversations.

Anchor the model before it reads a word. Give it the discipline itself: what customer discovery is for, why an existing workaround is the strongest signal in the call, why hypotheticals carry no weight, what separates somebody who owns the problem from somebody who is merely well read on it. Give it the rubric as explicit scoring criteria with definitions, not as a list of topics to comment on. And give it your thesis, meaning what you are building and who you believe the buyer is, so it can tell you where this conversation supports that thesis and where it quietly undercuts it.

Once you have run a handful of them you will want the reading done against everything else the company knows, meaning your roadmap, your pipeline, and every conversation that came before this one. A rubric applied to a single call in isolation is worth a fraction of the same rubric applied in context.

The rubric produces two outputs, and founders consistently underweight the second.

The first is signal against your thesis, scored identically on every call: the five Ws as stated in their words, whether a workaround exists and what it is, the people and process and technology inventory, spend on the current solution alongside the cost of leaving it unsolved, whether this person is actively seeking a way out or discussing the problem from a distance, and the verbatim problem language held separate from your interpretation of it. Because it runs the same way every time, the pattern is computed rather than remembered: which problems repeat, which vocabulary repeats, which segments produce alignment and which produce polite interest.

The second output is coaching on how you ran the call, and it compounds faster than the first one does. Score yourself against the principles in this guide, every time: talk ratio, whether you pitched before the reveal and at what minute your solution first appeared, leading questions including anything containing “would,” excavation cues you heard and failed to chase, hypotheticals you accepted instead of digging into, whether the reveal called back to something they actually said, and whether you held two thirds of the call for excavation.

Discovery is a skill with a slow and noisy feedback loop, which is the reason founders stay bad at it for years. You do something wrong in a call, and the consequence surfaces months later wearing the costume of a market problem. A rubric collapses that loop to a day. You find out you have been pitching at minute nine. It also tells you what you did well, which is what you need the first time you hand a call to someone else.

Ask for the referral at the end of the call and again in the follow-up email. The people who gave you the best signal know other people with the same problem and are usually glad to say so.

As for when to stop, Wilcox offers a usable test: interview in batches of five, analyze, and repeat until at least three of the last five people are actively seeking a solution. He keeps the batch small because widening past five tends to widen who you are willing to talk to, at which point you drift across segments and lose the pattern you were trying to find. The rubric computes this for you, since “actively seeking a solution” is a field on the scorecard rather than a judgment you make from memory two weeks after the call.

Discovery produces artifacts. Positioning, marketing, sales, and product each get something out of it.

Positioning gets the verbatim problem language, which is the highest-leverage output of the entire process and the one most reliably destroyed, because founders paraphrase into their own vocabulary within a day of the call and never notice they did it. Marketing gets the Why column as message and the Where as channel, particularly if you remembered to ask where they go looking for information about this; it also gets your competitive set for free, since the technology leg of the triad is a list of vendors your buyers already pay.

Sales gets the buying committee before there is a sales motion to put it into, along with the budget line you are competing for, who signs for it, and a precise description of what you are asking somebody to rip out, which is the objection you will hear most and the one you should have an answer prepared for.

Product and engineering get the workaround inventory, which is a better requirements document than a feature list because it shows you what people will tolerate. Anything a customer built for themselves is a specification with a working prototype attached to it. The cardinality map sets priority: build against the problems that recur, rather than the ones that were described most vividly by the person you liked most.

And the company itself gets a memory, or it should. The output of a hundred discovery calls is an asset, and most startups let it evaporate into two founders’ heads and a folder of transcripts nobody opens again. Institutionalize it or you will rerun these same interviews in eighteen months, at considerably higher cost, for a new head of marketing who was not in the room the first time.

Which points at what this is really arguing. Founders treat discovery as validation, a thing you do to find out whether you are allowed to build, and it is closer to the opposite. Validation is a byproduct. The primary output is the operating vocabulary of your company: what the problem is called, who owns it, what it costs, which budget it competes against, and what customers will put up with while you fix it. Skip discovery and you do not merely risk building the wrong thing. You build the right thing and cannot describe it to anybody.

Search, then execute. Discovery is the search, and it is the only part of the job that will tell you what you are wrong about while being wrong is still cheap.

Blank’s description of the alternative has held up for two decades.

So go find out. Nothing to sell, no idea to defend, a lead to follow, and a story you do not get to write in advance.

A timeboxed version of everything above, for reference during the call.

The timings are a target rather than a metronome. The one boundary worth defending is the reveal.

Fill in the brackets before your first call and say it in your own words after that. The sequence is what matters; the wording is yours.

Write these down before you start:

• [PROBLEM SPACE] The domain you’re curious about, named without naming a solution. Wide enough that they can go anywhere inside it, narrow enough that they can’t go outside it.
• [SOLUTION STATEMENT] One sentence. What you eliminate, how, and what it frees them up to do instead.
• [BIG IDEA] Where this goes if it works. Sixty seconds, spoken out loud.

1. Frame (0:00–2:00)

2. Open the space (2:00–8:00)

Then stay out of the way. Follow-ups only:

If they ask what you’re building:

3. Excavate (8:00–18:00)

The trigger is any mention of what they do today: a spreadsheet, a tool, a contractor, a process somebody invented on a Thursday. Go here:

Then map the triad:

If they’re speaking hypothetically, describing the problem in the abstract with no example and no workaround:

If the answer is nothing, write it down. That is your finding, and it is worth more than the articulate version of the problem they just handed you.

4. Size it (18:00–20:00)

5. Reveal (20:00–21:00)

Callback first, and never skip it:

Then the solution, then the big idea, under a minute:

Then prime them:

6. Their reaction (21:00–27:00)

Let them talk first and let it run all the way out. Then ask the question that matters:

Let the silence sit after you ask it. This is the answer you came for.

7. Close (27:00–30:00)

Immediately after

Don’t write a summary from memory. Push the transcript through an LLM with your rubric as the prompt and let the pattern accumulate across calls. Once you’ve run a handful of these you’ll want that reading done against everything else the company knows, rather than one call at a time.

Steve Blank

• The Customer Development Manifesto: Reasons for the Revolution, Part 1
• The Customer Development Manifesto: Reasons for the Revolution, Part 2
• Customer Development Manifesto: Market Type, Part 4
• Customer Development Manifesto: The Path of Warriors and Winners, Part 5
• Ardent 2: Get Out of My Building
• Business Model versus Business Plan

Justin Wilcox, Customer Development Labs

• How to Interview your Customers
• The Customers you Should be Interviewing
• How Many Customers Should You Interview?
• Video: How to Interview your Customers (further reading)