What the launch actually costs

Shipping is not launching. For a software product the distinction barely exists. The product reaches users the moment it is deployed, and the infrastructure behind it scales automatically. For a connected physical product, the gap between shipping and launching is where a significant proportion of hardware companies quietly fail, and where costs accumulate in ways that were entirely preventable.

The product leaving the factory ends one problem and starts several others that the development process has no natural mechanism for surfacing. Installation, maintenance, fault diagnosis, technician training, diagnostic tooling and centralised record capture do not happen automatically, and none of them is free. In my experience they are consistently underplanned and underbudgeted across the industry. That is not because the teams involved are careless. It is because the pressure to get the product built and shipped leaves almost no room for the question of how it will be supported in the field. By the time the gaps are visible, the product is already there and the gaps are expensive.

The launch is the product plus the operational infrastructure that supports it. Without the infrastructure, what is in market is not a product. It is a liability accumulating interest.

---

The maintenance knowledge gap

A connected physical product in the field will develop faults. Components wear, connections corrode, software states diverge from the expected, batteries degrade. In a consumer or fleet deployment, someone's job is to deal with those faults: a workshop technician, a field engineer, a regional service partner. That person needs to diagnose the product correctly, tell a hardware fault from a firmware issue, know which faults are field-repairable and which need a return to base, and carry out the repair without introducing new problems.

The knowledge to do that does not transfer automatically from the engineering team to the workshop. In my experience, the gap between what the engineering team assumes the workshop knows and what the workshop actually knows is consistently larger than expected. Bridging it takes deliberate translation: training materials that describe the product from the maintenance perspective rather than the development perspective, practical exercises on representative fault scenarios, and ongoing escalation support for faults the technician has not met before.

This is a product deliverable in its own right. A product without it is not ready to launch, whatever the engineering checklist says. Launching without it tends to show up as incorrect diagnoses, unnecessary returns, and a field service network that loses confidence in the product considerably faster than the product team realises.

---

Diagnostic tooling as a field product

A workshop technician cannot maintain what they cannot see into. For a connected product with software-managed behaviour, real-time sensor readings and firmware state, visual inspection is not enough. The technician needs tools that can interrogate the device: read the current firmware version, surface fault codes, display live sensor data, run self-test routines, and confirm that a repair has worked before the unit goes back into service.

In most hardware programmes I have encountered, diagnostic tooling is treated as a development aid rather than a field service product. The engineering team builds it for its own use during development, and it may or may not be handed over to field service in a form that is usable outside the development environment. The tools exist, but they need engineering context to operate, run on a development machine rather than a workshop computer, and carry no documentation designed for a technician who was not part of the original team. The field service network builds workarounds. The engineering team is generally unaware of them.

Diagnostic tooling designed for field service is a meaningfully different product from tooling designed for development. It needs to present the information relevant to the maintenance task, not the full engineering view. It needs to be usable by someone who knows the product as a maintainer, not a developer. And it needs to be treated as a maintained software product, updated when the firmware changes, not a one-off development artefact. Getting this right before launch costs considerably less than rebuilding the field service relationship after it has deteriorated because the tools were not fit for purpose.

---

Cohort knowledge and early warning

Every maintenance event contains information: the fault code, the symptom as the operator described it, the diagnosis, the repair action, the components replaced, the outcome. Individually each event is a record. Aggregated across a deployed population, these records are the most reliable early warning system a product team has for reliability problems developing in the field.

Products are manufactured in batches, and components come from suppliers who may change their production processes between runs. A batch with a latent defect, a component that is marginal rather than failed, or a process variation that reduces service life without causing immediate failure will not show up in incoming inspection. It will show up in the maintenance records four to eight months after deployment, as an elevated fault rate in a specific cohort.

If those records are captured centrally and tracked at cohort level, the signal is detectable before it becomes a widespread field problem. The intervention, whether a targeted firmware update, a proactive replacement programme or a change to the assembly process for future batches, can happen while the cost is still manageable. If the records sit in disconnected workshop systems across different markets, or are not captured consistently at all, the signal arrives late as warranty claims and operator complaints, and the cost has already compounded.

The system needed for this is not complicated to build, but it is considerably harder to retrofit than to design in from the beginning. The operational discipline of making every workshop capture data consistently enough to compare across sites has to be established before launch. It cannot be negotiated with a distributed field service network after the fact.

---

Warranty cost as product data

Warranty cost tends to be reported by the finance function and read, if at all, as a financial metric. In a hardware-software business it is more usefully understood as product data: a detailed account of where the product is failing in the field, at what rate and at what cost. The pattern of claims (which fault codes appear most often, which components are replaced at what rate, how the profile changes over the service life) is directly actionable in the engineering roadmap, provided it is visible at the right level of granularity.

A total warranty cost figure tells you that something is wrong. A breakdown by fault code, production batch, deployment environment and time since installation tells you what is wrong, where it started and what it would cost to fix. In my experience, an engineering team that has warranty data at that level of detail, and reviews it often enough to inform roadmap decisions, makes meaningfully better product investment choices than one that does not. The barrier is almost always organisational rather than technical. Finance has to report differently, and engineering has to build a process for receiving that information and acting on it.

---

The new market problem

Everything above applies to a new product in its first market. It applies again, in full, when an existing product enters a new geography. This is the version I find most consistently underestimated, because the product is known, the engineering is done, and the assumption tends to be that the extra cost of a new market is primarily commercial.

In practice the operational infrastructure (trained workshops, localised diagnostic tooling, maintenance record capture, regional spare parts supply) has to be built from scratch in the new market, in a context that may differ significantly from the original one. Use conditions vary. An e-scooter fleet in a northern European city operates in different temperature ranges, on different road surfaces and at different duty cycles from the same product in a South-East Asian market. The failure modes will be different. The maintenance training developed for the first market will be partly wrong for the second. Spare parts that rarely fail in one environment may fail frequently in another.

From a field operations perspective, a product going into a new market is a new programme. Teams that treat it as a distribution exercise rather than an operational build tend to discover the gap during the first warranty cycle, when the failure rate is higher than expected and the infrastructure to respond to it is not in place.

---

Where this fits in the product plan

Field operations infrastructure is not a cost centre. It is the mechanism by which the product delivers its commercial promise after it has shipped. A product the field cannot maintain, diagnose or support will fail in market regardless of its technical quality. The cost of not building the infrastructure is not avoided. It is deferred and compounded, and it shows up in warranty claims, field service failures, customer relationships that do not develop, and market entries that have to be restructured after the first deployment cycle.

The right time to plan and budget for field operations is during product development, while the architecture decisions that affect it are still open and the operational design can be integrated with the product design rather than bolted on afterwards. That means asking not only “can we build and ship this?” but “can we support it in the field, at the volumes we are planning, in the markets we are entering?”, at a point when the answer can still change the plan.

---

Four things worth taking seriously

For boards: do not treat shipping as launching. Ask whether training, diagnostic tooling, record capture and spares are planned and budgeted as part of the launch.

For engineering leaders: treat field diagnostic tooling and maintenance training as product deliverables, designed for maintainers and updated whenever the firmware changes.

For finance and operations leaders: report warranty cost by fault code, batch, environment and time since installation, and make sure engineering sees it in time to affect the roadmap.

For anyone planning a new market: treat the entry as a new operational programme, not a distribution exercise. The field infrastructure has to be built again, for conditions that may be quite different.

---

I would be interested to hear how your organisation decides when a connected product is genuinely ready to launch, rather than simply ready to ship.