Recognition should trigger an operating plan before it triggers a celebration. If a shortlist mention may send new visitors to your product, clear the support queue, test the first customer journey and decide who will pause roadmap work before the traffic arrives.
At 6:42 a.m., the email changes the shape of the day. The founder reads “shortlisted,” then looks at the unresolved tickets carried by a two-person team. Support has not opened. The announcement has not gone public. For a few hours, demand and capacity still exist in separate rooms.
That gap is the opportunity.
The problem arrives before the warning does
On April 13, 1970, an oxygen tank exploded aboard Apollo 13 while Jim Lovell, Jack Swigert and Fred Haise were travelling toward the Moon. The explosion damaged the spacecraft’s oxygen supply and forced the crew into the lunar module, which became their lifeboat.
Then carbon dioxide began accumulating.
The lunar module had been designed to support two astronauts for a shorter period. Now it had to keep three people alive on the journey home. The command module carried spare lithium hydroxide canisters that could remove carbon dioxide, but those square canisters did not fit the lunar module’s round openings.
The materials were available. The system could not use them.
In Houston, engineer Ed Smylie and a team at Mission Control worked out how the astronauts could build an adapter from materials already aboard the spacecraft. NASA’s Apollo 13 mission report documents the carbon dioxide problem, the improvised configuration and the procedures transmitted to the crew. The adapter worked, and the crew returned safely.
The famous object was assembled from ordinary materials. The important decision came earlier: Mission Control treated a rising operational signal as a constraint that could determine the mission’s outcome.
A shortlist announcement carries smaller stakes, but the mechanism is familiar. New attention increases the load on whatever system is already close to its limit. The recognition does not create the weak point. It reveals it.
Traffic turns old tickets into new evidence
The founder’s first temptation is public: prepare the announcement, update the homepage, message investors and ask friends to share the news.
The better first move is private. Open the support queue.
A visitor arriving through an award page or shortlist announcement has little patience for ambiguity. They may know the product’s name and one sentence about what it does. Their first failed login, delayed reply or unclear onboarding step becomes the evidence they use to judge the whole company.
For the existing customer, an unresolved ticket may be an inconvenience. For the new visitor, the same issue can become a reason to leave.
This is why I would separate the queue into three groups before the announcement lands:
- Problems that stop someone from reaching the product’s first useful result.
- Problems that affect payment, access or account recovery.
- Questions that can wait without blocking use.
The first two groups get attention before celebration work. Everything else receives a clear acknowledgement and a realistic next step. A two-person team cannot make every problem disappear before support opens, but it can decide which failures new attention must not amplify.
The same reasoning applies when choosing between product work and external recognition. In the decision between broken onboarding and an award application, the visible opportunity matters only if the customer journey underneath it can carry the extra scrutiny.
Give the spike an owner and a stopping rule
Small teams often respond to traffic informally. Both founders watch analytics. Both check the inbox. Both interrupt their work whenever a notification appears. By midday, support has consumed two people while still feeling unowned.
Before the announcement, one person should own incoming demand for a defined window. That person watches tickets, failed signups and repeated questions. The other protects the product unless a specific threshold is crossed.
The threshold matters. It could be several reports of the same blocking problem, a payment failure or a queue that can no longer receive a useful reply within the team’s normal rhythm. The exact number depends on the product. The decision should exist before excitement and fatigue distort it.
Prepare the smallest useful response kit as well: one clear explanation of the product, one tested onboarding path, saved replies for predictable questions and a status message that says what the team knows. Avoid promises about response times the team has never sustained.
This is operational preparation, not ceremony. It gives attention somewhere safe to land.
Build the adapter before you need it
Ed Smylie’s team could not send Apollo 13 a redesigned filtration system. They had to work with the materials already inside the spacecraft.
A founder facing a shortlist announcement has the same practical constraint at a different scale. There is no sudden support department coming before morning. There are two people, unresolved tickets and a narrow period in which to rearrange the work.
Use that period.
Test the journey a new visitor will take. Close the failures that block value. Assign one person to the queue. Write down the condition that will pull the second person away from the roadmap. Then prepare the public announcement.
The shortlist email is recognition. The support queue tells you whether the product is ready to receive it.
Comments
No comments yet.