Alfred AnyanInsights
← All insights

Kojo’s production-data access answer. Procurement could remove the product.

The stronger answer is a precise account of who can access production data, under what conditions, and how that access is reviewed. A smaller fintech team can win this question when its controls are clear enough for a buyer to assess without guessing.

At 4:40 p.m. in a meeting room in Accra, Kojo had one hand on a cooling cup of coffee and the other on the mute button. He was leading a small team selling a reconciliation product to a financial-services buyer. On the shared screen, their product and a larger competitor’s product had reached the same point: both could ingest files, flag exceptions, and produce the reporting view the operations team wanted.

Then the buyer’s risk lead asked, “Who on your team can access production data?”

Kojo had expected questions about integrations and implementation. He had not expected the call to turn on a sentence that short.

The buyer’s procurement review was due to move that week. If the team could not explain access clearly, the product could be removed before the commercial discussion even began. A good demo would not save it.

The answer has to describe actual access, not company intent

The larger competitor answered first. Their representative said access was “restricted to authorised personnel” and that security was a priority. None of it was necessarily false. None of it gave the risk lead enough to take back to an internal review.

Kojo paused his screen share and answered in the language his team had already used during its own production reviews.

He explained which roles could reach production systems, why those roles needed it, and what happened when someone needed temporary access beyond their normal permissions. He described the approval path, the record left behind, and the point at which access was removed. Where the team had a limitation, he named it plainly and said what they were doing about it.

That answer did not sound grand. It sounded like someone who had been responsible for deciding who could see a customer record at an inconvenient hour.

For a buyer, that distinction matters. “We take data seriously” asks them to trust your posture. “Only these people can access this environment, for these reasons, through this process” gives them something they can evaluate.

The small team had an advantage because its answer had fewer layers between the person making the promise and the people operating the system. That advantage disappears if the founder improvises on the call.

A production-data question is usually a decision-quality test

Buyers ask about production access because they are trying to understand how your team behaves when something goes wrong. They want to know whether an engineer can make an urgent fix without guardrails, whether support can inspect information they do not need, and whether anyone will know afterward what happened.

The question also reveals whether the team has separated a demo environment from the place where real customer information lives. That boundary can look obvious in a diagram and become messy when a sales deadline is close. A prospect asks for a realistic workflow. Someone suggests loading production-like records. An engineer needs to diagnose an issue quickly. Small exceptions accumulate.

The useful preparation is a short, shared description of reality. It should cover:

  • Which people or roles can access production data.
  • What each category of access is for.
  • How elevated or temporary access is approved and recorded.
  • How access changes when someone joins, changes roles, or leaves.
  • What the team cannot yet claim.

This is part of the same discipline behind asking where your model came from. A buyer is testing whether the system has a traceable chain of responsibility, from data source to production operation.

The smaller team’s answer works only when it has been earned

Kojo’s team had not created a perfect governance programme. They had made a series of smaller decisions before the sales call: limiting standing access, agreeing who could approve exceptions, and writing down the process after an incident exposed an ambiguity.

That last part matters. The team had once needed to investigate a customer issue late in the day, and the fastest path had involved access that was broader than the engineer needed. The issue was resolved, but the incident left a bad taste. The team changed the process because it did not want urgency to become an excuse for vague ownership.

On the call, Kojo did not use that incident as theatre. He used its result. The buyer did not need a story about flawless controls. They needed confidence that the team noticed weak spots and corrected them.

Later, the risk lead returned with a narrower question about a contractor helping with a component of the product. Kojo could answer that too, because the team had already decided what contractors could access and what they could not. The conversation moved forward.

That is the practical work behind credibility. A smaller company rarely wins by claiming to have the same machinery as a much larger one. It wins by making its boundaries legible.

Prepare the uncomfortable answers before the buyer needs them

Production-data access should be part of sales preparation, especially for fintech products where a buyer’s security, legal, and operations teams may each ask the question differently. The goal is consistency, not a memorised script.

Write a one-page internal answer. Have the person who runs the system review it, then have the person selling the system practise saying it without turning it into a policy recital. If a buyer asks a question the team cannot answer, do not fill the silence with broad assurances. Record it, find the owner, and return with a specific response.

The same habit helps when a buyer probes the operational ownership behind an AI feature. Human review and ownership are easier to discuss when the team has already decided where automated output stops and accountable judgment begins.

After the call, Kojo closed his laptop and sent the risk lead the written access summary they had prepared before the meeting. It was short enough to read, specific enough to circulate, and honest about the work still ahead. That gave the buyer a safer answer than confidence alone.

Comments

No comments yet.