The revealing moment in a discovery call is often the one you didn't prepare for. You've researched the account, recognized a familiar problem, and worked out some thoughtful questions. Then the customer says something that doesn't fit. What you do with that answer tells you a lot about the quality of your preparation.
You can follow it, ask another question, and revise your understanding. Or you can steer back toward the explanation you arrived with. The second approach can still sound informed and professional, especially when you know the product well. But the customer ends up being asked to confirm a conclusion you've already reached. That's validation disguised as curiosity.
Have a reason for your starting point
Preparation should make the conversation easier for the customer. Read the account history, understand the business, and look for the questions that deserve attention. Arriving with no point of view can turn discovery into a wandering interview in which the customer has to supply all the direction. Your experience should help you find a useful place to begin.
The challenge is remembering how much of that starting point is your interpretation. A problem you've seen elsewhere may explain this account, or it may only look familiar from a distance. An internal handoff may contain a customer's exact words alongside an assumption somebody made three calls ago. Before the meeting, separate those things in a simple preparation card:
- What we think is happening: Our current explanation of the problem.
- Why we think that: Customer statements, observations, or other information that supports it.
- What would change our minds: Something we might learn that would make us revise the explanation.
That last entry is worth spending time on. If you can't imagine an answer that would change your approach, ask a colleague where your explanation seems weakest. It's easier to question an assumption before the team has built the demo, proposal, and forecast around it.
Follow the answer that changes the plan
Suppose a customer asks about a training portal because new employees take too long to become productive. The account team suspects that instructions are hard to find and inconsistent across departments. A better library of training material sounds promising. So far, though, the team knows only that new hires are struggling and the customer has asked for a portal. It still needs to find out where the delay occurs.
A useful opening would be: “We wondered whether finding the right instructions was part of the delay. Could you walk us through a recent new hire's first assignments, including where they got stuck?” The customer can see your reasoning and has room to correct it. You're asking about something that happened, which gives you more to work with than a general opinion about whether better training would help.
The customer explains that the instructions are easy to find. The employee can't follow them because access to the required systems is waiting on three approvals, and nobody owns the full request. A better training library would leave that person reading clearer instructions for work they still can't do. The delay is elsewhere.
Now the questions should change. Who requests access? Which approvals are required? How does anyone notice that a request has stalled? Who can resolve it? You may have prepared to discuss training content, but the customer has given you a reason to examine access requests and ownership. Following that answer is how the preparation pays off: it helped you recognize that your first explanation was wrong.
Make it easy to revise your understanding
Asking someone to walk through a recent example brings out details that broad labels hide. “Slow onboarding” could mean missing instructions, delayed access, unclear expectations, or a combination of them. Once you understand the sequence, summarize it in ordinary language and invite correction. In this case: “The new hire had the instructions, but couldn't get into the system. Is that where most of the delay happened?”
Keep that account separate from your recommendation. In the notes, record what the customer described alongside what you think it means. That lets someone question the proposed solution without losing the details that led to it. It also makes differences between stakeholders easier to examine. If an executive describes a speed problem and an operator describes a quality problem, keep both accounts and find out how they relate. Choosing whichever version fits the product leaves the disagreement for someone else to discover later.
After the call, revise the preparation card while the conversation is fresh. The account team now knows enough to arrange a working session on access requests, though it may still need to understand why the approvals stall. The planned training-portal demo can wait. A change in direction like that is a useful result: the team has a better question to investigate, and the customer has been heard.
Experience gives us patterns to recognize and ideas to test. Curiosity lets us find out where those patterns stop being useful. Good preparation leaves room for both.