Unexpected overseas demand should trigger a focused test, not an immediate rewrite of the product. An African founder can serve the new buyer without abandoning the original vision by separating the customer’s underlying problem from the customization they request.
At 11:18 p.m. in Accra, Kofi was preparing to close his laptop when an email arrived from a procurement manager in Rotterdam. The sender wanted a demonstration of the inventory tool Kofi and his small team had built for independent retailers in Ghana. She also wanted three changes before she could recommend it internally.
Kofi, an illustrative composite of founders I have encountered across markets, read the message twice. The possible contract could cover months of development. But accepting it might turn a focused product into a custom system for one distant buyer.
His team had enough money for the current quarter. After that, the choices narrowed quickly. If he refused the request and local sales remained slow, he could lose two engineers. If he agreed, the overseas buyer could pull the roadmap toward workflows his original customers would never use.
For a few minutes, both decisions looked irresponsible.
The request behind the requested feature
The email asked for approval layers, reporting fields and integration with an internal purchasing system. Kofi’s first instinct was to estimate each item. That would have been premature.
A customer’s requested feature often describes the solution they can imagine, not the full problem they need solved. Founders hear “add another approval step” and start drawing screens. A better first question is: what failure are you trying to prevent?
The Rotterdam team was worried about stock movements nobody could explain at month-end. That concern was familiar. Retailers in Accra described it differently, usually through missing items, handwritten corrections and arguments over which record was current. The language changed across continents. The underlying job remained close: establish who changed what, when they changed it and why.
That distinction gave Kofi room to think. He did not need to choose between dismissing the buyer and copying her specification. He needed to find the shared problem beneath both markets.
This is where founder judgment matters more than geographical instinct. Overseas demand can feel like validation because it arrives from a market associated with larger budgets. It can also feel like betrayal if the product began with a local problem. Neither feeling should set the roadmap.
Protect the product boundary before discussing scope
The next morning, Kofi wrote two columns on a whiteboard. One held capabilities that would strengthen the product for every customer: clearer change histories, configurable permissions and better exports. The other held work specific to one company’s internal systems.
That boundary changed the conversation.
He offered to demonstrate the existing product, explore the common control problem and discuss the first column. He would only consider company-specific integration after confirming commercial terms, implementation effort and ongoing maintenance. The message was polite, but it removed the assumption that interest entitled the buyer to redesign the product.
This approach matters because custom work carries costs beyond development. Every exception needs testing. Every special field enters support conversations. Every integration can break when another system changes. Revenue may arrive once while the maintenance obligation stays.
The same discipline applies when building across African, European and US markets. Geography can influence payments, connectivity, regulation, purchasing habits and expectations. It should not become a shortcut for assuming every customer in a region behaves alike. Start with observed constraints. Then decide which differences belong in configuration, which justify a product capability and which should remain outside the boundary.
That reasoning also appears in Malik’s fleet system test, where a two-continent opportunity exposes what the product must prove before expansion becomes credible.
Use payment to distinguish demand from curiosity
A positive email is evidence of interest. It says little about willingness to buy, tolerate the current product or commit internal time.
Kofi proposed a paid discovery phase with a defined outcome: map the buyer’s stock-control workflow, test the existing product against it and identify the smallest reusable changes. Payment mattered less as revenue than as a signal. The buyer would need to assign people, share real constraints and put a budget behind the problem.
Had she declined, Kofi would still have learned something valuable without moving his team’s roadmap. If she accepted, he would gain evidence stronger than praise during a demonstration.
Founders can apply the same filter with three tests:
- Does the problem appear among customers we already serve?
- Can the solution become a reusable product capability?
- Will the interested buyer commit money or meaningful effort before we build it?
A request that fails all three tests is probably a distraction. One that passes two deserves investigation. A request that passes all three may reveal a larger market hiding inside a customer email.
Let the evidence widen the vision
Two days before Kofi planned to freeze the next development cycle, the procurement manager accepted the paid discovery proposal. She also agreed to begin with the existing product rather than make every requested change a condition of the trial.
That was the turn. Kofi kept his engineers, at least for the immediate cycle, and protected the product boundary. More importantly, he gained a way to learn from overseas demand without treating a single buyer as a new strategy.
The original vision did not need to stay geographically narrow to remain intact. Its durable core was the problem: helping operators trust the record in front of them. Accra had revealed that problem first. Rotterdam had described another version of it.
On Friday afternoon, the whiteboard still had two columns. Only three items moved into the roadmap, each useful to the retailers the product had been built for. The integration request stayed where it belonged, outside the line.
Comments
No comments yet.