Consulting & customers
Before you propose a solution, ask about the last time
Ask the client to walk through a recent example of the problem. Find out what they were trying to do, where the difficulty appeared, who was affected, and what they have already tried.
A requested solution is a starting point
A client asks for a dashboard. You know how to build one, so the conversation quickly turns to charts, data sources, and delivery dates. Only later do you learn that the hardest part of their week is getting three departments to agree on which numbers to use.
The dashboard may still be useful. But the first request did not tell you enough to know. Discovery gives both of you a chance to describe the work before committing to a particular answer.
Make the problem concrete
Ask for a recent event rather than an imagined future. A specific Monday meeting, customer handoff, or approval delay gives the conversation something to return to.
Follow the sequence. What were they trying to do? What happened next? Where did someone have to wait, repeat work, or make a decision without enough information? Ask what a phrase like “too slow” means in that example.
“Could you walk me through the last meeting where you wished this dashboard existed? What were you trying to decide, and what made that difficult?”
Check the picture before offering the plan
Summarize what you think you heard. Include the outcome, the obstacle, and the people affected. Invite a correction. You may discover that the most visible complaint is not the one the client most needs help with.
Discuss who needs to agree, what cannot change yet, and what a useful first improvement would look like. Then agree on the first piece of work and the assumptions you still need to check.
Leave with a question you can answer next
Discovery does not have to end with a confident recommendation. Sometimes the useful result is a narrower uncertainty: whether two teams use different definitions, whether a delay is recurring, or whether the proposed change would reach the people doing the work.
Name what you know, what you are inferring, and what would help you check the inference. Agree who will find out, and when you will return to the decision.
For consultants, sales teams, customer-success staff, and forward-deployed engineers, this is part of making expertise useful. Use what you learn to propose the next step, and say which assumptions you still need to check.
Practice asking about a customer’s actual workflow
Try your response to a fictional conversation, then read the guidance and decide what you would change.
Open the practiceThree starter practices are free. Soulful opens the full library.Sources and limits
These sources establish the relevance of discovery work. The fictional dashboard conversation is an authored application, not an experimentally validated interview protocol.
- O*NET: management analysts and consultants
Describes gathering information, interviewing people, and preparing recommendations.
- GitLab: solutions architect practice
An operating reference for discovery and understanding customer needs; it is one organization’s model.
Published by Leetsoul. Sources checked . Examples are fictional. Read our evidence approach.