The Diagnostic-First Framework for AI Enablement
The Diagnostic-First Framework for AI Enablement
The Pattern I Keep Seeing
I became the “AI person” without asking for it. Just started using AI in my work, and suddenly the requests flooded in:
- “Build us a knowledge-sharing bot for client services”
- “Automate our status updates”
- “Create a tool to help us onboard specialists faster” Every request sounded reasonable. Every request missed the actual problem. What I noticed: When I asked a few diagnostic questions, most requests evaporated. No follow-up. Which meant they were treating AI like a band-aid for systematic issues they didn’t have language for yet.
The Real Problem Underneath
People weren’t asking for tools to do tasks. They were experiencing something deeper: Emotional and cognitive drain from how we work under pressure. Client pivots that made prior work feel wasted. Ad hoc requests disrupting planned timelines. New specialists joining mid-flight with no capacity to onboard them. The constant sense that hard work got thrown away instead of adjusted. Under that pressure, teams lose access to principles, frameworks, and domain knowledge they actually possess. They revert to reactive firefighting mode. And then they ask for an AI tool to “fix” the symptom without naming the disease.
What Doesn’t Work
Building the tool they asked for. Because even if you build it, the systematic issue remains. Worse, you’ve now added another tool to an already overwhelmed team’s stack. Jumping straight to AI solutions. AI amplifies whatever clarity (or confusion) you bring to it. Feed it an unclear problem and you get sophisticated noise. Feed it a well-diagnosed problem and you get leverage.
What Does Work: The Diagnostic-First Approach
Before building anything, run a quick diagnostic conversation. Not formal interviews. Just questions like:
1. When does this problem actually show up?
Not “describe your workflow.” But “walk me through the last time this hurt.”
2. Is this about the task, or something breaking down around it?
Often what looks like “we need automation” is actually “our communication falls apart under pressure.”
3. If I built this tool, what would still be broken?
This question reveals the systematic issue hiding underneath.
4. What do you lose access to when things get hectic?
Usually it’s not information. It’s frameworks, principles, domain expertise, or the ability to think strategically instead of reactively.
The Reframe
Instead of: “Build me a tool to do [X]” Ask: “What knowledge, principles, or decision frameworks need to show up at specific pressure points?” This shift changes everything:
- Not a comprehensive knowledge base -> A companion that surfaces client context at project kickoff
- Not automated status reports -> A check-in assistant that catches misalignment before it compounds
- Not an onboarding system -> A domain expert companion that gives new specialists starter guidance when the team is too busy You’re designing for specific decision moments where thinking breaks down, not trying to automate entire workflows.
The Netflix Effect
Here’s where it gets interesting: Even a well-designed AI companion creates its own abundance problem. Ask it for strategic options and it will generate ten thoughtful approaches in seconds. More perspectives than you could brainstorm solo in an hour. This is the Netflix effect at a new elevation. The companion amplifies your thinking, but it can’t choose for you. It offers lenses, reframes, reminders of optionality. You still need your expertise and context to curate:
- Which options fit this specific client?
- Which paths work with this team’s capacity?
- Which approaches are feasible given this timeline?
- Which ideas should you combine, adapt, or ignore entirely? The AI surfaces abundance. You bring judgment shaped by context, constraints, and lived experience.
A Simple Test: The “Elevation Check”
Before building any AI solution, run it through this: Can you name the specific moment where thinking breaks down?
- Not “teams need more knowledge” but “teams are jumping project to project, context to context, back to back meetings with no time for critical thinking or depth work”
- Not “communication is hard” but “stakeholder expectations drift between kickoff and mid-project review” Can you describe what should show up at that moment?
- Domain expertise they don’t have time to build?
- Strategic frameworks they forget under pressure?
- Decision principles that get lost in reactive mode? Is this the minimum intervention that fixes that specific break?
- Not a comprehensive platform
- Not a Swiss Army knife tool
- A targeted companion for that exact pressure point If you can’t answer these clearly, you’re not ready to build yet. Go back to diagnosis.
What I’m Still Learning
I don’t have this mastered. I still catch myself slipping into “let me just build something” mode. But the pattern holds: Most tool requests are systematic issues showing up as tactical pain. The leader who can diagnose where thinking breaks down, identify what knowledge needs to show up at those moments, and design minimal AI interventions–that’s who creates real leverage. Not the person who builds the most tools. The person who solves the right problems with surgical precision. And then brings enough domain expertise to curate wisely when those tools offer more options than anyone can execute.
Try This
Next time someone asks you to build an AI tool:
- Pause. Ask diagnostic questions first.
- Look for emotional language (“wasted,” “drowning,” “exhausting,” “tedious” – that last one is especially triggering because it has my name in it, and it’s screaming at something deeper).
- Map the specific decision moment where thinking breaks down.
- Design the minimum AI intervention for that exact pressure point.
- Remember: the companion will offer abundance. Your job is curation. When using AI companions yourself:
- Expect more options than you can execute. That’s the feature.
- Treat outputs as lenses, not answers.
- Ask: “Which paths fit our reality?” Not “Which is theoretically best?”
- Combine, adapt, ignore based on context the AI doesn’t have.
The Humbling Part
The biggest shift was letting go of my need to be the “AI tool builder” and becoming the “problem diagnostician.” Tools are easy to build. Naming the real problem? That’s the hard work. And it’s where the actual leverage lives. I still trip into complexity. I still want to build the comprehensive solution. But when I catch myself, I go back to the diagnostic questions. That’s where clarity emerges.