The onboarding failure mattered more than the award deadline because it was already costing new users their first successful experience. At 11:47 PM, the right decision was to pause the application, reproduce the failure and protect the product people were trying to use.
In April 1970, the Apollo 13 crew faced rising carbon dioxide inside the lunar module. The command module’s square scrubber cartridges could not fit the lunar module’s round openings. Engineers in Houston had to devise an adapter using materials available aboard the spacecraft, then guide the crew through building it before the air became unsafe.
NASA documents the improvised carbon dioxide filter in its Apollo 13 mission history. The grand objective had already changed. Landing on the Moon no longer mattered. Keeping James Lovell, Jack Swigert and Fred Haise alive did.
My stakes were smaller. The decision had the same shape.
Two deadlines were competing for the same hour
The award application was nearly complete. A little more work would move it across the line before the deadline.
Then a new user reported the same onboarding failure I thought we had already dealt with. The first screen still failed.
That report changed the decision. I could finish the application and preserve a chance at recognition, or stop and investigate a problem already blocking somebody who had chosen to try the product.
Awards can create useful attention. For an early-stage company, that attention may lead to introductions, credibility or partnership conversations. I take those possibilities seriously. A nomination arriving during release week creates a real allocation problem when the same small team owns the product and the application.
But attention magnifies whatever it finds.
If the first screen fails, more visitors produce more failed first sessions. The award could increase the number of people reaching the defect before we fixed it. Recognition would amplify the wrong evidence.
A repeated failure is different from an unfinished task
An unfinished application feels urgent because its deadline is visible. The remaining fields sit in front of you. The closing time does not move. Every minute spent elsewhere feels like a deliberate loss.
A product failure is less tidy. One report may represent one unusual device, one browser state or one path through the interface. It may also reveal a defect affecting people who never report it. They leave, and the team records their silence as weak demand.
The word “same” carried the decision for me. This was a new user reporting a failure we had already seen.
A repeated onboarding problem deserves a higher priority than its ticket count suggests. It sits at the entrance to the product, before a user has received enough value to tolerate friction or explain what went wrong. There is no relationship to draw on yet. The product gets one short chance to make the next action possible.
That is why I would not compare the two tasks by completion percentage. The application may be 95 percent complete while the fix remains uncertain. The relevant comparison is consequence.
Missing the application sacrifices one opportunity. Leaving the onboarding failure in place risks every new attempt until the cause is understood.
Fix the path before inviting more traffic
The first move is to preserve the report exactly as received. Record the user’s path, where the screen stopped and what should have happened next. Avoid turning the report into a broad redesign discussion before reproducing the failure.
Then test the shortest critical path from a new account to the product’s first useful result. The question is practical: can a person arrive with no internal knowledge and complete the first required action?
If the answer is no, pause work intended to attract more people. That includes applications, launch posts and partnership announcements. A two-person team should fix the path a shortlist would expose before the shortlist sends visitors into it.
This does not mean every bug outranks every external deadline. A cosmetic defect deep inside an infrequently used setting should not automatically stop an application. Priority rises when the failure blocks activation, repeats across users, affects a critical action or prevents the team from learning whether demand is real.
The distinction protects a small team from two bad habits: treating every support message as a fire, and treating fixed calendar deadlines as more important than product consequences.
Decide by what remains true tomorrow
By midnight, the useful question was no longer, “Which task can I finish fastest?” It was, “Which unresolved problem will still damage the company after this deadline passes?”
The award application had a closing time. Broken onboarding had no natural stopping point. It would keep meeting each new user until someone interrupted it.
Apollo 13’s engineers did not solve every problem in the spacecraft. They worked the constraint that determined whether the crew could continue breathing. Their improvised adapter bought the mission what it needed most: a viable next step.
That is the discipline I want when two deadlines compete. Identify the failure that blocks the next useful action. Protect that path first. Then return to the application if time remains, with no invented certainty about whether either outcome will go your way.
At 11:47 PM, I would save the draft, preserve the user report and open a clean session at the first screen.
Comments
No comments yet.