Before making a single proposal slide, a competent consultant goes into the field. Interview, listen, and observe aren’t formalities—they’re the work that separates an accurate diagnosis from a well-presented guess.
🎯 Discovery objective
Discovery exists for one simple purpose: understand the operation before proposing anything. It’s the antidote to the consultant who arrives with the solution ready and looks for evidence to justify it.
🔍 What you need to find out
- •What the actual work is — not what the flowchart shows, but what people do.
- •Where is the pain most acute — frequency, cost, urgency, visibility.
- •Who has the problem and who has the budget to solve it — often, they’re different people.
✓ Consultant who conducts discovery
- ✓Comes with hypotheses to validate, not ready-made answers
- ✓Listens more than they speak in the first meetings
- ✓Proposes after understanding, not before
- ✓Validates the diagnosis with the people doing the work
✗ Consultant who skips discovery
- ✗Proposes in the first meeting without listening to the context
- ✗Treats the symptom, not the cause
- ✗Discovers during implementation that the problem was something else
- ✗Loses credibility when the solution doesn't work
❓ Questions that reveal the pain (SPIN)
SPIN is a framework by Neil Rackham, developed from an analysis of 35,000 sales calls. It works just as well for consultative diagnosis because the sequence matters: you can’t talk about implications without understanding the problem.
Situation — "Tell me the context"
Examples: How many people work on this process? What tool do you use today? How often does this happen?
Objective: map the current state. Limit situation questions—they’re tedious for the person you’re speaking with if there are too many.
Problem — "Where does it hurt?"
Examples: Which part takes the most time? What usually gets delayed? What are you most tired of correcting?
Objective: identify explicit pain points. The person you’re speaking with usually has a lot to say here—let them talk.
Implication — “What does this problem lead to?”
Examples: Does this delay affect other departments? When an error happens, what needs to be redone? How much time is lost each week because of this?
Objective: broaden awareness of the cost of the problem. The person you’re speaking with often hasn’t connected the dots—you help them do that.
Need — "What would change if you solved it?"
Examples: If this process took 10 minutes instead of 2 hours, what else could you do? What would be possible that isn't today?
Objective: articulate the solution’s value before proposing it. The person you’re speaking with starts to "buy into" the idea during the interview.
💡 Practical tip
Prepare 3 questions of each type before each interview. You don't need to follow the sequence rigidly — but make sure you cover all four dimensions before you finish.
👂 Active listening and confirmation bias
Confirmation bias is the human tendency to pay more attention to information that confirms what we already believe. For consultants, this shows up as "I already knew that was it" — what stalls the real diagnosis.
Signs that you’re falling into the bias
- ⚠You already have the solution in mind before the first interview
- ⚠You interrupt the other person when they say something unexpected
- ⚠Your notes only record what confirms your hypothesis
- ⚠You dismiss data that contradicts you as an "outlier"
Active listening techniques
Paraphrase
"So, if I understand correctly, the problem is X—is that right?" Confirms understanding and signals genuine attention.
Intentional silence
After an answer, wait 3-5 seconds before speaking. The other person will usually add the most important information during the silence.
Note the unexpected
Set aside a column in your notes for "surprised me." At the end of the interview, review this field—it often contains the most valuable insights.
Ask the opposite
"Does anyone think this isn't the main problem?" — brings opposing perspectives to the surface.
🚶 Observe the actual work (gemba)
Gemba is where the work happens—the factory floor, the call center queue, the financial analyst’s screen. Go to the gemba it’s the practice of observing directly instead of relying only on what people describe in meetings.
🏭 Why the actual process diverges from the documented one
- •Accumulated workarounds — over time, people develop workarounds that were never documented.
- •Parallel tools — local spreadsheets, WhatsApp, and paper notes that the official system doesn't capture.
- •Informal stages — checks, approvals, and consultations that happen but no one "counts" in the process.
💡 How to conduct a gemba walk
- Ask to sit beside someone carrying out the process
- Observe without interrupting for the first 15 minutes
- Record each action, tool used, and wait time
- Ask about what wasn't clear at the end, not during
- Compare with the official flowchart — the differences are the diagnosis
👥 Map stakeholders
A stakeholder map isn’t bureaucratic red tape—it’s essential political intelligence. The person who feels the pain rarely approves the budget, and the person who approves the budget rarely understands the operational pain.
Who bears the burden (operations)
- • Knows the problem details
- • There’s a lot to gain or lose from change
- • Will need to adopt the new solution in their day-to-day work
- • Can sabotage the project or champion it
Who pays (executives)
- • Focuses on results, not technical details
- • Need to see ROI or reduced risk
- • Can approve or kill the project for political reasons
- • Executive sponsor is essential
Questions to map the political landscape
- • Who loses power or relevance if this process changes?
- • Who has the most to gain and could champion the project?
- • Who can informally say “no” and stall implementation?
- • Are there departmental conflicts that affect the scope?
📋 Documenting and Synthesizing the Findings
Interviews generate raw data—loose notes, observations, quotes. The synthesis is the intellectual work that turns data into a diagnosis. Without it, you have material but no deliverable.
Discovery document structure
Who was interviewed, what was observed, discovery period.
Ranked by impact. Each one includes collected evidence.
Transparency about what you expected to find and what you actually found.
Who influences, who pays, who executes, who can block.
What still needs to be validated before the proposal phase.
⚠️ Attention
Don’t deliver the discovery document as a “research report” — present it as an “initial assessment with a recommendation for next steps.” It’s a matter of positioning: you’re not a researcher; you’re a consultant.
🎒 Module summary
Next module:
2.2 — Process and bottleneck mapping