Who owns the software-defined vehicle after it leaves the factory?

The commercial promise of a software-defined vehicle is the ability to improve what a customer owns after delivery. That promise creates an enduring operating responsibility. A feature roadmap may belong to product management, but the consequences of changing a vehicle extend into engineering, service, security and the supply chain. The central management question is who can make a decision that all those teams will honour.

An organisation can buy software components without acquiring the capability to support a changing fleet. It needs people, evidence and contracts that survive the transition from development programme to vehicles in use. Treating launch as the end of software ownership leaves that transition dangerously incomplete.

Define the product beyond delivery

Start with the functions customers receive and the conditions under which they remain available. Separate functions that depend on the vehicle alone from those that require connectivity, an account or an external service. Identify the experience if each dependency disappears. This establishes the actual product boundary, rather than the boundary suggested by an attractive demonstration.

The Eclipse SDV charter explicitly includes both development and fleet software operations within its collaborative scope. For a manufacturer, the practical implication is to give operational support a place in the product plan. Decide how defects, compatibility changes and service retirement reach the same decision forum as new features.

Give one owner authority over trade-offs

A lifecycle owner should be able to convene the teams that carry different risks. Engineering assesses technical feasibility and behaviour. Security evaluates exposure. Aftersales understands recovery in a workshop. Commercial teams explain commitments made to customers. Each contributes evidence, but their meeting needs a clear decision authority and an escalation route.

Ownership also needs a budget. A programme that funds feature development while leaving monitoring and maintenance to discretionary spending creates a predictable conflict. Request a support plan with each significant feature proposal. Specify the staff, supplier access and tools required to investigate a fault several software generations later.

Keep suppliers inside the lifecycle

Software acceptance should include the material needed to maintain the delivered component: supported configurations, dependency information, diagnostic access and a route for reporting defects. Negotiate the treatment of interface changes and discontinued tooling while the supplier still has a strong incentive to resolve uncertainty.

Consider how a supplier replacement would work. The question is not whether every component can be exchanged easily. It is whether the manufacturer understands the evidence, permissions and integration work required. A dependency that cannot be changed may be acceptable when the business has deliberately funded its long-term support.

Measure the ability to make a safe change

A useful management review follows a proposed change from requirement to a vehicle in service. Ask which configurations it affects, what proves compatibility, how deployment is controlled and how support staff recognise the result. Unanswered questions expose operating gaps more clearly than a broad maturity score.

Software-defined capability should therefore be judged partly by the organisation's capacity to keep its promises. A credible strategy connects new value to continued care of the installed product. The vehicle leaving the factory starts that responsibility; it does not transfer it to an undefined future team.