When a visible panel invitation competes with a broken onboarding flow, protect the product first. Accept only if the company can contain the failure before the event and your absence will not turn one blocked funnel into several days of lost users.
At 4:17, the Kigali invitation is the easiest message in the inbox to answer. It has a deadline, a stage, and a room full of policymakers, investors, founders, and potential partners. The onboarding failure has none of that theatre. It is one engineer tracing logs while new users reach the same point and disappear.
That difference makes the panel feel strategic and the bug feel operational. For a company with one engineer, the reverse may be true.
The moment the mission changed
On April 13, 1970, Apollo 13 was more than two days into its journey when an oxygen tank exploded. Jim Lovell, Jack Swigert, and Fred Haise were still in space, but the planned Moon landing no longer mattered. The immediate work became keeping three astronauts alive and bringing them home.
NASA’s account of the mission documents how teams at Mission Control in Houston had to manage falling power, limited water, rising carbon dioxide, and a spacecraft damaged far from Earth. One of the best-known fixes came when engineers worked out how the crew could make the command module’s square carbon dioxide scrubber cartridges fit the lunar module’s round openings using materials already aboard.
The mechanism matters more than the drama. NASA did not keep pursuing the original mission because the mission was prestigious. Once the constraint changed, the definition of success changed with it.
A founder facing a Kigali panel and a blocked onboarding flow has smaller stakes, but the same decision shape. The invitation represents the original mission: visibility, distribution, credibility, perhaps the next partnership. The failed onboarding changes the constraint. Until users can finish entering the product, more attention may create more failed attempts.
Visibility cannot rescue a blocked product
A panel slot can be valuable. In Kigali, the room may include people who would take months to reach through cold email. A useful answer on stage can travel into private conversations, introductions, and future work.
But visibility has a multiplier effect. It multiplies whatever people encounter next.
If the product works, attention gives more users a reason to try it. If onboarding fails, attention sends more people into the same dead end. The founder returns with a folder of contacts and a product that has quietly taught each new user to leave.
This is why I would ask for evidence before treating the invitation as an obvious yes. How many users are blocked? Does the failure affect every signup or one path? Can support move people through manually? Has the engineer found the faulty step, or are they still trying to reproduce it? What will stop working if the founder spends the event day travelling, preparing, speaking, and following up?
Those answers change the decision. A contained defect with a tested workaround may leave room for both priorities. An unknown failure across the main signup path requires a different call.
The same discipline applies when a Friday demo wins the room but the product still has to prove itself on Monday. I wrote about that gap in What Must Monday Prove After Friday’s Demo Wins the Room?. Applause can validate the story. Only completed user actions validate the path.
Put conditions around the yes
The decision does not need to become “Kigali or the product” immediately. A conditional acceptance can preserve the opportunity while keeping the product as the governing constraint.
I would define a small release condition before Friday evening. The engineer needs a reproducible failure, a confirmed cause, or a safe workaround that another person can operate. The founder needs to know who watches signups during the trip and what event triggers an exit from the panel commitment.
The condition should be observable. “We are close” is weak. “A new account completed onboarding through the affected path after the fix” gives the team something concrete to test.
I would also cut the event commitment to its useful core. Decline extra meetings that have no clear connection to the company. Reuse existing preparation rather than losing a day polishing slides. If the organiser needs an early answer, explain that attendance depends on resolving a live product issue. A serious organiser may accept that boundary. If the slot disappears, the company still avoided sending attention into a broken funnel.
This resembles the judgment behind The 8:17 Ticket I Wouldn't Fix, and the Second Incident It Could Have Caused: urgency alone does not identify the right action. The surrounding system decides what is safe.
Decide what Friday must prove
By Friday, the founder needs two decisions, not one. First, is onboarding sufficiently contained for the company to invite more attention? Second, can the engineer continue without depending on the founder for every product, customer, and commercial call?
If both answers are yes, take the Kigali slot. Go with a clear account of what the company is building and return with a short list of follow-ups tied to the roadmap.
If onboarding remains unexplained, decline or ask to join remotely. The company’s scarce resource is not the panel seat. It is the trust of each person who tries the product while the team still has limited runway and one engineer.
Apollo 13 never reached the Moon. Lovell, Swigert, and Haise returned safely on April 17, 1970 because NASA accepted that the mission had changed. Before answering the invitation, write one sentence that defines success for Friday. If that sentence starts with users completing onboarding, the calendar should follow it.
Comments
No comments yet.