Expectations Management

Most disappointment isn’t a failure of execution. It’s a gap between what someone thought they were getting and what was actually agreed to, and that gap gets created long before any work starts.

I see this most clearly in AI and automation projects, because the gap there is wide by default. A client hears “AI agent” and pictures something that understands their business the way they would, or at least how a seasoned employee would. What they’re actually getting, on day one, is a system that’s good at the thing it was built and trained for, nothing more. If nobody names that difference out loud before the build starts, the client isn’t disappointed by the technology. They’re disappointed by a target they set for themselves that no one corrected.

The fix isn’t better execution. It’s a five-minute conversation before anything gets built: here’s what this will do, here’s what it won’t, here’s what “done” looks like when we’re finished. That conversation feels like it slows things down. It doesn’t. It moves the hard conversation from after delivery, when it costs trust, to before delivery, when it costs five minutes.

I run this same discipline internally, not just with clients. When I hand a task to an agent or to a person on a project, I try to state the actual target before work starts, not just the request. “Build me a report” and “build me a report a non-technical exec can read in two minutes and act on” produce different work, and only one of those was ever going to match what I actually wanted. Skipping that sentence doesn’t save time. It just moves the cost to a rework cycle later, dressed up as a quality problem instead of what it actually was: an expectation nobody set.

Set the expectation upfront. It’s the cheapest thing you’ll do on the entire engagement, and skipping it will cost you multitudes in the long run.