A runway forecast only counts if it includes the hires required to deliver the plan. If nine months of cash depends on leaving a critical engineering role empty, the company has nine months of survival but far less time to build.
Consider Kwame, an illustrative composite of founders I have worked beside across Accra, Berlin and the US. At 4:17 on a Friday afternoon, he was holding a printed cash forecast beside a cooling cup of coffee when he noticed the asterisk next to “engineering hire.” The note said the role had been excluded from the base case.
Three customers were waiting for the integration that engineer would own. Without it, one renewal could disappear and two pilots might never become contracts. With the hire, the neat nine-month runway dropped sharply.
For a few minutes, both choices looked capable of ending the company.
The forecast had answered the wrong question
Kwame had asked, “How long can we keep operating?”
The spreadsheet answered that question accurately. Payroll, software, rent and expected revenue were all there. The problem was that survival had become detached from the work required to earn the next round of revenue.
This happens easily in small companies. A founder cuts planned spending to protect runway, then continues discussing the product roadmap as though the removed people, tools and experiments still exist. The cash model shows nine months. The operating plan quietly assumes twelve months of work from a team that was never hired.
I have learned to distrust runway numbers presented without the assumptions underneath them. A forecast should show what the company can still accomplish at each spending level. Otherwise, founders can congratulate themselves for extending the calendar while reducing the chance that anything valuable happens before the money runs out.
The engineer line made Kwame’s conflict visible. Hiring could shorten the company’s life. Refusing to hire could preserve cash while weakening the reason customers had stayed.
Separate survival runway from delivery runway
Kwame reopened the model and created two versions.
The first was the survival case. It showed how long the existing team could continue paying its bills if hiring stopped and product work remained limited.
The second was the delivery case. It included the engineer, the integration work and a conservative assumption about when customer revenue might arrive. He did not treat unsigned pilots as cash. He also did not assume the engineer would become productive on the first morning.
The difference between those cases became the real decision.
A runway number needs an attached promise: what will be shipped, sold or learned before the cash reaches its minimum safe level? If the answer is vague, the forecast offers comfort rather than control.
This is similar to the decision in What Happens When a Profitable Contract Threatens Your Product Release?. Cash and progress can pull in opposite directions. The hard part is identifying which work creates the next source of cash, and which work merely keeps everyone occupied.
For Kwame, the integration sat close to revenue. That still did not make a full-time hire automatically correct. It meant the work could no longer remain hidden outside the forecast.
Fund the constraint, then narrow the promise
By early evening, Kwame had stopped debating “hire or do not hire” as though those were the only options. He listed the smallest credible version of the integration, the customer evidence needed before expanding it, and the engineering capacity required to reach that point.
The broader roadmap lost two features. One pilot received a narrower scope. The company began the engineering search, but tied the final commitment to a specific customer checkpoint rather than an optimistic sales conversation.
That choice carried risk. The preferred candidate could accept another role. A customer could reject the reduced scope. The integration could take longer than expected.
Still, the decision now matched the constraint. Kwame was spending scarce cash on the work customers were already waiting for, while removing promises the current team could not support.
Founders often protect every roadmap item because removing one feels like retreat. On limited runway, an unchanged roadmap can be the more dangerous choice. If one hire is essential, the product promise may need to shrink around that person’s highest-value work.
The same discipline applies before building. In Why Kweku Tested Distribution Before Building Features, the useful move was to test whether a route to customers existed before committing more product effort. Here, the test came one step later: whether waiting customers would support the narrower build strongly enough to justify the hire.
Put the asterisk in the main conversation
On Monday morning, Kwame placed both runway figures at the top of the leadership document. Nobody could repeat “nine months” without specifying which version they meant.
The survival case bought more calendar. The delivery case bought a credible attempt at the next milestone. Neither was presented as safe.
That distinction changed the weekly discussion. Customer commitments were reviewed beside hiring costs. Roadmap items had to defend their place against the cash they consumed. The engineer stopped appearing as an optional expense and became a decision tied to a defined piece of revenue-bearing work.
This is the next step I would take with any runway forecast: write down the people and purchases excluded from it, then mark which promised outcomes depend on them. If a crucial outcome relies on an excluded cost, move the asterisk into the forecast itself.
Kwame still had a difficult hire to make and customers who could walk away. But on Monday, the plan finally described the company he was trying to build, not the cheaper company that could remain alive while standing still.
Comments
No comments yet.