I’ve been in a lot of project kickoffs. Across companies of different sizes, industries, and levels of technical maturity, there is one phrase that appears with the regularity of a heartbeat and the specificity of a fortune cookie: “We want to leverage AI to streamline our operations.”
Okay. Which operations? Which part of them? What does streamlined mean? What does it mean in terms of time saved, money saved, errors prevented, decisions improved? Who will use this system? Who will own it? What happens when it’s wrong?
These questions are met, almost invariably, with a look that suggests I am missing the point. The point, apparently, is the AI. The streamlining is assumed to be self-evident. The operations are “you know, the ones.” We will define success later, once we’ve seen what the AI can do.
This is not a project. This is a mood board with a budget attached.
The Conversation That Doesn’t Happen
There is a specific discovery conversation that should precede every AI integration project. It is not glamorous. It does not involve choosing between models or discussing agent architectures. It is tedious, methodical, and saves more money than any engineering decision made afterward.
The questions go like this: What is the workflow this will touch — specifically, step by step? Which step in that workflow is the bottleneck? What does success look like, and how will you measure it six months from now? What is the cost of an error — financially, operationally, reputationally? Who reviews the output and what authority do they have to override it? What data does this need and where does that data actually live?
Most clients have partial answers to most of these questions. Almost none have complete answers to all of them. The act of working through the complete answers is not a preliminary inconvenience before the real work begins. It is the real work. The engineering that follows is just implementation of decisions that should already have been made.
I’ve rebuilt the same AI integration twice on two separate engagements because a critical business rule surfaced in week six that would have been surfaced in hour two if someone had asked. The hourly rate for rebuilding week-six architecture is, I’ll note, considerably higher than the hourly rate for the two-hour discovery conversation that would have made it unnecessary.
Why Everyone Skips It
Because it is not exciting. Because executives want to see demos, not questions. Because questions feel like doubt and doubt is not the energy you want in a kickoff meeting where someone has just approved a meaningful budget to do something new and important with AI.
Also because the questions are frequently uncomfortable. “What happens when the AI is wrong?” implies that the AI will be wrong, which implies that the person who approved this project may be answering for that in front of their VP. Nobody leads with that slide.
The technical team skips it because they want to build, not scope. The client skips it because they want to see progress, not prerequisites. Everyone arrives at week seven when the first meaningful user test reveals that the system addresses the right process and the wrong sub-process, and the requirements need to be revisited, and the sprint needs to be unplanned, and the uncomfortable truth is that this moment was completely predictable from the information available in week one.
The projects that run on time are, with very few exceptions, the projects that took the longest to start. Not because slowness is a virtue, but because the people who insist on the two-hour discovery conversation are also the people who refuse to build something they don’t fully understand. Those are correlated properties in an engineer. Both are valuable.
The Five Questions That Actually Matter
You can run a meaningful discovery in two hours if you’re disciplined about it. The questions that actually determine whether a project will succeed or not are not about technology. They are:
What decision does this need to make, or what task does it need to execute? Not the category — the specific thing. Not “improve customer service” but “classify inbound support tickets into these seven categories with this field in the CRM updated automatically.”
What is the measurable definition of success? Not “better” or “faster” or “more efficient.” A number. A time. A rate. “Ticket classification accuracy above 92%” or “PR opened within 4 hours of ticket assignment 80% of the time.” Something you can put in a dashboard.
What is the acceptable failure rate, and what happens when it’s exceeded? AI systems fail. The question is not whether but how often and with what consequence. An error rate of 3% is acceptable in one context and catastrophic in another. Defining this upfront determines the entire architecture.
Where does the data actually live? Not where it theoretically lives. Where it actually is, in what format, with what access controls, with what quality issues, with what update frequency. The answer to this question has ended more AI projects than any model limitation.
Who owns the output? If the agent makes a decision and it’s wrong, who is responsible for it? Who has authority to override it? Who will monitor it? The answer to this question determines whether you need a full autonomous pipeline or a human-in-the-loop design — which are architecturally quite different and should not be decided in week five by implication.
The Part That’s Actually My Job
I’ll be direct about something: the discovery conversation is not a bureaucratic prerequisite to the interesting work. It is the foundation that determines whether the interesting work produces something that survives contact with reality.
The best AI systems I’ve built — the ones that are still running, still accurate, still generating value a year after deployment — all started with someone being willing to sit in a room and answer uncomfortable questions before anyone wrote a line of code. The worst ones started with a brief, a handshake, and the shared optimistic assumption that requirements would “emerge during development.”
They do emerge during development. At the worst possible moment, in the most expensive possible way.
Ask the questions first. Build the thing second. The questions are not the delay — they’re the architecture.