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.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).