A founder with enough cash for one engineer or twelve weeks of customer discovery should fund the path that resolves the most dangerous assumption. The decision starts by naming what must be true by Monday, then spending only enough to test it.
At 4:43 on Friday afternoon, Kweku sat in a small office in Accra with the payroll sheet open and his phone face down beside it. His product helped local service businesses turn customer messages into scheduled work. Three prospects liked the demo, but none had paid. The cash left after Friday’s payroll could cover one engineer for the next stretch, or give Kweku and his co-founder twelve weeks to learn why interest kept stopping before payment.
Kweku is an invented composite, but the choice is familiar. Hire now, and the product might become impressive enough to close those prospects. Delay the hire, and a competitor might reach them first. Choose badly, and the company could arrive at its next payroll with a better product and no evidence that anyone would buy it.
The hire would answer the wrong question
The requested features looked specific. One prospect wanted automatic follow-ups. Another wanted a dashboard for team managers. A third asked whether the product could connect to the tool its staff already used.
That sounded like a roadmap.
Yet each request concealed a different possibility. Perhaps the first prospect needed follow-ups before paying. Perhaps the request was a polite way to postpone a decision. Perhaps the dashboard mattered to a manager who lacked authority to approve the purchase. An engineer could build all three requests without resolving which explanation was true.
I have seen this trap while building products across African, European and US markets. A detailed feature request feels like evidence because it gives the team something concrete to do. Code appears. Screens change. Friday demonstrations become easier.
The commercial uncertainty remains untouched.
Kweku’s real question was smaller and more uncomfortable: would one of these businesses pay for the current result if the team handled the missing steps manually?
That was what Monday had to prove.
Monday needed a payment conversation
Kweku removed the engineering role from the immediate plan. He did not decide that hiring was unnecessary. He decided that the company had not yet earned the hire.
On Monday morning, he and his co-founder returned to the three prospects with a narrower offer. They would set up the existing product, handle the requested follow-ups manually, and review every failed scheduling attempt for a limited pilot. The customer would still pay. The founders would absorb the awkward work that software might later automate.
This changed the conversation.
One prospect stopped replying after Kweku introduced payment. Another admitted that scheduling was irritating but rarely costly. The third explained that missed customer messages were causing jobs to disappear before staff could respond. That prospect was willing to discuss a paid pilot, provided the founders could show exactly how exceptions would be handled.
By Wednesday, Kweku still had no signed agreement. The engineer he wanted had another offer and needed an answer. If the pilot stalled, Kweku could lose the candidate and spend weeks discovering something he might have learned by shipping faster.
The doubt was real. There was no clean option, only a choice about which risk the company could survive.
Then the third prospect shared a batch of recent message threads and agreed to a paid, tightly scoped test. The data revealed that the requested dashboard was secondary. The costly failures happened earlier, when ambiguous messages entered the wrong workflow.
The roadmap changed before anyone wrote new production code.
Discovery must produce decisions
“Twelve weeks of customer discovery” can become a comfortable phrase for avoiding commitment. Kweku’s version needed deadlines and consequences.
Each week had to answer a decision that could move money or engineering time:
- Will a prospect pay for the outcome before the requested automation exists?
- Which manual step repeats often enough to deserve software?
- Where does the current product fail on real customer inputs?
- Who feels the cost strongly enough to approve a purchase?
These questions produce evidence a founder can use. General interviews often produce compliments, feature suggestions and descriptions of an ideal future. A paid test exposes priorities because the buyer must decide what matters now.
This is also why runway decisions should connect to a dated proof point. “Learn more about customers” has no stopping condition. “Secure one paid pilot for the current outcome before the next hiring decision” does.
The same discipline appears in Kojo’s product roadmap decision after a competitor’s launch. Pressure can sharpen the next test, but only when the team refuses to confuse movement with evidence.
The engineer came after the constraint was visible
By the end of the discovery period, Kweku had something more useful than a longer feature list. He knew which failure interrupted revenue for the customer, what founders could handle manually, and which repeated exception consumed enough time to justify automation.
That made the engineering role easier to define. The first assignment was no longer “build the dashboard prospects asked for.” It was to reduce a specific class of misrouted messages that the paid test had surfaced repeatedly.
The hiring decision still carried risk. Customer discovery had not guaranteed a market, and one pilot could not settle the company’s future. It had replaced a broad guess with a narrower one.
On the Friday when Kweku finally reopened the hiring plan, the payroll sheet was still there. So was the pressure. This time, beside the engineer’s name, he could write the customer failure that person would be hired to fix on Monday morning.
Comments
No comments yet.