A required registration needs one named decision-maker who can move it forward, even when legal, operations and product each own part of the evidence. If nobody owns the next call, the launch date becomes a hope rather than a plan.
The pause usually looks harmless at first. A product is ready for a German launch. The onboarding flow works. The customer conversation is moving. Then someone asks for the registration, confirmation, or filing that makes the work possible.
Legal has a question about the entity. Operations has the documents. Product knows what the customer will see and when. Everyone has a reasonable reason to wait for someone else.
That is how a registration acquires no owner.
The work sits between teams
The difficult part is rarely filling in a form. It is deciding whose uncertainty matters enough to stop the launch.
Legal may need to know whether the planned product flow creates a different obligation. Operations may be waiting for a document from outside the company. Product may treat the registration as an implementation detail until a customer asks why access has not arrived.
Each view is incomplete on its own. The gap appears in the handoff.
I have found that a launch does not need a committee to “coordinate.” It needs one person responsible for the next irreversible action: call the adviser, ask the office what evidence is missing, decide whether to change the rollout, or tell the customer the date has moved.
That person does not need to be the legal expert. They need the authority to turn unclear ownership into a decision.
Apollo 13 had an interface problem, not a spare part
In 1970, after the Apollo 13 spacecraft suffered an explosion, Jim Lovell, Jack Swigert and Fred Haise had to use the Lunar Module as a lifeboat. Carbon dioxide became a problem because the Command Module had square canisters and the Lunar Module used round openings.
The crew had the filters. They did not have a direct way to use them.
At Mission Control in Houston, engineers worked out an adapter from materials available to the crew. The outcome was uncertain while the team was still solving the fit between two systems designed for different jobs. NASA’s Apollo 13 Flight Journal documents the mission and the effort to make the square canisters work in the Lunar Module.
A registration that lives between legal, operations and product has the same shape. The company may possess every required piece of information, yet still lack the person who can make those pieces fit into the next action.
The lesson is practical: do not ask, “Who owns registration?” Ask, “Who can decide what happens by the end of today if the registration is incomplete?”
Give the gap an owner before launch week
The owner should create a short record that the people involved can actually use. It can be a page, a message thread, or a shared document. It should answer four things:
- What exact registration, confirmation, or approval is blocking the launch?
- What evidence is still missing, and who can obtain it?
- What decision must be made if it does not arrive in time?
- Who will speak to the external party next?
This changes the conversation. “Legal is looking at it” becomes “Marta will confirm the entity question, then Kwesi will submit the supporting documents. If confirmation is still missing on Friday, we launch to the existing market first.”
That last part matters. A registration problem can expose a product decision that was already waiting underneath it. Do you delay every customer? Limit the first release? Keep the overseas contract and accept a slower roadmap? The registration may be administrative, but the trade-off belongs to the business.
I wrote about a related version of this problem in Marta’s AI disclosure delayed launch. Trust had to come first. A launch can look ready from inside the product while one unresolved obligation changes what customers can reasonably trust.
Escalation is part of the product plan
Founders often treat escalation as a sign that the process has failed. In practice, escalation is the process when work crosses boundaries.
Set the trigger early. If nobody can identify the next external call, the issue goes to the founder or operating lead. If a document depends on an outside party, the launch plan shows the dependency plainly. If product needs to change the rollout, it receives that instruction before the team is polishing screens for a market they cannot yet enter.
This is especially important when a small team operates across Germany, Africa, and the US. Time zones and different business norms can make silence look like progress. A customer waiting in Berlin does not experience the internal distinction between legal, operations, and product. They experience a company that either gave a clear answer or did not.
Apollo 13’s crew could not wait for each system to solve its own piece independently. Houston had to define the interface, assign the work, and send back a usable procedure. A launch owner does the smaller, everyday version of that work: name the gap, assign the next call, and make the contingency visible before it becomes the launch plan by default.
Comments
No comments yet.