Launch programmes are easy to make look ready. Every function has a plan, each milestone has an owner, and the dashboard gradually turns green as homologation, stock, retail, systems and aftersales move towards launch. The difficult part is that customers do not experience any of those workstreams separately. Their first transaction immediately tests whether the whole system connects.

That distinction becomes more important as launch models get lighter. Direct sales, smaller market teams, outsourced logistics and service partners can all be economically sensible, but they leave less room for ambiguity. If the operating responsibility has moved, the decision rights and recovery paths have to move with it.

The customer tests interfaces, not workstreams

Launch programmes are usually managed by workstream because that is how organisations are structured. Homologation, supply, retail, finance, IT, aftersales and communications each have owners, milestones and status colours. That is sensible until the first customer transaction crosses several of those boundaries at once.

A salesperson can only promise a vehicle if the stock exists in the right specification, the price is executable, the order state is visible and the delivery path can support the date being quoted. The same customer may then need registration support, a charging answer, a warranty decision or a repair. None of those moments respects the launch programme's organisation chart. They expose whether the handovers between functions actually work.

This is why a programme can be green almost everywhere and still be operationally unready. Each team may have completed what it was asked to do, while the business still has no reliable answer to a simple customer question such as: can I have this car at this price on this date, and what happens if something goes wrong afterwards?

The business case has to survive the transaction

The same issue appears in the business case. A market-entry model can be financially coherent while remaining too abstract to operate. Volume, margin, facility and headcount assumptions can all reconcile in Excel without telling the market which stock it may commit today, who can approve a pricing exception, how an unavailable specification is recovered, or what happens when the first repair needs a part that is not in-country.

Those details change the economics as well. A wider network improves reach but increases fixed cost, field-management load and service coverage. Lower inventory protects cash but makes delivery reliability more sensitive to allocation and replenishment. A partner-heavy model can reduce internal infrastructure while creating new dependencies around standards, customer data, exception handling and service quality. Pricing changes demand, margin and often the stock mix that has to be carried.

Treating these as separate workstreams hides the trade-offs. The useful launch business case is the one that lets management see how a decision in one part of the model changes risk somewhere else, and then tests whether the organisation can still execute the customer promise with the resulting configuration.

Exceptions reveal the operating model

Normal-path readiness is easy to overestimate because most launch preparation assumes that the transaction goes roughly as designed. The operating model becomes visible when it does not. A delayed vehicle, a wrong specification, a price exception, a missing repair part or an order that shows different information in two systems forces the organisation to reveal who actually owns the problem.

Take a delayed vehicle. Somebody has to decide whether the original allocation can still be protected, whether another unit can be substituted, what can be promised to the customer, whether goodwill is appropriate and who is authorised to approve it. A market can have a perfectly competent sales team, supply team and customer-care team and still lose several days simply because nobody owns the cross-functional decision.

The same is true technically. If a new vehicle arrives with a fault and the local workshop cannot resolve it, the important launch question is not whether a service partner has been appointed. It is whether the partner knows the escalation route, whether remote technical support can access the required data, whether a replacement part can be expedited and who keeps the customer informed while that happens.

A small number of realistic exception tests before launch usually tells management more than another round of status reporting. For each one, the business should be able to name the owner, the information needed to decide, the authority limit, the escalation path and the maximum delay it is willing to accept. Where those answers are vague, the launch is carrying operating debt that the first customers will discover for you.

Direct sales and partners move responsibility

Different commercial models do not remove these obligations. They move them. In a direct-sales model, responsibilities that a dealer might previously have absorbed can return to the OEM or NSC. Stock recovery, local customer exceptions, parts of the working-capital burden and customer ownership have to be designed explicitly because there is less organisational slack between the manufacturer and the buyer.

A partner model changes the picture again. A distributor, logistics provider, service partner or retail group can legitimately own substantial parts of the launch system, but the handover cannot be left implicit. Management still needs to know what the partner owns, what information must flow back, which service level applies, when an exception comes back to the market or headquarters and who can intervene when the standard path fails.

Outsourcing execution does not outsource the customer promise. The customer is unlikely to care whether the breakdown sits inside the OEM, the distributor, the dealer or a third-party provider. They care that someone can see the whole problem and resolve it without sending them around the organisation.

Aftersales starts before there is meaningful parc

Aftersales is often treated as something that scales after sales begin because the vehicle parc is initially tiny. Capacity can certainly scale later. The recovery path cannot. The first damaged car, software issue, warranty question or unavailable part can appear before the market has enough volume to justify a mature local organisation.

That does not mean building a full national aftersales structure before launch. It means deciding what the minimum credible support model is for the promises already being made. A launch can rely on partner capacity, temporary parts routes, remote technical support or regional escalation, provided the limits are understood and somebody owns the customer while the temporary path is being used.

The distinction matters economically. Building too much capability too early destroys capital; building too little without a recovery design simply moves the cost into customer dissatisfaction, delay and management firefighting. The right answer depends on expected volume, geography, product complexity and the strength of the partner network, but the gap itself should be a deliberate choice rather than a surprise.

Minimum viable needs explicit boundaries

A launch can be deliberately incomplete. In many markets that is the rational choice. What makes it minimum viable is not that fewer things have been built. It is that management knows which capabilities are missing, how long the temporary route can carry the business and what condition triggers the next investment.

If service is initially concentrated in one location, the business should know what happens to a customer outside that radius. If inventory is deliberately lean, there should be a defined recovery path for the specification that is not available. If commercial exceptions require headquarters approval, the market should know the response time it can realistically promise. These are not reasons to delay a launch by default. They are the boundaries that keep a lean launch from turning into an undefined one.

The same logic should shape the launch-room view. Instead of another dashboard built around departmental completion, management needs visibility on executable stock, delivery reliability, ageing exceptions, unresolved customer cases, critical parts availability and time waiting for decisions. A handful of exceptions during ramp-up can expose a structural weakness long before volume makes it obvious.

The decision

Before committing the launch date, management should be able to connect three things: the economics of the chosen model, the operating dependencies required to make the customer promise work, and the recovery paths for the gaps that are deliberately being carried. That is enough to make a launch decision without pretending the organisation is already mature.

This is an operating judgement rather than a market-wide empirical rule. A simple proposition, a standardised transaction and a mature partner network may need much less orchestration. A complex vehicle, fragmented systems, multiple partners or a direct-sales model will usually need more. The amount of launch infrastructure should therefore be proportional to the promise the business is making and the risk it is choosing to retain.

The vehicle may be ready well before the organisation around it. The useful launch gate is whether the business can sell, deliver, support and recover the customer promise at the level it has chosen, with known gaps and named owners, without inventing the operating model after the first customer arrives.