When an investor passes, protect the next proof point before protecting every month of runway. A contract can fund the team, but take it only when its scope leaves the product’s core question answerable.
At 4:17 PM, Nia was sitting in a shared office in Accra with a cold sachet of water beside her laptop when the email arrived: the fund would not move forward. The partner liked the problem. They could not justify the round before seeing repeat demand.
Nia had six months of work planned for an AI tool that helped small retailers spot stock gaps from sales records. Her team had already built the data intake, the first model, and a dashboard that made sense to them. It had not yet made a retailer pay.
An overseas company had sent a contract that morning. The fee would cover the team for a while. The work was close enough to their product to sound sensible in a call: automate reporting for a larger business, adapt the data pipeline, add a review layer, deliver a working system.
It also asked for the two engineers she needed to run retailer trials.
The investor’s pass turned the choice into something immediate. Cut six months of planned product work and focus on the smallest retailer test, or accept the contract and let a paying client decide what the team built next.
The rejection email changed the job
A pass can feel like a verdict on the company. Usually, it is a verdict on the evidence available at that moment.
Nia reread the email and began defending the roadmap to herself. The dashboard was nearly ready. The model would improve with more data. A new feature could make the demo more convincing. Each sentence described work the team could do. None answered the investor’s actual concern.
Would a retailer use this often enough to pay for it?
That was the job now. The fundraising plan had paused. The product team had become a learning team.
This is where founders can lose a quarter without noticing. A rejection creates anxiety, and anxiety makes planned work feel safer than customer contact. Building the next screen feels productive. Asking a buyer to test a rough workflow can produce a clearer answer, including an answer nobody wants.
The contract offered relief. It also made the roadmap easier to avoid.
A contract should buy evidence, not replace it
Nia did not reject the overseas contract. She opened the scope and marked every request that would create a one-off path: custom reporting views, approvals designed around that company’s internal process, integrations no retailer had asked for.
Then she wrote a narrower proposal.
Her team would deliver the reporting automation that fit their existing pipeline. They would not build the requested review layer in the first phase. One engineer would remain on retailer trials. The contract would fund work they could later reuse, while leaving room to find out whether the original product had a buyer.
The company could have declined. That was the genuine risk. Payroll still had to be met, and the investor’s email had removed the easiest story Nia could tell herself about the next few months.
The revised scope went out late that evening. The following day, the buyer accepted the smaller pilot.
That acceptance did not validate Nia’s product. It gave her something more useful than a blanket yes: time to pursue validation without handing the roadmap to the first available payer.
The distinction matters. A contract can be revenue, learning, distribution, or a detour. It becomes a detour when the work asks you to answer a customer’s internal problem while postponing the question your company exists to answer.
The same pressure shows up when a US company wants a broader pilot than a small team can responsibly support. Kwesi narrowed the pilot before expanding the scope, because a larger opportunity can still cost the evidence needed for the next decision.
Cut the roadmap around the next irreversible choice
Nia removed work from the plan, but she did not remove it because it was bad work. She removed it because the work could wait until she knew which retailer problem deserved the team’s attention.
The remaining plan was smaller:
- Put the existing workflow in front of a few retailers who could say yes or no to a paid test.
- Track where their records broke the product’s assumptions.
- Keep the contract work inside the parts of the system the product already needed.
- Set a date to review evidence, rather than treating the contract’s end as product validation.
These are plain decisions, but they are hard when the team has already spent months building. Product work carries its own gravity. The more effort attached to a feature, the easier it is to call it strategy.
A founder’s notes often contain the answer before the pitch deck does. The hard part is admitting what that answer costs. The Tuesday Answer in Your Notes, and What It Could Cost Your Roadmap is about that quieter decision: seeing the tradeoff, then choosing it while it is still reversible.
The morning after needs a narrower plan
Two weeks later, Nia was back at the same desk, this time listening to a retailer describe how staff corrected stock records after closing. The dashboard had treated those corrections as noise. They were central to the buyer’s daily work.
That conversation made one planned feature unnecessary and exposed a problem the team had not seen from their own screens.
The investor had passed. The uncertainty remained. But Nia no longer had six months of abstract product work sitting between her and an answer. She had a smaller contract, a protected test, and a calendar with retailer conversations that could still change the company’s direction.
Comments
No comments yet.