A fintech launch should pause when its critical path depends on stable connectivity, modern devices, or payment habits that target customers do not share. Those assumptions are product dependencies, and discovering them before release is evidence that the review worked.
In 1999, NASA’s Mars Climate Orbiter approached Mars after a journey of hundreds of millions of kilometres. The spacecraft was expected to enter orbit and support the study of the planet’s atmosphere. Instead, the mission team lost contact.
The failure began far earlier than the final approach. One team had produced thruster data using pound-force seconds. Another part of the system expected newton seconds. Both sides had completed their work, but the interface between them carried an assumption nobody had resolved.
NASA’s Mars Climate Orbiter Mishap Investigation Board documented the mismatch in its 1999 Phase I report. By the time the difference became undeniable, the spacecraft could not be recovered.
The assumptions hiding inside the launch plan
A fintech team can reach the same kind of boundary without leaving Earth.
The launch plan may look complete. Registration works. Identity checks pass. The payment flow succeeds on the devices around the meeting table. The dashboard records each transaction. Someone has prepared the release announcement.
Then the team traces the critical path from the customer’s position.
The registration flow assumes a connection will remain active across several screens. The identity step assumes a camera can produce a clear image under ordinary household lighting. The payment confirmation assumes customers recognise the options and use them in the sequence the product expects. Recovery assumes they can retrieve an email without leaving the session.
Each assumption can survive a demo because the demo environment quietly supplies what the product needs: a recent phone, reliable internet, available storage, current software and a payment habit familiar to the builders.
That environment may describe the team in Accra, Lagos, Berlin or Atlanta. It does not automatically describe the customer the team selected.
The dangerous sentence in the meeting is, “The flow works.” The useful follow-up is, “Under which conditions?”
A pause can protect the critical path
Pausing at this point creates a difficult decision. Runway still moves. Partners may be waiting. The team may have promised a release window. An engineer who expected to start the next feature now has to reopen work everyone considered finished.
Shipping anyway feels like momentum. It can also turn untested assumptions into customer failures.
The Mars Climate Orbiter report is useful here because the problem was not a lack of technical ability. The failure sat at an interface where two valid-looking outputs met. Fintech products have similar interfaces between software and network conditions, device capability, customer behaviour, payment rails and support operations.
A passing test on one side says little about the whole path.
This is where I would pause the launch and replace broad confidence with a short dependency map. Start with the customer’s intended outcome, then write every condition required to reach it. Mark which conditions the product controls, which depend on outside systems and which exist only because the team assumes customers behave like the people who designed the flow.
That investigation can uncover risks similar to the identity boundary in Ama’s AI demo or the duplicate-record problem that led Chidi to postpone a launch. In each case, the delay matters less than the decision it protects.
Test the weakest conditions first
The next test should not recreate the meeting room more carefully. It should remove the comforts that made the first demo pass.
Use the oldest supported device available to the team. Interrupt the connection during registration, payment and confirmation. Reduce available storage. Leave the app midway and return. Ask a target customer to complete the flow without explaining the labels. Observe where they hesitate, switch channels or abandon the task.
The goal is not to manufacture hardship. It is to test the conditions already present in the chosen market.
Record failures by customer consequence. “The request timed out” describes the system. “The customer cannot tell whether money moved” describes the risk. That distinction decides what must block launch and what can wait.
The same discipline applies to payment habits. A technically available option may still be unfamiliar, distrusted or used differently from the sequence encoded in the product. Customer observation belongs on the critical path when behaviour determines whether the transaction completes.
Resume with evidence, not reassurance
A pause needs an exit condition or it becomes drift.
Define the few journeys that must work under the supported conditions: account creation, payment, confirmation, recovery and access to help. Assign one owner to each unresolved dependency. Retest the whole journey after individual fixes, because changing one step can move the failure elsewhere.
NASA could not correct the Mars Climate Orbiter’s interface after contact was lost. A fintech team sitting in a launch meeting still has that option.
Keep the release paused until the weakest supported device, the interrupted connection and the least familiar customer can complete the critical path and understand the result. Then launch with a narrower claim, backed by what the team has actually seen.
Comments
No comments yet.