"Forced" is probably not the right word. "Pushed" might be better; though, it doesn't seem strong enough to create the right visual.
My team and I were on-site with a robotics company, planning for the next quarter. Over the previous year, we'd built a suite of internal tools for them: a powerful automated testing platform, an application for automating and tracking the configuration of physical components, and a tool to simplify testing obstacle detection software.
The client was extremely happy with what we'd delivered. So they brought us a new challenge: a better, more efficient way to analyze error reports. The existing process wasn't straightforward. It could take days, often pulling multiple engineers away from their regular work. This often resulted in robot downtime, costing our client and their customers money.
We jumped in. Got a room full of their stakeholders together, watched demos of the existing process, and dug into what they'd already tried. By the end of the day we had a shared direction: dramatically reduce the time it takes engineers to get to a root cause.
When we presented the proposal to the COO, he doubted the rules-based approach would justify the investment.
What we saw as an iterative approach to move the needle, he saw as only minor improvements. The client wanted something more dramatic. More innovative.
The client wanted AI.
Every experience I'd had with a client wanting an AI solution had gone the same way. Sometimes the problem wasn't real. More often, the problem was real, but the technology wasn't ready to meet it. The clients weren't wrong to want it. They just wanted it before it could actually deliver.
And so I found myself looking at a clear business problem that we believed AI could solve. Not being one to let my skepticism get in the way of progress, we began discovery.
In three days, we talked to 25 people: engineers, managers, people who'd been there for years and people who'd just started. We had AI recording and transcribing everything, generating daily summaries that helped us spot gaps and adjust our questions as we went. In the pockets between interviews, we were already prototyping. By the time we left, we had a roadmap and a defined MVP.
When we got back, my product designer Clement and I worked through everything we'd captured. With AI helping us make sense of it, we transformed a mountain of interview notes into user personas, an experience map, and a concrete list of feature ideas within days. Meanwhile, the engineers started building a proof of concept.
Within three weeks, we had something both functional and genuinely cool.
Users could upload .zip files and the system would extract the logs and send them to a reasoning model (we landed on Claude Sonnet, though we tested models across OpenAI, Gemini, and Claude) which would read a description file and examine the logs to understand the issue. The application would then deploy sub-agents, each specialized in different system components, to perform a deep investigation into what may have caused the incident. It generated artifacts to make the information easy to navigate: notes, a detective board, a timeline. It let users jump directly from a note to the log entry that inspired it.
But the coolest part? It worked.
The AI identified the root cause with fair consistency. Not every time, and we didn't expect it to, but often enough that we were confident it could dramatically reduce the time it takes engineers to get to a root cause. The proof of concept was compelling enough that we conducted seven demos in two weeks and started collecting feedback for a pilot release.
Here's the thing I keep coming back to, though: the COO was right.
Our first proposal wasn't ambitious enough. We'd anchored on what was safe and incremental when the problem actually had room for something more.
Being pushed to think bigger was uncomfortable. I won't pretend otherwise. I went into that discovery sprint genuinely unsure whether we could deliver, with a healthy amount of "I told you so" loaded and ready if it didn't pan out.
It panned out.
But the skeptic in my head was still there. How would users know they could trust what the AI was telling them? What tools did they have to quickly validate whether it was right? Would it actually save time if validation required all the same investigative steps as doing it themselves?
Here's what I've realized: those questions aren't doubts. They're the product requirements.
The COO was right to push harder. And the skeptic was right to keep asking. Sometimes you need both.