A founder with six months of runway should accept both pilots only if the same product can serve both customers without separate core workflows, data models or delivery teams. Two signed pilots can look like validation while quietly committing the company to build two products.
At 4:46 on Friday afternoon, Kojo sat in a small office in Accra with two signed documents open on his laptop. The bank wanted an internal review assistant for policy documents. The logistics company wanted dispatch staff to ask questions about shipment records. Kojo, an illustrative composite, had spent the week waiting for either signature. Now he had both, and six months of company cash left.
By Monday, each customer expected a kickoff date. Declining either pilot could mean losing the contract. Accepting both could consume the runway before Kojo learned whether his original product had a repeatable market.
The signatures hid two different products
Both pilots included document ingestion, search and generated answers. On a pitch deck, the overlap looked substantial.
The bank needed controlled access, approval trails and answers tied closely to approved policy documents. A plausible answer with weak support could create a compliance problem.
The logistics company needed current operational records, fast responses and a workflow that dispatch staff could use while handling active shipments. An answer based on yesterday’s data could send someone in the wrong direction.
The shared AI layer was the least important part of the comparison. The products differed where failure would happen.
I have learned to inspect a pilot by tracing the customer’s critical decision. What information enters the system? Who can see it? How current must it be? What happens when the answer is wrong? Who reviews the result?
Kojo wrote those questions on paper and drew two columns. By the fourth row, the apparent overlap had disappeared. One pilot pulled the product toward governed knowledge retrieval. The other pulled it toward live operational support.
That was the Friday problem. Revenue from both contracts could extend the company’s life on paper, while the engineering obligations shortened its strategic life.
A signed pilot can still be bad evidence
A signature proves that one organisation will try a proposed solution under agreed conditions. It does not prove that the same product can be sold repeatedly.
Founders with limited runway often treat paid demand as automatically useful demand. I understand why. Salaries and cloud bills arrive on schedule. Product clarity does not.
But revenue has an acquisition cost inside the product. If each contract requires a new architecture, workflow and support pattern, the company earns money by adding permanent branches to the codebase. Every later sales call becomes a choice about which branch to extend.
This is the deeper risk behind pilots that require unsupported architecture. The first custom build may feel manageable. The second reveals that the company has started selling its team’s flexibility instead of a repeatable product.
Kojo’s bad ending remained possible: he could accept both pilots, hire contractors to meet both kickoff dates, and reach the end of six months with two satisfied organisations that wanted incompatible next versions. There would be activity, invoices and little evidence about what to build next.
The decision needed a product boundary
At 5:21, Kojo stopped comparing contract values and compared irreversible commitments.
The bank pilot required changes to access control and review history. Those capabilities could support the product direction he had already chosen. The logistics pilot required connections to changing operational records and a separate interface for dispatch work. That path might become a valuable company, but it demanded a different product thesis.
He called the logistics lead before the working day ended. He did not reject the problem. He narrowed the proposed pilot to a manual, time-limited discovery engagement that would test the dispatch decisions without promising a production integration.
The answer could still have been no. The signed pilot might disappear once the original scope changed.
That uncertainty mattered. If a customer only wants the work when you promise a separate product, the contract is telling you what it will cost, even when the commercial page shows revenue.
The logistics lead agreed to discuss the narrower scope on Monday. Kojo accepted the bank pilot and left the second signature untouched.
What to compare before accepting both
When two credible customers ask for different things, compare the product consequences before comparing the contract totals.
Write down the critical decision each customer expects the product to support. Then map the data source, required freshness, permissions, interface and consequence of error. Shared vocabulary such as “AI assistant” or “automation” does not establish meaningful product overlap.
Next, separate reversible delivery work from permanent product commitments. A temporary manual process can test demand. A new data model, security structure or operational interface changes what the company must maintain.
Finally, choose the pilot that produces evidence for the company you are trying to build. If the second opportunity is worth exploring, reduce its scope until it tests the uncertain assumption without funding an entire second roadmap. Kojo’s earlier choice between two credible requests follows the same pressure from another angle: demand can divide a company before the founder notices the organisational split.
On Monday morning, Kojo’s desk still held two signatures. Only one had become a product commitment. The other had become a question the company could afford to investigate.
Comments
No comments yet.