Take me through how you run a technical discovery call.

Preparation stops well short of a solution

Before the call, know their industry, who is in the meeting and what each person's remit is, and — most usefully — what their engineering job adverts say, because those describe the estate more honestly than a website does. What you should not have is a solution. Arriving with a proposed architecture converts the call from an investigation into a defence of something you invented from a two-line brief, and the customer will politely correct you rather than tell you what is really wrong. Prepare a loosely held hypothesis instead — "their problem is that claims handlers re-key data between three systems, and the cost is cycle time rather than headcount" — which gives your questions direction and is cheap to abandon in the first ten minutes, roughly when you should expect to abandon it.

The first three minutes buy you the rest

Open by stating the shape of the call and getting agreement to it, because otherwise you have thirty minutes of unstructured conversation and no permission to ask the awkward questions later. Something close to this, said quickly:

"I have got us for fifty minutes. My plan is to spend most of it understanding how
this works for you today and what you are trying to change, then ten minutes at
the end on what a sensible next step looks like. I will probably ask some
questions that sound basic, and some about how decisions get made here - stop me
if I am going somewhere unhelpful. Does that work, or is there something you need
to get out of this call specifically?"

That last clause matters. Whatever they name becomes the thing you must cover, and if they name nothing you have learned something about how invested they are.

Order the questions outcome, process, constraint, decision

Ask about the business outcome first, the current process second, technical constraints third, the decision process fourth. Engineers reliably invert this, opening with the stack because it is comfortable, and the cost is that every subsequent answer is framed as a technology preference rather than a business problem you could solve several ways. The current-process questions carry the value, and they work best as walkthroughs of a single unit of work rather than as abstractions. "What are your pain points?" invites a rehearsed answer from a slide someone else wrote. "Take one claim that failed validation last Tuesday and tell me everywhere it went" produces the queue nobody owns, the spreadsheet that turned out to be load-bearing, and the person who leaves at four.

Phase	A question that works	Why it earns its place
Outcome	"If this works, what is measurably different in twelve months?"	Forces a metric, or reveals there is not one
Outcome	"What made this the quarter you decided to do something?"	Distinguishes a funded project from an interest
Process	"Walk me through one order end to end, including the bits you are embarrassed by"	Exposes manual steps that no requirements list mentions
Process	"Who does this today, and what do they do when it goes wrong at 6pm?"	Gets you the operational reality and the real users
Constraint	"What could we not change even if it were the right answer?"	Surfaces the identity provider, the contract, the sacred system
Constraint	"Who has to approve a system holding this data, and have they been told yet?"	Finds the security or residency blocker early
Decision	"If you decide to go ahead, walk me through what happens between then and a signature"	Reveals procurement, legal and the real timeline
Decision	"Who else has to agree, and what would each of them need to see?"	Gives you the stakeholder map and your demo brief

Notice that none of them are answerable yes or no, and none can be answered from public information. That is the test to apply to any question you are about to ask.

Qualifying is a separate activity happening at the same time

Discovery collects information about the problem. Qualification decides whether there is a deal, and it is the half engineers skip. By the end of the call you should be able to answer, in one line each, whether there is a business consequence to doing nothing, whether money exists or would have to be found, who can say yes, what their process to yes involves, what is driving the timeline, and who inside the organisation wants this to happen. MEDDIC is the common shorthand for that set, and naming a framework is fine — but interviewers listen for whether you can extract the facts conversationally, not whether you can recite the acronym.

The mechanic that makes it possible without turning the call into an interrogation is to answer, then ask. They ask whether you support their identity provider; you say yes, briefly, then follow with "who owns that decision on your side — will they need to review this?" Every technical answer you give is a licence to ask one thing back, and a call where you gave nine generous answers and asked nothing is a call where you were used as free consulting.

The highest-yield qualifying question is what changed. Organisations tolerate broken processes for years, so a project becomes funded when something specific happens: a regulator's finding, a new operations director, a system going out of support, a competitor doing something visible. If nobody can name the change, you are probably talking to someone researching next year's budget, and that is worth knowing before you commit three engineers to a proof of concept.

Declining to demo, without being difficult about it

You will be asked to show the product early, and doing it is the most common way discovery dies, because once the screen is shared the conversation becomes a feature tour and you never get back. Refuse by trading rather than by explaining your process: "Happy to — and it will be a better use of your time if I know which of the three ways this can be set up is relevant to you. Give me fifteen more minutes on how the reconciliation runs today and I will show you the version that matches." Almost nobody argues, because you offered something better rather than withheld something. If they insist twice, show something; being rigid about your own methodology in front of a customer reads worse than a slightly premature demo.

Closing with a commitment and a recap

Spend the last ten minutes on the next step, and make it a mutual commitment with a date and names rather than a promise to follow up. Then send a written recap within a day: their objective as you heard it, the current process, the constraints, the open questions, and the next step with owners. Ask them to correct anything you got wrong.

That email is a qualification instrument as much as a courtesy. A recap that comes back corrected, forwarded to a colleague, or answered with two more questions tells you that you have a champion. A recap that is never acknowledged tells you the same thing in the other direction, for the price of one email rather than a month of pipeline optimism.

Where strong engineers lose this round

The characteristic failure of a technically excellent candidate is a discovery call that produces a superb requirements list and no idea whether anyone will buy anything. You can tell it is happening because the answer to "what did you learn?" comes back entirely in nouns from the customer's estate — the message broker, the record counts, the batch window — and contains no person, no date, no budget and no consequence of inaction.

The second failure is solving the problem live. When a customer describes something you have solved before, the pull to design the answer on the call is enormous and it feels like value. What it does is stop the diagnosis at the first plausible cause, commit you publicly to an approach you have not thought through, and occasionally hand a competitor your architecture, because a customer who liked your idea will repeat it to the next vendor.

A discovery call is graded on your listening ratio and on what you can now answer about the customer's decision, not on how much you learned about their architecture — if you leave with a complete requirements list and cannot name who signs or what changed this quarter, you ran a free consulting session.