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 penny to spend a pound

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 penny to spend a pound” 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.

---

How a component saving cascades

The pattern is easy to see in connected products. Suppose a team is asked to reduce the cost of a major subassembly. A cheaper alternative can win the unit-cost comparison and still turn out to be much more than a component decision: different spares, different mounting, and field replacements that cost more than the saving assumed.

To put illustrative numbers on it: a saving of £4 a unit across 20,000 units is £80,000. If one unit in fifty later needs a field replacement costing £150 in parts, labour and logistics, that is £60,000, before counting returns, an extra firmware variant to maintain and the customers who do not come back. Most of the saving has gone, and the cost lands later, on other budgets.

Its behaviour in the field may differ too, and that shows up in service rather than in the unit-cost comparison. A product with several processors needs an over-the-air update strategy that reaches all of them, and diagnostic data from all of them. Without both, the first sign of a problem can arrive from customers rather than from the products themselves.

None of those consequences sits 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.

The same pattern shows up in much smaller decisions. A design calls for waterproof connectors, and to save a few cents some interfaces use ordinary ones instead. The apparent saving can produce 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, and they pay for themselves the first time something goes wrong 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.