Most consultants ask surface-level questions and get surface-level answers. “What’s the problem?” “Communication is bad.” That’s useless. Here’s how to dig deeper and find the root causes clients will actually pay you to fix.
The Question That Gets You Nothing
You’re in a discovery interview.
The client sits across from you (or on Zoom). You’ve got your notepad ready.
You ask: “So, what’s the problem?”
They say: “Communication is terrible.”
You write it down. Communication is terrible.
You ask: “What else?”
They say: “Projects keep falling through the cracks.”
You write it down. Projects falling through cracks.
You ask: “Anything else?”
They say: “People don’t know who owns what.”
You write it down. Unclear ownership.
Congratulations. You just wasted 30 minutes getting information you already knew from the kickoff call.
This is what most consultants do. And it’s completely useless.
Why?
Because “communication is terrible” isn’t the problem. It’s a symptom.
The real problem is WHY communication is terrible. Is it because:
- People don’t know who to communicate with?
- The tools are clunky?
- There’s no clear process for escalation?
- Leadership doesn’t communicate priorities?
- Teams are siloed by design?
Those are different problems requiring different solutions.
If you solve “communication” without understanding the root cause, you’ll deliver a surface-level fix that doesn’t stick.
And the client will think: “We paid $25K for this?”
I learned this the hard way. Multiple times.
Today, I’m teaching you how to dig deeper.
Why Most Discovery Interviews Fail
Let me show you what goes wrong:
Mistake #1: You Ask Leading Questions
Bad question: “Don’t you think the real issue is that people aren’t held accountable?”
Why it fails: You just told them the answer. They’ll agree because you’re the expert. But you haven’t learned anything—you’ve just confirmed your bias.
Mistake #2: You Accept the First Answer
You ask: “Why do projects fall through the cracks?”
They say: “People are too busy.”
You write it down and move on.
Why it fails: “Too busy” is never the root cause. It’s another symptom. The question is: WHY are they too busy? What’s creating the workload? What could be eliminated?
You stopped one layer too early.
Mistake #3: You Ask About Solutions, Not Problems
You ask: “What do you think we should do?”
Why it fails: They hired you to figure that out. If they knew the solution, they’d have implemented it already. You’re letting them off the hook instead of diagnosing the real issue.
Mistake #4: You Don’t Ask for Examples
They say: “Leadership keeps changing priorities.”
You write it down.
Why it fails: That’s an opinion, not data. Without a specific example, you don’t know:
- How often does this happen?
- What triggers it?
- What’s the impact?
- Is this one person’s frustration or a systemic issue?
Opinions are cheap. Examples are gold.
The Discovery Interview Framework That Actually Works
Here’s how to run interviews that uncover root causes:
PHASE 1: Setup (First 5 Minutes)
Your opening:
“Thanks for making time. I’m working with [leadership] on [project goal]. I’m not here with a predetermined solution—I’m here to learn how things actually work, from people who do the work.
Everything you share is confidential. I’ll synthesize themes across conversations, but I won’t attribute specific comments to individuals.
I’m going to ask a lot of questions. Some might feel basic. That’s intentional—I want to understand the full picture, not just assume I know.
Sound good?”
Why this works:
✓ Psychological safety (they can be honest)
✓ Confidentiality (they’ll share things they wouldn’t tell their boss)
✓ Permission to ask “dumb” questions (removes your imposter syndrome)
PHASE 2: Their Story (10-15 Minutes)
Start broad. Let them talk.
You ask:
“Tell me about your role. What does a typical day or week look like?”
[Shut up. Let them talk. Take notes.]
You’re listening for:
✓ What they spend most of their time on
✓ What frustrates them
✓ What they’re proud of
✓ Who they interact with
✓ Where friction happens
Don’t interrupt. Don’t redirect. Just listen.
After 10 minutes of them talking, you’ll know more than 30 minutes of you asking specific questions would reveal.
PHASE 3: Problem Exploration (The “5 Whys” Technique)
Now you start digging.
They say: “Projects keep getting delayed.”
Don’t write it down and move on. Dig deeper.
You ask: “Walk me through a recent example. What project got delayed? What happened?”
[Get specific. Names. Dates. Details.]
They say: “The Q3 product launch. It was supposed to ship in September, shipped in November.”
You ask: “What caused the delay?”
They say: “Engineering couldn’t hit the deadline.”
You ask: “Why couldn’t they hit it?” (Why #1)
They say: “Scope kept changing.”
You ask: “Why did scope keep changing?” (Why #2)
They say: “Product team kept adding features based on customer feedback.”
You ask: “Why were features being added mid-project instead of during planning?” (Why #3)
They say: “We don’t have a feature freeze process. Things get added whenever.”
You ask: “Why isn’t there a feature freeze process?” (Why #4)
They say: “Leadership hasn’t agreed on how to prioritize features. So everything is equally important.”
BINGO. Root cause: No prioritization framework.
That’s completely different from “Engineering is slow.”
This is the “5 Whys” technique. Keep asking “why” until you hit bedrock.
You’ll know you’re there when the answer is:
- “We’ve never set that up”
- “No one owns that decision”
- “We don’t have a process for that”
- “Leadership hasn’t aligned on that”
That’s the real problem.
PHASE 4: Impact Quantification (Critical)
You’ve identified a problem. Now quantify it.
You ask:
“How often does this happen? Weekly? Monthly?”
“How much time does this cost you personally?”
“How much time does it cost the team collectively?”
“What’s the dollar impact? Lost revenue? Wasted costs?”
“If this problem went away, what would change?”
Example:
They say: “Scope changes delay projects.”
You ask: “How often does this happen?”
They say: “Probably every other project.”
You ask: “How many projects per quarter?”
They say: “Six.”
You do the math: So 3 projects per quarter get delayed. That’s 12 per year.
You ask: “What’s the average delay?”
They say: “Usually 4-6 weeks.”
You ask: “What does a 4-week delay cost in lost revenue or wasted resources?”
They say: “Probably $50K-75K per project when you factor in lost market timing and re-work.”
You do the math: 12 projects x $60K average = $720K annual cost.
THAT’S the number you’ll reference in your diagnostic report and final presentation.
Without quantification, you’re just complaining about problems.
With quantification, you’re building a business case for your solution.
PHASE 5: What They’ve Tried (And Why It Didn’t Work)
You ask:
“What’s been tried before to solve this?”
“What happened?”
“Why didn’t it stick?”
This is gold.
You learn:
✓ What NOT to recommend (because they already tried it)
✓ Why previous attempts failed (so you can address those failure points)
✓ Whether this is a recurring problem or new
Example:
You ask: “Has anyone tried to fix the scope change issue before?”
They say: “Yeah, we implemented a change request process two years ago.”
You ask: “What happened?”
They say: “Leadership just bypassed it whenever they wanted.”
You ask: “Why could they bypass it?”
They say: “It wasn’t mandatory. Just a suggestion.”
Now you know: Your solution needs leadership buy-in and enforcement, not just a process.
This is why asking “what’s been tried” is crucial.
PHASE 6: The Ideal State (What Good Looks Like)
You ask:
“If we’re sitting here a year from now and this problem is solved, what’s different?”
“What does ‘good’ look like in your world?”
This gives you:
✓ Their vision of success (which might differ from leadership’s)
✓ Realistic expectations (what they think is achievable)
✓ Hidden needs (things they want but haven’t articulated)
Example:
You ask: “If projects stopped getting delayed, what would be different for you?”
They say: “I’d spend less time in crisis mode. I could actually plan my week instead of constantly firefighting.”
Write that down. When you deliver your solution, you’ll reference this: “Remember when you said you wanted to plan your week instead of firefighting? Here’s how this system makes that possible.”
PHASE 7: The Hidden Question (Who Else Should I Talk To?)
Near the end, you ask:
“Who else should I talk to who has a different perspective on this?”
“Is there anyone who’s closer to this problem than you are?”
“Anyone who disagrees with how you’re seeing this?”
Why this matters:
✓ You discover people you didn’t know existed
✓ You get introduced to dissenting voices (which prevents blind spots)
✓ You show you want the full picture, not just confirmation
This question has led me to the MOST valuable interviews in almost every project.
The Complete Interview Script (Put It All Together)
Here’s how it flows in real conversation:
[Setup – 5 min]
You: “Thanks for making time. I’m working with leadership on improving project delivery. I’m not here with a predetermined solution—I’m here to learn. Everything you share is confidential. I’ll ask a lot of questions, some might feel basic. Sound good?”
[Their Story – 10 min]
You: “Tell me about your role. What does a typical week look like?”
[Let them talk. Take notes. Don’t interrupt.]
[5 Whys – 15 min]
You: “You mentioned projects get delayed. Walk me through a recent example.”
Them: “Q3 product launch got delayed.”
You: “What caused the delay?”
Them: “Engineering couldn’t hit the deadline.”
You: “Why couldn’t they hit it?”
Them: “Scope kept changing.”
You: “Why did scope keep changing?”
Them: “Product team kept adding features.”
You: “Why were features being added mid-project?”
Them: “No feature freeze process.”
You: “Why isn’t there a feature freeze process?”
Them: “Leadership hasn’t agreed on prioritization.”
You: “Got it.” [Write: Root cause = No prioritization framework]
[Quantify – 5 min]
You: “How often does this happen?”
Them: “Every other project. So 3 per quarter.”
You: “What does a delay cost?”
Them: “Probably $50K-75K per project.”
You: [Calculate: 12 projects/year x $60K = $720K annual cost] “So roughly $720K per year?”
Them: “Yeah, probably.”
[What’s Been Tried – 5 min]
You: “Has anyone tried to fix this before?”
Them: “Yeah, we implemented a change request process.”
You: “What happened?”
Them: “Leadership bypassed it whenever they wanted.”
You: [Write: Previous solution failed due to lack of enforcement]
[Ideal State – 5 min]
You: “If projects stopped getting delayed, what would be different for you?”
Them: “I could actually plan my week instead of firefighting.”
You: [Write: Success = Predictable schedules, less firefighting]
[Who Else – 3 min]
You: “Who else should I talk to who has a different perspective on this?”
Them: “Talk to Sarah in Product. She sees this from the customer side.”
You: “Perfect. Anything I didn’t ask that I should have?”
Them: “No, I think you got it.”
You: “Great. Can I follow up if I have more questions?”
Them: “Sure.”
Total time: 48 minutes.
You just learned:
- Root cause (no prioritization framework)
- Annual cost ($720K)
- Why previous solution failed (no enforcement)
- What success looks like (predictable schedules)
- Who else to talk to (Sarah)
That’s a productive interview.
How to Take Notes During Interviews
Don’t transcribe everything. Capture:
Column 1: What They Said
Direct quotes (in quotation marks)
“Leadership keeps changing priorities.”
“We don’t have a feature freeze.”
Column 2: What It Means (Your Interpretation)
→ No prioritization framework
→ Scope creep is systemic, not individual
Column 3: Follow-Up Questions
→ Who owns prioritization decisions?
→ What triggers scope changes?
Column 4: Quantification
→ 3 projects/quarter delayed
→ $60K cost per delay
→ $720K annual impact
After the interview, spend 10 minutes cleaning up your notes while it’s fresh.
Don’t wait. Do it immediately.
Red Flags During Interviews
Watch for these warning signs:
Red Flag #1: Everyone Blames Someone Else
Engineering blames Product. Product blames Sales. Sales blames Leadership.
What it means: Accountability isn’t clear. Or there’s a culture problem.
What to do: Map the blame patterns. That’s your starting point.
Red Flag #2: No One Knows Why Things Are Done a Certain Way
“We’ve always done it this way.”
“I don’t know. That’s just how it is.”
What it means: Processes are legacy. No one’s questioned them.
What to do: Quick wins by eliminating outdated processes.
Red Flag #3: People Are Afraid to Be Honest
Short answers. Defensive body language. “Everything’s fine.”
What it means: Political environment. Fear of retaliation.
What to do: Build more trust. Guarantee confidentiality. Interview more junior people (they’ll be more honest).
After the Interviews: Pattern Recognition
Once you’ve done 5-10 interviews, look for:
Pattern #1: What Everyone Mentions
If 7 out of 10 people mention “unclear priorities,” that’s a systemic issue.
Action: This goes in your diagnostic report as a primary finding.
Pattern #2: What Only One Person Mentions
If only one person says “The CRM is broken,” dig deeper. Is it:
- A real issue others don’t see?
- One person’s pet peeve?
- A symptom of a bigger problem?
Action: Validate with others before including in findings.
Pattern #3: Contradictions
Leadership says: “We communicate priorities clearly.”
Teams say: “We never know what’s most important.”
That’s a gap worth exploring.
Action: Highlight this gap in your report. It’s where the solution lives.
Your Discovery Interview Checklist
Before the interview:
- Review their role/background
- Prepare 5-7 core questions
- Test recording equipment (if using)
- Block extra 15 min after for note cleanup
During the interview:
- Build trust (setup phase)
- Let them tell their story (10+ min uninterrupted)
- Use 5 Whys to find root causes
- Quantify impact (get numbers)
- Ask what’s been tried before
- Define their ideal state
- Get referrals to other interviewees
After the interview:
- Clean up notes immediately (10 min)
- Identify patterns vs. outliers
- List follow-up questions
- Update interview tracker
- Send thank-you email
Talk Tomorrow
Tomorrow, we’re talking about how to synthesize all your discovery findings into a diagnostic report that makes the client say “This is exactly what we needed”—and sets you up for Phase 2.
Hit reply and tell me: What’s the hardest part of discovery interviews for you? Getting people to open up? Knowing what questions to ask? Digging past surface answers?
I want to know where you struggle.
And if you know someone who’s about to start their first consulting project and needs to nail discovery, forward this to them. The quality of your discovery determines the quality of your solution.
— Bob
P.S. That “Who else should I talk to?” question? It’s led me to the most valuable interview in 70% of my projects. The person they recommend is usually the one closest to the real problem. Ask it every time.
