A prospective customer often cannot evaluate an infrastructure product until it connects to the system they already use. When that request arrives before the planned core release, the Friday decision is whether to build a narrow connector now or protect the roadmap.
The demo stopped at the boundary
By 4:40 on Friday afternoon, Kojo was holding a coffee he had forgotten to drink while a prospective customer shared their screen from an office in Accra.
The product worked. The workflow ran. Data moved through the new infrastructure exactly as Kojo had designed it.
Then the customer opened their existing system.
The demo stopped at the boundary.
Their team could not send real data into the product without a connector Kojo had not planned to build yet. A mock file would show the interface, but it would not answer the customer’s actual question: what happens when this runs inside our current operation?
Kojo had two options. He could spend the weekend building a narrow connector and risk pushing the core release into the following week. Or he could protect the roadmap, offer another simulated demo, and accept that the customer might decide the product was too early to evaluate.
The second option was still possible on Monday morning. That was the uncomfortable part.
The request changed the product decision
Infrastructure products are often judged at the point where they meet existing systems. Buyers rarely experience the product in isolation. They experience the handoff between what they already have and what you are asking them to adopt.
That handoff carries the risk.
A connector request can look like custom work, especially when it arrives before the product is ready. Sometimes it is custom work. Sometimes it is the first evidence that the planned product boundary is wrong.
Kojo’s original release focused on the core path: reliable processing, clear failure states, and enough visibility to understand what the system was doing. Those were sensible priorities. The connector request did not erase them.
It exposed a missing condition for evaluation.
The customer did not need every integration. They needed one narrow path through their existing system, with enough real behavior to decide whether the infrastructure deserved a pilot. Building that path could produce more useful evidence than polishing another internal screen.
That distinction mattered. Kojo was not deciding between “customer work” and “product work.” He was deciding which piece of work would answer the next business question.
The narrow connector was the release
At 6:15, Kojo cut the connector down to one input, one output, and the specific failure case the customer had raised. No broad integration layer. No promise that every future customer would work the same way.
The scope fit on one page.
He wrote down what the connector would prove:
- whether the customer’s data could enter the system without manual repair;
- whether the output could return to their existing workflow;
- whether the failure message gave their team enough information to act.
Everything else stayed out.
This is where infrastructure work becomes difficult for small teams. A request can pull the product toward one buyer’s environment, while the roadmap is trying to create something repeatable. The answer is rarely to accept every request or reject every request. It is to define the smallest experiment that separates a real product requirement from a customer-specific convenience.
By Saturday evening, Kojo had a working path. It was limited and slightly awkward. That was useful. The rough edges showed where the product depended on assumptions the team had not tested.
On Monday, the customer evaluated the product through their own system. They found a failure the mock demo would have hidden. Kojo fixed the failure, documented the boundary, and learned that the connector needed one extra validation step before any pilot could proceed.
The pilot was still not guaranteed. But the decision had moved from “Can we imagine using this?” to “What would it take to run this safely?”
Protect the roadmap by testing the boundary
A fast connector earns its place when it creates evidence about adoption, reliability, or scope. It becomes a trap when it quietly turns the product into a collection of one-off requests.
Before agreeing to build one, I would write three sentences:
The customer cannot evaluate the product because this boundary is missing.
This narrow connector will test this specific assumption.
If the test succeeds, we will either productise the boundary or deliberately keep it outside the core release.
That last sentence protects the roadmap. It gives the team a way to learn without pretending every integration belongs in the product forever.
Kojo returned to the core release the following week with a better definition of “done.” The release was no longer only about the system working internally. It also had to show where the system could meet a customer’s existing operation, what happened when the handoff failed, and which parts were worth supporting repeatedly.
The connector did not replace the roadmap. It gave the roadmap evidence.
When a request arrives before the demo, ask what the customer is unable to judge without it. If the answer is specific, build the smallest path that makes that judgment possible. Then decide from what you learn, while the choice is still visible.
Comments
No comments yet.