Two credible customer requests reveal a category when they share the same underlying problem, buyer, and path to repeatable delivery. If each request needs different users, data, workflows, and sales arguments, you probably have two consulting opportunities competing for one runway.
At 9:12 on a Tuesday morning, Kojo sat in a small office in Accra with 11 months of runway and two proposal tabs open. Kojo is a composite founder, but the decision is familiar. One prospect wanted his AI product to read supplier documents and flag missing information. The other wanted it to summarize customer calls and draft follow-up tasks.
Both prospects had budget. Both wanted a pilot. Either contract could extend the company’s life.
Together, they looked like demand.
Two payments can hide two products
Kojo’s technical lead had already marked the requests as feasible. That answer worried him more than a flat no would have.
The supplier pilot needed document ingestion, field extraction, validation rules, and an approval screen. The call product needed transcription, account context, task generation, and a connection to the customer’s existing sales tools. The shared label was AI. Almost everything after that split.
Kojo could accept both and tell himself the product was becoming a broad assistant for business operations. That description would make the work sound coherent while his team built two separate systems.
The immediate danger was delivery. With a small team, one delayed integration could consume the margin from both pilots. The deeper danger was interpretation. Two signed contracts might persuade him to hire, expand the roadmap, and spend runway against a category that existed mainly in his invoices.
He had until the afternoon to tell both prospects whether he could meet their proposed timelines. Saying yes could bring cash in. Saying no to either could leave him watching the runway shrink with no replacement deal.
For a few minutes, the safest decision looked like accepting both.
Trace the constraint beneath each request
I have learned to distrust feature overlap when evaluating early demand. Two customers asking for summaries may still be buying relief from completely different risks.
The useful comparison starts beneath the requested feature.
Kojo wrote four lines under each opportunity: who feels the pain, who approves the spend, what event creates urgency, and what the customer does when the product produces an answer.
The supplier team faced a costly review step before approving an order. Their operations lead owned the problem and could judge whether a flagged document deserved attention. The sales team wanted cleaner follow-up after calls. A commercial lead owned that problem, and success depended on whether representatives trusted and used the generated tasks.
One request sat inside a controlled approval process. The other sat inside human habits and an existing sales workflow.
That difference mattered more than the fact that both used language models.
It is the same distinction behind what copying AI answers to WhatsApp taught Ama about decisions. The generated answer may be technically sound, yet the real product begins where someone must trust it, move it, approve it, or act on it.
Buy evidence before buying a category
Kojo changed the question from “Can we deliver both?” to “What would we learn from delivering each?”
The supplier pilot could test a reusable claim: a team receives inconsistent documents, checks them against known requirements, and needs a person to review exceptions before approving the next step. If that pattern appeared across other conversations, the company could reuse more than code. It could reuse the buyer, demonstration, onboarding process, success measure, and sales language.
The call-summary pilot offered less category evidence. The prospect wanted several adjustments tied to its current tools and internal habits. Another sales team might ask for a different destination, approval flow, or record structure. Revenue was possible, but repetition remained uncertain.
Kojo did not reject the second request because custom work is inherently bad. Custom work can fund learning. The problem begins when a founder records bespoke revenue as proof of a repeatable market.
A practical test is to remove the customer names from both requests and describe the decisions the product supports. If the same sentence still fits, you may have a category. If the description becomes so broad that it could cover half of business software, the overlap is cosmetic.
Before committing, Kojo asked each prospect for a narrower paid discovery step. He wanted sample inputs, the current manual process, the person responsible for the final decision, and one observable delivery test. That approach also protects against the failure described in the integration offer that would have cost a founder his roadmap.
The decision your runway can survive
By late afternoon, Kojo had chosen to pursue the supplier workflow first. He kept the second conversation open, but he removed its features from the product roadmap until the prospect could support a smaller, paid test.
He still had no proof of a category. He had something more useful than early certainty: a clear statement that another buyer could confirm or break.
The next morning, the two proposal tabs were still open. One had become a bounded pilot with a named decision, defined inputs, and a review step. The other had become a question rather than a promise.
With 11 months left, that distinction preserved more than engineering time. It stopped two credible requests from quietly becoming two companies.
Comments
No comments yet.