When the product is already in the field

Before a product is in the field, most technical decisions are still arguments about what is likely to happen. Once it has shipped, the argument changes. Earlier judgements keep expressing themselves through real units, real customers and real service networks, often long after the meeting in which they were made has been forgotten.

The pattern is not peculiar to connected products. I saw versions of it earlier in publishing systems, where short-term savings in architecture, tooling or process quality created costs that arrived later in less convenient forms. Connected physical products make the pattern harder to ignore. The consequences are not confined to slower systems or awkward maintenance. They return as failed components, service burden, warranty exposure, customer returns and occasionally safety questions. By then the product is out there in numbers large enough to make every correction more expensive than prevention would have been.

---

Save a cent to spend a dollar

There is always pressure on product cost. It comes from sales, finance, marketing and procurement, often for perfectly legitimate reasons. A product that is too expensive to sell is not a success simply because it is beautifully engineered. The CTO's task is not to resist every reduction. It is to tell the genuine efficiency from the false economy: the saving that removes waste from the one that quietly removes resilience, observability, maintainability or safety margin.

I have used the phrase “save a cent to spend a dollar” often enough in meetings that it has become a useful diagnostic for me. Some savings really are savings. Others are deferred costs with better timing for the spreadsheet and worse timing for the business. The hard part is that the false ones rarely look reckless when they are proposed. They are small, locally defensible reductions that seem harmless one at a time and become expensive only when the whole system has had time to reveal what was lost.

Being the arbiter of that distinction is one of the less visible parts of the CTO role. The judgement has to be technical enough to understand what the reduction changes, commercial enough to understand why the pressure exists, and broad enough to explain the later bill in terms the rest of the business can weigh before the field supplies the evidence at greater cost.

---

The battery-pack cascade

I have seen this most clearly in connected vehicle products, where pressure to reduce the cost of a large battery pack did not stay a battery-pack decision for long. The revised pack was cheaper in the narrow sense that mattered to the original conversation. It also created a different spares-carrying requirement. It did not fit the scooters in quite the same way, so it needed different mounting arrangements. And it made field swap-outs more awkward and more expensive than the saving had assumed.

The battery-management technology did not behave in the same way either, which led to field problems and customer returns that never appeared in the unit-cost comparison. The product also had multiple processors, and the over-the-air update strategy had not been planned deeply enough for all of them to be updated once the product was deployed. Diagnostic data was not available from all of those processors either. When problems began to emerge, the team was partly blind to what was happening inside products already in customers' hands.

None of those consequences sat on the same budget line as the original saving. That is the point. A component-cost reduction can become a system-cost increase once compatibility, field service, firmware lifecycle, diagnostic visibility, returns and customer trust are counted properly. The cheap version of the part may be the expensive version of the product.

---

Where the pressure goes

The same pattern operates beyond the design itself. Constant pressure to reduce cost strains the whole supply chain. A supplier pushed hard enough on price looks first to its own margin, then to its processes, then to its own suppliers. The pressure moves upstream until it reaches a link with less slack, less negotiating power or less visibility. That is often where the corner is cut: a material specification quietly altered, an inspection step shortened, a manufacturing tolerance allowed to drift, a component sourced from an equivalent whose equivalence is more commercial than technical.

The company demanding the saving may never have asked for any of those changes. It asked for the conditions under which they became likely. Everyone in the chain has targets to meet, and it takes only one player reducing material or manufacturing quality too far for a latent problem to enter tens or hundreds of thousands of products before the issue becomes apparent in the field. By then the direct supplier negotiation may still look commercially successful. The product risk has simply moved out of sight until the installed base is large enough to make it visible again.

This is one reason procurement decisions in connected products cannot safely be treated as commercial decisions with a technical review attached afterwards. They are technical, commercial and reliability decisions at the same time. A CTO who cannot explain that clearly will either lose every argument on immediate cost or become the person who seems to oppose commercial discipline on principle. Neither outcome serves the business.

---

Designing cost out properly

There is a better route than crude cost cutting, and it starts earlier. Design for manufacture, design for test and design for repair are not afterthoughts added once the product works. They are part of what it means for the product to work commercially.

Design for manufacture asks whether the product can be built repeatedly, at the intended quality, without depending on heroic process control or expensive rework.

Design for test asks whether faults can be found before shipment rather than discovered later by customers.

Design for repair asks whether the field service model has been designed deliberately: what can be diagnosed remotely, what can be swapped quickly, what should be repaired, and when replacement is genuinely cheaper than repair across the whole life of the product. Sometimes replacement is the right decision. What matters is that it is a designed decision, not the accidental consequence of a product nobody thought about maintaining.

A different product made the point in a smaller but equally revealing way. The design called for waterproof connectors, but to save a few cents some interfaces used ordinary connectors instead. The apparent saving produced a less standardised product, a more complicated spares position and avoidable reliability problems in the field. Decisions like this look almost too small to argue about while the product is on paper. They look less small once workshops are carrying extra stock, technicians are making slower repairs and customer-facing failures have begun to accumulate.

Remote diagnostics sit in the same category. A system that can identify most faults remotely, ideally the great majority of them automatically, reduces customer-service workload, unnecessary returns and the number of physical interventions needed to understand a problem. Building that capability costs money before launch. Not building it costs money every time a customer reports a fault nobody can see into clearly enough to resolve without moving hardware around the country.

---

What the leader is carrying

The uncomfortable part is that the CTO often has to make or defend these decisions before the later cost can be demonstrated conclusively. The sales leader can point to the price target now. Finance can point to the margin now. Procurement can point to the supplier quote now. The CTO is frequently the one arguing that a future failure pattern, service burden or safety exposure is being made more likely by a saving whose benefit is immediate and measurable.

That takes more than technical knowledge. It takes the judgement to know which arguments are worth having, the commercial fluency to explain whole-life cost rather than engineering preference, and the steadiness to avoid both reflexive resistance and weary acquiescence. Some reductions should be accepted. Some should lead to redesign. Some should be refused. Much of the quality of the role lies in knowing which is which, and in making the case before the product in the field makes it at greater cost.

When consequences do surface later, the temptation is to defend the original decision, localise the problem or treat the field signal as noise. Seniority is tested by the opposite response: faster escalation, wider evidence gathering, less ego in the root-cause work, and a willingness to spend money early when the alternative is spending trust later. Systems can surface data. Only a person can decide whether to look at it honestly.

The product in the field is no longer an argument about what should work. It is the answer, arriving slowly and at scale.

---

Four things worth taking seriously

For boards: ask what a proposed cost reduction changes beyond its own budget line. Compatibility, field service, firmware lifecycle, diagnostics, returns and customer trust all belong in the comparison.

For engineering leaders: treat procurement decisions as technical and reliability decisions as well as commercial ones, and be ready to explain the whole-life cost in terms the rest of the business can weigh.

For founders: budget for design for manufacture, test and repair, and for remote diagnostics, before launch. They cost money early. Their absence costs more once the product is in the field.

For anyone negotiating with suppliers: price pressure travels upstream. The corner may be cut several links away, where you cannot see it until the installed base shows it to you.

---

I would be interested to hear which small saving, in a product you have worked on, turned out to be the most expensive decision in the programme.