A funding headline can make a team mistake a delivery constraint for a capital problem. Before discussing a raise, identify the one promise your company cannot reliably keep with the people, time and customers it already has.
At 7:14 on a Wednesday morning, Kweku forwarded the news to his seven-person team: Nigerian mobility fintech Moove had become Africa’s latest unicorn after raising $250 million. His message said, “This changes what is possible.”
Kweku is an invented composite, but the decision is familiar. He runs an Accra software company that automates order reconciliation for distributors. He drinks his coffee cold, keeps sales calls on speaker while pacing, and has enough runway to make every hiring decision feel permanent.
By the 9:00 stand-up, the team was discussing a seed round, two engineering hires and expansion into Nigeria.
Meanwhile, their largest pilot had stopped processing orders overnight.
The headline changed the diagnosis
The pilot customer expected a corrected batch before Friday’s weekly close. If Kweku’s team missed it, the customer could end the pilot and return to spreadsheets. That would remove their strongest reference account weeks before three prospects made buying decisions.
The team knew the failure pattern. A distributor could amend an order after a sales representative had already uploaded it. Their system treated both versions as current, then sent the conflict into a manual review queue. Nobody owned that queue after 6:00 p.m.
The morning conversation still drifted towards capital.
One engineer argued that a larger team could build better monitoring. The commercial lead wanted a salesperson in Lagos. Kweku opened a fundraising spreadsheet and began estimating how much eighteen months of hiring might cost.
The unicorn headline had supplied a larger story at exactly the moment the company needed a smaller one. Capital promised movement. The delivery problem demanded an awkward question: why had a known failure reached a customer again?
I have seen this temptation while building products across Africa, Germany and the US. The numbers change. The reflex does not. A team under pressure imagines the company it could become after a raise, because examining the current operating failure feels narrower and more embarrassing.
One missed handoff put the pilot at risk
At 4:40 p.m. on Thursday, the duplicate orders remained unresolved. Kweku sat in a small meeting room with a charging cable stretched across the table and the customer’s escalation message open on his laptop.
The bad ending was now plausible. If the corrected batch missed the customer’s close, the pilot could expire without becoming a contract. The team would enter investor conversations with a growth story and no dependable answer to a basic delivery question.
Kweku stopped the fundraising discussion.
He asked each person to describe what happened between the first amended order and the customer complaint. The exercise took less than an hour. It exposed a gap that another engineer would not automatically repair: the product created a manual review task, but assigned no named owner, response window or escalation path.
This was the same kind of failure behind Kojo’s broken approval step. Software had moved the work forward, then an undefined human decision left it sitting where nobody was accountable for the outcome.
With the Friday close approaching, Kweku assigned one person to review every conflict, added a visible status for the customer-facing team and paused the risky automation path. The corrected batch went out in time for the customer to continue evaluating the pilot.
That fix would not impress an investor slide. It kept the company’s most important promise alive.
Capital amplifies the operating system you already have
A raise can fund engineers, distribution and time. It can also increase the number of customers reaching an unresolved handoff.
If Kweku had hired two engineers before clarifying ownership, they might have built more alerts around the same gap. If he had hired a salesperson in Lagos, that person could have brought additional distributors into a process already failing under one large pilot.
Money would have increased activity while leaving delivery unchanged.
This is why I separate capacity questions from control questions. Capacity asks whether the team has enough people or computing resources to complete the work. Control asks whether someone can see a failure, decide what happens next and carry that decision through before the customer pays for the ambiguity.
Founders often reach for capital when control is missing because hiring feels concrete. Yet unclear ownership survives new headcount. It may become harder to see once responsibilities spread across more people.
The same distinction matters when a pilot begins pulling the roadmap towards custom work. Ama protected her product roadmap by defining the pilot’s boundaries. More money would not have made those boundaries for her.
Run the Friday test before the funding model
Before opening the fundraising spreadsheet, write down the customer promise currently most likely to fail.
Name the exact handoff. Identify who sees the problem first, who has authority to decide, and what the team stops doing while that person resolves it. Then test the path using a failure already observed in the product.
If the team can explain the failure but cannot name the owner, the constraint is operational. If the owner and process are clear but the queue still exceeds available capacity, capital may belong in the diagnosis.
The following Monday, Kweku’s stand-up began with the conflict queue rather than the unicorn headline. One person owned it. Everyone could see its status. Fundraising stayed on the agenda, but it no longer carried the burden of fixing a promise the team had never properly assigned.
Comments
No comments yet.