When your customer agrees to a pilot, they expect the product to deliver the outcome. But in many cases, especially with early-stage AI products, what they really expect is you, the founder, to personally ensure that outcome, even if it means stepping in for the AI. This misunderstanding, if not addressed, can derail a pilot before it truly begins.
In March 1907, a 31-year-old Winston Churchill, then Under-Secretary of State for the Colonies, embarked on a tour of British East Africa and Uganda. His official purpose was to assess the progress of the Uganda Railway and the economic potential of the region. Unofficially, he was a politician building his profile, and the journey offered a compelling narrative. His published account, My African Journey, details his observations, but one particular episode, recounted by historian R.W. Lewis in Churchill: A Life, highlights the gap between intended system and actual expectation. During a stop in what is now Kenya, Churchill participated in a hunting expedition. The local guides, accustomed to serving European gentry, had a particular expectation: they assumed Churchill, as the "great man," would personally bring down the most impressive game. The railway and the modern rifles were mere tools; the true outcome, the impressive trophy, was to be secured by the principal. Churchill, for his part, was likely focused on the experience, perhaps even the novelty of the hunting party itself, rather than the raw delivery of a kill by his own hand. The system (guides, weapons, trackers) was supposed to deliver the hunt; the unstated expectation was that the distinguished guest's personal prowess would guarantee the prize.
The Unspoken Mandate: From Product to Person
We landed a pilot with a logistics company in Accra, Ghana, on a Friday. The contract was signed, the scope clear: our AI would automate their freight documentation, reducing human error and processing time. Monday morning, in our kickoff call, the operations manager, Mr. Nketiah, expressed his excitement. "This is fantastic," he said, "because it means Alfred will personally oversee every document until it’s perfect, right?" The question hung in the air. The pilot, in his mind, was not a test of our AI product's capabilities alone. It was a guarantee of outcome, personally underwritten by the founder. His expectation was a manual white-glove service, powered by our expertise, not a self-sufficient AI agent.
This isn't a failure of communication on the customer's part; it is a common, often unstated, assumption when a new, complex technology like AI is introduced, especially by a small team. When Churchill embarked on his African journey, the local guides saw him not just as a participant in the hunt, but as its ultimate guarantor. Similarly, Mr. Nketiah saw our AI not as a standalone solution, but as an extension of my personal commitment to his business’s success. The gap between what the product can do and what the founder is expected to personally ensure is the critical distinction.
Why This Expectation Forms, and What to Do
Customers in early pilots often view the founder as a feature. This is particularly true in markets where personal relationships and trust carry immense weight, and for solutions that promise to automate tasks previously performed by humans. They are not buying a black box; they are buying the founder's perceived expertise and dedication to solving their specific problem. This isn't necessarily negative, but it means founders must be explicit about the product's boundaries and their own role.
The instinct might be to lean into this, to personally deliver for every pilot. However, this path leads to an unscalable service business, not a product company. The challenge is to manage this expectation without breaking trust or losing the pilot.
Setting Realistic Expectations
The conversation with Mr. Nketiah, much like Churchill’s implicit understanding with his guides, required clarification. I explained that while I would be deeply involved in monitoring the pilot's performance and gathering feedback, the delivery of the automated documentation would be handled by the AI and our dedicated support team, who were trained to intervene only when the AI genuinely needed assistance. We mapped out clear escalation paths for issues the AI couldn't resolve, and defined the metrics for success, ensuring they were tied to the AI's performance, not my personal hours.
This explicit boundary-setting is crucial. It means having an honest conversation about what the AI handles, where human intervention is designed, and what the founder's role truly is. It shifts the customer's mental model from "founder delivers outcome" to "product delivers outcome, supported by the founder's vision and team." Without this conversation, every successful pilot becomes a manual chore, every failure a personal one. The very reason you built an AI product is to scale beyond your personal capacity, but the customer may be unknowingly trying to anchor you to their specific outcome.
The Cost of Unmanaged Assumptions
If we hadn't addressed Mr. Nketiah's assumption, the pilot would have either consumed my entire week or failed to meet his unstated expectation. It would have led to frustration on both sides: him expecting me, and me expecting the AI to prove its worth. Just as Churchill's hunting party would have been disappointed if he had merely observed from afar, our logistics partner would have felt underserved if the AI didn't live up to the unspoken personal guarantee. This is a common pitfall in AI Demo Reliability: What a No-Rescue Test Taught Kojo About Human Review, where the limits of automation need clear definition. The success of an AI product isn't just about its technical capabilities; it's about aligning customer expectations with its actual operational boundaries.
Comments
No comments yet.