The right call is to protect the launch date while adding the smallest cash-assisted path that lets customers complete the journey. Ship it as a controlled operational bridge, measure where cash enters the process, and resist turning one weekend into a full payments rebuild.
At 4:47 on Friday afternoon, Youssef was standing beside a whiteboard in Tunis with a cold coffee in his hand. His fintech product was due to launch on Monday, but the final test had exposed a hard stop: a customer could complete every screen on her phone, then still need to visit a cash counter before the transaction was finished.
Youssef is an invented composite, but the decision is familiar. Delay the launch, and he risks losing the small group of partners who have already arranged their Monday around it. Launch without cash support, and the product may work beautifully for the customers least likely to need it.
The bad ending was clear. Monday could arrive with a polished app, working notifications and no completed transactions.
The cash counter is part of the product
Teams often draw the product boundary around the software they control. The customer draws it around the job they need to finish.
If the journey ends at a cash counter, that counter belongs in the product map. It affects whether the transaction completes, how long completion takes, what proof the customer receives and who resolves the problem when the digital record and physical payment do not match.
That does not mean Youssef should build a large cash collection network before Monday. It means he cannot describe the mobile flow as complete while treating the final step as somebody else’s concern.
I have seen this boundary mistake while building products across African, European and US markets. A team ships the clean part of the journey, then calls the remaining friction an operational exception. Customers experience one journey. They do not care which company, contractor or counter owns the awkward final metre.
The useful question for Youssef was therefore narrower: what is the smallest honest version of the cash journey he can support on Monday?
Protect the date by reducing the promise
By Friday evening, Youssef had three apparent choices. He could delay everything. He could launch the full digital journey and leave cash customers to find their own way through the final step. Or he could add a temporary process his small team would have to operate by hand.
The third option looked inelegant. It was also the only one that preserved both the learning date and the customer’s ability to finish.
I would narrow Monday’s launch to a defined group, document the cash handoff in plain language and assign one person to reconcile each completed payment against the product record. Customers should know where the digital journey pauses, what they need to do next and how confirmation reaches them.
That choice changes what Monday means. It stops being a declaration that the product is finished. It becomes a test of the most important uncertainty: will customers complete the journey when cash remains one of the steps?
The same reasoning applies when an integration threatens to consume more runway than the evidence supports. I explored that trade-off in Sami’s six-month integration plan. The calendar matters, but only when the launch produces information that can change the next decision.
Manual work needs an expiry condition
A temporary cash process can become permanent through neglect. One person checks payments on Monday. Two weeks later, three people are copying references between messages and spreadsheets, and nobody can explain which failure the software should solve first.
Before launch, Youssef needs to decide what evidence would justify building further.
He should record where customers abandon the journey, how often staff must intervene, which details create reconciliation errors and how long the team can support the manual process without pulling attention from the core product. He should also set a review point. The team can then choose to automate, change the flow, restrict the launch further or stop serving that route.
This is customer discovery conducted through a live transaction rather than an interview. The customer’s behaviour reveals whether the cash step is inconvenient, confusing or essential. A paid pilot can sharpen a roadmap in the same way, as in how Kweku’s customer discovery changed his product roadmap.
The manual bridge earns its cost only if it creates evidence.
Monday should answer one expensive question
On Sunday evening, Youssef rewrote the launch note. It no longer implied that every step happened inside the app. It explained the cash handoff, named the support route and limited access to a group his team could follow closely.
Monday still carried risk. A customer might reach the counter and walk away. A payment might arrive without enough information to match it. The team might discover that supporting cash costs more than the transaction can bear.
Those are useful failures because each one identifies a decision the product must face.
At 9:12 on Monday morning, Youssef watched the first transaction move from the phone to the cash step. His team knew who was responsible, what confirmation they needed and which details to record. The launch date survived, but the promise had become smaller and more truthful.
That is the move I would make at 4:47 on Friday: keep Monday, reduce the surface area and make the cash counter visible in the product record. Then let the first completed journeys decide what deserves to be built next.
Comments
No comments yet.