When AI cuts a week of engineering work to four hours, treat the saved money as a new capital-allocation decision. Put it toward customer acquisition only when demand is already clear enough that more conversations will change what you build; fund the larger product bet when the missing capability is what prevents a credible test.
At 9:12 on Monday morning, Rafi was standing beside the kitchen counter in his Accra flat, holding cold coffee and watching the team’s sprint board lose its shape. His engineer had spent the previous week building a workflow that turned messy customer requests into structured drafts for review. Over the weekend, an AI tool produced a working version in four hours.
The relief lasted until the finance sheet opened.
That week of engineering effort had been budgeted. The recovered runway was real. By Friday, Rafi had to decide where it went: into reaching more prospective customers, or into a larger product bet that could make the demo harder to dismiss.
The bad ending was easy to see. Spend on acquisition before the product can hold attention, and he pays to collect polite calls and weak signals. Spend on the product before anyone has shown they need it, and the team disappears into another impressive build while runway keeps shrinking.
Four hours changed the budget, not the job
The first mistake after a dramatic productivity gain is to call the work “free.” It was cheaper and faster than expected. It still needed someone to define the workflow, test edge cases, decide what a customer could safely trust, and repair the parts that looked convincing only in a demo.
Rafi’s team had reduced implementation time. They had not proven demand.
That distinction matters because AI can make a roadmap look more affordable than it is. A feature that once required a full sprint may now arrive in an afternoon, but every feature also creates a question: who needs this badly enough to change behaviour, pay for it, or make room for it in an already crowded workflow?
By Tuesday, the team had stopped talking about “what we saved” and started listing the decisions that money could buy. Customer calls. A narrow paid pilot. A better onboarding path. More model experimentation. A second workflow that would make the first one useful in a broader set of cases.
The board had become shorter. The decision had become sharper.
Use acquisition to test a decision you can still make
Customer acquisition earns the recovered budget when the next conversations can settle a live product question.
Rafi did not need a campaign built around reach. He needed to hear whether the people already closest to the problem would use the draft workflow in their normal week, where they would stop trusting it, and what outcome they would pay to get faster.
That meant finding a small set of prospects who had the problem in motion, rather than collecting general enthusiasm from people who liked the idea of AI. A founder saying, “That sounds useful,” does little for a roadmap. A potential customer who can name the document, request, or queue currently slowing their team down gives you something to build against.
This is where the recovered budget can be more valuable than another feature. It gives a small team permission to learn before committing. Pay for the conversations, the demos, the travel if it is necessary, and the time to turn patterns into a decision.
The acquisition spend should have a stopping rule. Rafi wrote one down: if the first set of serious conversations did not reveal a repeated urgent use case, the team would not scale outreach or add sales support. They would return to the product with evidence, or narrow the audience.
That is a harder discipline than “let’s see what happens.” It protects the runway from being converted into activity.
Fund the larger product bet when the current version cannot tell the truth
By Thursday afternoon, Rafi had heard a pattern in the calls. Prospects understood the draft workflow, but each had the same hesitation: they could not rely on it when a request fell outside the expected path.
The feature worked in the clean case. The product had no credible answer for the moment a human needed to step in.
That moved the decision. More acquisition would only send more people into the same doubt. The larger product bet became the better use of the recovered runway because it would make the next demand test honest.
The work was not to add more AI for its own sake. It was to define the handoff: what the system could prepare, what it must flag, and who owns the final decision when the input is ambiguous. That boundary is often the difference between an AI demo and a product someone can use on a Monday morning. What Should Automation Do When One Case Falls Outside the Expected Path? explores that decision in more detail.
This is also why a larger product bet needs a narrower brief than the original sprint. “Make it smarter” creates a long list. “Make this workflow safe to test with five real teams” gives the team a finish line.
Make Friday’s choice reversible where you can
Rafi did not put all the recovered funds into either path. He funded the human-approval layer that made the workflow testable, then reserved a smaller amount for conversations with people who could use that version soon.
The split was not a compromise for its own sake. It matched the uncertainty. The product needed one missing piece before customer feedback would mean much. Once that piece existed, acquisition could answer the next question without forcing a full go-to-market bet.
On Friday evening, the sprint board had four completed hours where a week had been planned. Rafi’s team had not gained a free week. They had gained a chance to spend the same runway with more intent.
Comments
No comments yet.