What Discovery Actually Requires
How discovery is done determines what gets found — and what gets found determines what you can actually build with AI.
My sister Lyn is a patient advocate. When my mother found a lump in her breast, the referral she got sent her to the wrong kind of doctor entirely — a specialist who had nothing to do with breast health.
Lyn didn't argue with the referral. She asked the receptionist a different question: "If your mother had a lump, who would you take her to?" She got a private call with three real names.
At the appointment with the right doctor, Lyn noticed something in my mother's chart that connected two things the doctors hadn't put together. She asked about my mother's other breast — the one nobody was there for. The doctor ordered an MRI.
Three spots in the other breast. Cancer, caught nearly a decade before it would have become something serious.
Lyn describes how she works: "It's things I have no idea are going to come up. I'm taking in my surroundings and what's going on in the conversation, and I come up with these questions without knowing what the question is."
That question — the one she didn't know she was going to ask — is exactly what AI transformation discovery is looking for. And almost never gets.
Documentation Is Not Discovery
Every organization has two versions of how work actually happens.
The first is the official version: the one explained in onboarding, described in meetings, drawn on process maps. Clean, sequential, logical. People have said it so many times it no longer sounds like a description. It sounds like policy.
The second version is what's actually happening. The workaround everyone uses without thinking about it. The judgment call made dozens of times a day that never got written down because it stopped feeling like a decision. The step that regularly stalls because someone specific isn't available, and the official process doesn't account for that.
A 2020 HBR study on digital transformation put the instruction plainly:
Look for what isn't quite working in your operation. Where do you regularly need workarounds or have to stop a process unexpectedly to fetch more information or involve another person?
Those workarounds are not inefficiencies to eliminate. They're signals. They're where the official version diverges from the real one — and where the real intelligence of the process lives.
Every process has two versions. Discovery determines which one AI gets built on.
When discovery surfaces the first version and not the second, the AI handles the documented steps correctly and quietly passes over the judgment, context, and implicit expertise that make those steps actually work. The output is technically correct and contextually incomplete. The team notices. They conclude the AI isn't capable enough. The real problem — thin discovery — never gets examined.
You Can't Prepare the Right Question
In the early 2000s, GE Healthcare engineer Doug Dietz spent years building an MRI machine he was proud of. Then he visited a hospital and watched a child walk toward it.
She was terrified. Sedation rates for pediatric MRI patients were above 90% — not because of the procedure, but because of the experience.
Dietz didn't ask patients how they'd improve MRI. He spent time with children. Heard their stories. Learned how they played and what made them feel brave. What he found: kids don't need calm. They need adventure.
The result was the Adventure Series: MRI suites became pirate ships and space stations. Sedation rates dropped to under 10%.
The insight that changed everything wasn't on anyone's checklist. It came from someone who was actually listening.
Harvard Business School research on thousands of natural conversations found something counterintuitive: the most powerful questions in a discovery session can't be prepared in advance.
Follow-up questions seem to have special power. They signal to your conversation partner that you are listening, care, and want to know more.
You can only follow up on what you just heard. Which means the right next question is only available to someone who walked in without a conclusion already waiting.
Steven Baert, former Chief People Officer at Novartis, named what most discovery interviews are doing instead:
"Previously [I focused on] listening to fix. 'You have a problem. I need a few points of data from you so I can solve the problem.' [But now] I'm practicing listening to learn."
Listening to fix already has the answer. It's collecting confirmation. Listening to learn is what surfaces the second version of the process — the real one.
What Discovery Actually Captures
The goal of a real discovery interview isn't a process map with more detail. It's a complete picture of how work actually lives inside the people doing it.
That means going further than steps and handoffs. It means understanding:
What people experience. Which parts of this process do they genuinely enjoy — the parts that feel like the real work they were hired to do? Which parts do they dread? Which feel necessary and which feel like overhead they've quietly resented for years?
How decisions actually get made. Not what the decision tree says. What does someone consider when something unexpected happens mid-task? What signals tell them to escalate versus handle it themselves? When do they trust their judgment and when do they check with someone else?
What people actually want to be doing. Not a leading question — a real one. What would this job look like if they could design it? What kind of work makes them feel good at the end of the day? What are they not doing right now that they wish they were?
Why they think each step exists. Some steps are genuinely necessary. Some are legacy. Some are there because someone who left three years ago needed them, and nobody has questioned it since. The person doing the work usually knows the difference. Nobody asked.
And then: all the follow-up questions in between. The ones that only become visible after the previous answer. That's where the second version lives.
Robin Dreeke spent his career as an FBI counterintelligence agent building trust quickly and getting people to share things they hadn't planned to share. In Warren Berger's The Book of Beautiful Questions, he described the prerequisite for this kind of listening:
"Am I genuinely interested in the other person? Am I able to put my ego aside and suspend all judgment? Am I prepared to truly listen, as opposed to just acting as if I am listening?"
Before you end every discovery conversation, ask the question that almost never gets asked: what didn't we talk about that would matter most? What are you not saying because you weren't sure it was relevant?
That's where Lyn lives. In the question that wasn't on the intake form.
Who Does This — and How Long It Takes
Most people weren't trained to do this kind of listening. That's not a failure — it's the norm. Most of us learned to come in with an agenda, run through it efficiently, and leave with clear notes. Following the conversation instead of the script is a different skill, and developing it takes practice and a specific kind of attention that most teams haven't been asked to build.
This is why discovery, at the start, needs someone from the outside.
An external person can see what your team has stopped seeing. They don't know which workarounds are "just how it is." They aren't carrying the organizational assumptions that make the second version invisible. They can ask the naive question — and mean it. They can notice the pause, follow the aside, and stay in the question long enough to find the one nobody knew to ask.
But the goal isn't permanent dependence on that outside person. It's the opposite.
The best engagements work like this: the consultant runs the first discovery rounds with your team alongside them, and makes every step visible as they go. The questions they ask, the patterns they're listening for, the moment they decide to follow a thread instead of moving on — all of it gets named explicitly. Your team watches, participates, and starts to build the muscle. After several rounds, they can do this without outside help.
That's the real deliverable: not just findings, but internal capability. The ability to keep doing this as the work evolves, as AI capabilities change, as new processes get built. This is also why AI adoption keeps stalling. Everyone can see what AI can theoretically do. Far fewer organizations have built the internal skill to know where it actually belongs — which requires understanding your own processes deeply enough to make that call. Discovery is the practice that builds that muscle. The upskilling isn't separate from the transformation. It's inside it.
As a rough guide: thorough discovery for one process — talking to multiple people, documenting what's stated and what's revealed — takes about a month. Design thinking and prototyping takes another two to four weeks. Building and testing takes roughly another month. One workflow, end to end: three months. And that doesn't include the pre-work that has to happen before discovery even starts: leadership alignment, a communications plan, change management, getting the champions team in place. That comes first. Discovery without organizational buy-in produces findings nobody acts on.
The timeline sounds long. It isn't, relative to what it replaces. A lot of AI transformations are failing right now — not because the tools don't work, but because they were built on the wrong picture of the work. The budget that goes into an implementation that doesn't stick dwarfs the investment in doing discovery right.
What Transforms vs. What Merely Improves
Jeremy Utley and Perry Klebahn, in Ideaflow, make an observation that applies equally here: "Ideaflow depends on inputs reaching a receptive mind." What comes out is determined by what goes in.
When discovery inputs are thin — official processes, prepared answers, the stated version — AI outputs are thin. You get faster documentation. Incrementally cheaper workflows. A slightly smoother version of the process you already had. That's useful. It's not transformation.
When discovery goes deep enough to find the real version — the judgment behind the steps, the expertise that's never been written down, the intelligence that makes the official process actually work — something different becomes possible.
You're no longer incrementally improving a process. You're building something that reflects how your people actually think.
Best Buy survived the Amazon threat not by optimizing its existing retail model, but by discovering what customers actually needed — something no process map would have revealed. When customers said they felt overwhelmed by technology, the obvious response was: improve the store. Better layout, clearer signage, faster checkout.
But that wasn't the insight. Customers didn't need a better retail experience at all. They needed someone to help them figure out what to buy, set it up at home, and fix it when it broke. They needed expertise, on demand, in their lives — not in a store. That discovery led to Geek Squad, in-home services, and an advisory model that turned Best Buy's physical presence into an advantage instead of a liability. They found the right problem by starting with the person, not the process.
That's the difference between transformation and digitization. And it gets decided in discovery.
The leaders who've moved fastest on AI transformation did the slowest, most careful discovery. They found the real version. That's what told them where to build.
You can't automate your way to the right problem. You have to find it first.
If you're wondering where to start: one workflow, one outside set of eyes, and a commitment to go deep enough to find the version that isn't on the map. From there, you build the capability internally — through champions who carry the change, through role design that protects the judgment AI shouldn't replace, through upskilling that gives your team the language and the practice to keep doing this on their own. Discovery is the first step. Everything else builds on what it found.
That's what the rest of this series is about.
Sources
The Book of Beautiful Questions — Warren Berger
Ideaflow: The Only Business Metric That Matters — Jeremy Utley & Perry Klebahn
GE Healthcare Adventure Series / Doug Dietz