A small AI team should build the requirement that blocks a paid, repeatable deployment and can become a reusable product capability. Treat every other request as a service commitment, a partner process, or a reason to walk away until the buyer can show that it belongs in the deal and in the roadmap.
The call that looked like three markets at once
Consider Tunde, a founder in Yaba, at 6:40 p.m. with his laptop open beside a paper cup of cold coffee. His team had spent months building an AI workflow that helped operations staff sort incoming requests and prepare a first response. A buyer wanted a pilot.
The buyer’s Lagos team asked for a local person they could call when a queue stalled. Procurement in Berlin sent a supplier questionnaire with pages of security and contracting requirements. Their US colleagues wanted the product hosted in a particular environment before any customer data entered the system.
Each request sounded reasonable on its own. Together, they could consume the next quarter.
Tunde had two engineers. One was already fixing an evaluation problem that caused the model to sound confident when it should have handed work back to a person. The other had started the integration the pilot needed. If the team took every requirement as product work, the pilot could slip until the buyer’s budget moved elsewhere. If they refused too quickly, they could lose the first enterprise deal that had reached this far.
The danger was not that the team would choose the wrong country. The danger was building three separate products around one buyer’s internal map.
Separate the buying requirement from the product requirement
A local support contact can be essential to a Lagos buyer without requiring a Lagos support operation. Procurement paperwork in Berlin can be necessary to get a contract signed without shaping the core user experience. A US hosting request may be a genuine product requirement, or it may be a policy preference that only matters for this account.
The first job is to name the request accurately.
Ask what fails if the team does not build it. If the answer is, “The buyer cannot legally or operationally use the product,” it deserves serious product attention. If the answer is, “Their procurement process cannot approve a new vendor,” it may need a focused sales and legal response instead. If the answer is, “Our local team would feel more comfortable,” the team should find the smallest credible way to provide that confidence.
This distinction protects limited runway. It also produces a clearer conversation with the buyer. “We can provide a named escalation contact during the pilot” is a real commitment. “We are building local support in every market” is a promise that can quietly become payroll, coverage gaps, and missed product work.
The same applies to hosting. Before moving infrastructure, ask who needs the requirement, what data it covers, whether it applies to the pilot or a future rollout, and whether the buyer will commit once it is met. A request that stays vague after those questions belongs in discovery, not in an engineering sprint.
Make the buyer show the path to revenue
Tunde did not need a framework with twelve boxes. He needed evidence.
He went back to the buyer with a short list: which requirements were mandatory before a pilot, who owned each answer internally, and what would happen after the pilot if the team met them. The local support request became a named operating arrangement for the pilot. The Berlin questionnaire went to a workstream with a clear owner. The US hosting requirement stayed open until the buyer clarified whether it was required for the initial data set.
That last point mattered. A team can spend weeks satisfying a requirement that nobody has authority to enforce.
This is where founders often confuse buyer seriousness with buyer volume. A long requirements document shows that a company has processes. It does not show that a budget owner will choose the product when the process ends.
Ask for the commercial counterpart to every expensive request. It could be a signed pilot scope, a defined decision date, access to the people who will use the workflow, or a written path from pilot to rollout. The commitment does not need to be theatrical. It needs to be concrete enough that the team can see what it is buying with its time.
This is also why a customer map matters. In The Customer Map an AI Startup Cannot Afford to Lose, the central risk is losing sight of who owns the work, the budget, and the outcome. Cross border enterprise deals make that map more important, because the person requesting the feature may sit far from the person who can approve the purchase.
Build the capability that survives this buyer
The useful test is simple: if this buyer disappeared tomorrow, would another target customer still need what we built?
A security control that protects every deployment may survive. Better audit records may survive. A configurable data boundary may survive. A custom approval sequence written around one procurement team’s habits probably will not.
Tunde’s team chose to keep the model evaluation work moving. They built only the deployment controls that they could explain as part of a broader product direction. They documented the remaining buyer requests as conditions for the next stage, with owners and dates on both sides.
The pilot started with a narrower workflow than the buyer first imagined. That was the turn. Instead of waiting for a perfect international operating model, both teams had a live process to evaluate. The buyer could see where local support mattered. Tunde could see which hosting and governance requirements appeared in actual use rather than in a spreadsheet.
A month later, his engineers were still working from one roadmap. The inbox held open procurement questions, but the product had not fractured around them.
That discipline matters as African technology companies navigate a period where consolidation is part of the growth conversation. A small team cannot treat every large buyer’s geography as a command to expand. Build for the repeated constraint. Handle the rest with clear operating agreements. Protect the product until the revenue case is strong enough to change it.
Comments
No comments yet.