The Expert Who Walked Out the Door

I turned a departing expert's recordings into an AI you could ask questions. What happened next taught me more about adoption than the build ever could.

real project · told honestly, names withheld · 6 min read

Twenty years of knowledge, fifty hours of tape

Every company has one person who knows where the bodies are buried. We had exactly one for a critical product domain, and after twenty-plus years, that expert left.

The team building a new product in that domain inherited the leftovers: about fifty hours of meeting recordings. That was the whole estate. A gaping hole in the org chart and a pile of audio nobody was ever going to sit through.

The build was the easy part

I loaded the recordings into Google NotebookLM as source material. That choice mattered: NotebookLM only answers from the sources you give it, with citations back to the original, so the risk of made-up answers stays low. Ask why a design decision went the way it did years ago, and it answered from the expert's own words, and showed you where it got them.

The team could query it like a colleague. I demoed it, walked through the use cases: onboarding new people, checking old design decisions, asking "what would the expert say about this?" before committing to a direction.

It worked. Then the interesting part happened.

The part nobody puts in a case study

The team it was built for never worked it into their routine. Their manager liked it enough to present it at a company town hall. But day to day, it sat there.

If you have ever rolled out a tool, you know this moment. Most companies buy the tools first and ask why nobody uses them second. I had just done the homemade version of the same thing: built something that worked, aimed it at the people with the most obvious need, and watched it not get used.

A working tool, publicly praised, and still not adopted. Sit with that. It is the single most common failure in enterprise AI, and it has nothing to do with the technology.

The sideways ending

Here is the twist. The tool had been built for a team inside the VP of Product's own organization; I made it for one of her product managers. So while the team let it sit, she tried it herself.

Using it did what my demo could not. Ask a question, get an answer grounded in real sources, with the receipts to check it. She realized the value firsthand, and then adopted the approach for other uses: capturing project information in NotebookLM as something she could query with AI and trust.

So adoption happened. Just not where I aimed it, and not the way I pitched it.

What I do differently because of this

People don't adopt the best tool. They adopt when a felt need meets firsthand experience of the solution.

Building the system was days of work. The adoption came from a leader getting her hands on the tool and feeling the value, not from my demo and not from the town-hall applause. That inverted how I do AI enablement: the tool is the smallest part. The real work is engineering firsthand moments. Get the tool into the hands of someone with a felt need, and make the win visible. Pull does the rest.

Would I rather tell you a story where my system got adopted exactly as planned? Sure. But if you are trying to get AI adopted in your organization, this story is worth more. I have watched the failure mode from the inside, and I know what fixed it.

← back to work