The users trapped at account setup deserve the next eight hours. An award application might create future opportunity, but failed onboarding is blocking evidence that the product works today.
On the evening before the Challenger launch in January 1986, Morton Thiokol engineer Roger Boisjoly argued that the space shuttle should not launch in the forecast cold. He had already raised concerns about how the solid rocket booster O-rings behaved at low temperatures. The launch schedule was real. So was the unresolved engineering risk.
The outcome was still open when Boisjoly and other engineers joined a call with managers at Morton Thiokol and NASA. The initial recommendation was to delay. After internal discussion, Morton Thiokol management reversed that position and recommended launch.
Challenger lifted off from Kennedy Space Center on January 28, 1986. It broke apart 73 seconds later, killing all seven crew members. The Presidential Commission investigating the accident documented the O-ring failure, the pre-launch discussions and the decision process that allowed schedule pressure to outrank the warning.
A startup onboarding failure carries nothing close to those human stakes. The decision mechanism, however, is uncomfortably familiar: a fixed external deadline can make a visible operating failure feel postponable.
The deadline has a clock, the failure has users
At 9:12 on deadline Monday, the award application offers clarity. It closes at five. The form has empty fields. Eight focused hours could turn a rough narrative into a credible submission.
Onboarding is messier. A user enters an email address, reaches account setup and stops. Another retries. Someone sends a screenshot without enough context. The team cannot yet tell whether the problem is the verification email, the password rules, a mobile layout or a broken request.
The application therefore feels easier to prioritize. Its finish line is visible. Onboarding offers only investigation.
That difference can distort the decision. The application deadline measures when an organiser stops accepting entries. The failed setup measures whether new users can reach the product’s value at all.
For a pre-seed founder in Accra, Lagos, Cape Town, Berlin or Atlanta, the second measure usually matters more. Limited runway makes every failed activation expensive, even when the amount is difficult to calculate. A user who cannot create an account cannot test the product, invite a colleague, pay or explain what confused them.
Protect the smallest useful path
Choosing onboarding does not mean promising to repair the entire activation journey by five. The next move is to define the smallest path that must work.
I would begin with one real failed attempt and follow it from the first screen to the point of exit. Which device was used? What did the user expect after pressing the button? Did the request reach the server? Was an account created without a visible confirmation? Could the founder complete the same path using the same conditions?
That trace should produce a narrower decision. Fix the blocked request. Rewrite the instruction users are misreading. Remove a field that the product does not yet need. If the full repair will take longer, add a temporary manual route and tell affected users exactly what happens next.
This is the same practical instinct behind Kojo restoring the manual steps that turn interest into payment. Manual work can be acceptable while a team learns where automation fails. Silence at the point of failure is harder to defend.
The award narrative can then be reduced to what remains honest after the product work. A shorter application built around verified customer behaviour is stronger than eight hours of polished claims resting on an onboarding path the founder knows is broken.
Schedule pressure changes the burden of proof
The Challenger investigation matters here because it shows how a deadline can quietly reverse the burden of proof. Instead of asking whether the system had been shown safe under the conditions, decision-makers asked whether the available evidence justified stopping the launch.
Founders make a smaller version of that reversal when they ask, “Is onboarding bad enough to abandon the application?” A better question is, “What evidence says the application deserves priority while users cannot enter the product?”
There are cases where the award should win. The setup problem may affect one unsupported browser. A working route may already exist. A teammate may have reproduced the fault and begun a contained fix. The application might provide access to a buyer, grant or partnership that materially extends runway.
Those are reasons grounded in evidence. The closing time alone is not.
This distinction also prevents panic from becoming a permanent operating style. Every external deadline arrives with a date, a form and someone waiting. Product failures often arrive as partial logs, abandoned sessions and messages from users who never return. The loudest clock can capture the day unless the founder deliberately values the quieter signal.
Make the call reversible by noon
At 9:12, I would give onboarding a fixed investigation window, long enough to reproduce the failure and identify its boundary. By noon, the founder should know whether the problem blocks most new users, affects a narrow segment or has a safe manual route.
That makes the next decision reversible. If the issue is contained, return to the application with fewer hours and better evidence. If the issue blocks the main path, keep working on it and let the award go.
Roger Boisjoly could not prove exactly how the O-rings would behave during that Challenger launch. He was pointing to an unresolved failure under conditions that made the existing evidence weaker. The commission record is a lasting reminder that uncertainty around a critical path deserves attention before schedule pressure turns it into permission.
By five, the founder may have no award application to submit. But a user who was trapped at 9:12 may now reach the product, complete setup and reveal the next decision worth making.
Comments
No comments yet.