A viral launch has succeeded when demand rises. It has failed operationally when the product depends on private routines that only one founder understands.
At 6:12 on Monday morning, the support queue showed 184 requests from customers in Accra, Berlin and Atlanta. The launch had travelled farther than expected. So had every ambiguity in the product.
Some customers could not complete the first workflow. Others had reached states the demo never showed. A few requests needed product judgment rather than a support reply: Was this account blocked by design? Could that result be trusted? Should the automation continue after the customer changed one field?
Before the launch, those questions lived in the founder’s head. He knew which exceptions were harmless, which ones needed a manual check, and which customers required a different answer because of the market they operated in. That knowledge had kept the product coherent.
At 184 requests, it became the constraint.
Growth exposes the decisions nobody wrote down
Toyota faced a much larger version of this problem after years of rapid international expansion.
By 2009 and 2010, the company was dealing with major recalls involving millions of vehicles. Akio Toyoda, Toyota’s president and the grandson of its founder, appeared before the United States Congress in February 2010 as lawmakers questioned the company’s handling of safety complaints.
Toyoda’s prepared testimony described a company whose growth had outrun its priorities. Toyota had expanded quickly, and in his account, the order that once guided the business had become confused: safety first, quality second, volume third. Growth had pushed volume forward.
The outcome was still uncertain when he testified in Washington. Toyota had to investigate technical causes, answer regulators, restore customer confidence and examine whether decisions were travelling through the company fast enough. The hearing and Toyoda’s testimony are preserved by the U.S. Government Publishing Office in the congressional record.
The useful parallel for an early-stage software founder is smaller and less dramatic, but the mechanism is familiar. A product can appear coherent while one person quietly resolves every contradiction. Demand does not create those contradictions. It reveals how many were being settled manually.
The support queue is a map of hidden product policy
The wrong response to 184 requests is to answer 184 requests as quickly as possible.
That clears the visible queue while preserving the system that produced it. Tuesday arrives with another queue, and the founder remains the only person who can interpret the difficult cases.
I would separate the requests by the decision they require.
Some are ordinary support: password problems, missing confirmations, unclear instructions. These need clearer product language, better recovery paths or a documented reply.
Some expose repeated workflow failures. If customers in Accra, Berlin and Atlanta stop at the same point, the interface may be asking them to infer a rule the team never stated.
The final group contains judgment calls. These are the dangerous ones because a quick support answer can quietly become product policy. If one customer gets an exception, will the next customer qualify? Can a support person make that call? Does the product record why the decision was made?
This is the same reason I would resist automating an exception before understanding it. As I explored in Should I Automate the Exception That Froze My Transfer?, automation can repeat an unclear decision faster. It cannot make the decision sound.
Replace founder memory with visible boundaries
The founder does not need a larger support team first. The first job is to make the hidden operating model visible.
Start with the twenty requests that took the longest to resolve. For each one, record what evidence was checked, who was allowed to decide, what condition changed the answer, and where the product failed to explain itself.
Then choose one repeated decision and move it out of private memory. That may mean adding a product state, writing an escalation rule, logging the evidence behind an automated action, or shrinking the workflow until the uncertain part can be reviewed safely.
This work will feel slower than replying to the next ticket. It is also the only work that changes Tuesday.
A useful boundary sounds plain: support can resolve these three cases, product reviews these two, and the automation stops when this field changes. If the rule needs a ten-minute voice note from the founder every time, it is still private.
The same discipline applies before adding AI to customer support. An assistant needs a defined route for cases it cannot classify, especially when a conversation could enter a regulated or high-consequence process. The decision to pause matters as much as the decision to proceed, a point developed further in What Happens When a Chatbot Hands a Customer Into a Regulated Process?.
Protect coherence before chasing the next spike
Toyota’s problem could not be solved by asking Akio Toyoda to inspect every vehicle or personally answer every complaint. The company had to restore priorities and make responsibility travel through the organisation.
A small product team faces the same design question at a different scale: can the product remain trustworthy when the founder is asleep, in another time zone or focused on the next release?
The answer will not come from the launch dashboard. It will come from the requests that forced someone to stop, interpret and decide.
On Monday, I would leave the celebration metrics open in another tab. Then I would take the first twenty difficult cases, name the decision inside each one, and refuse to close the day until at least one of those decisions no longer depended on the founder remembering what to do.
Comments
No comments yet.