Designing for Maintenance, Not Just Launch

Most physical products are conceived for a long life cycle, and yet the design team tends to measure its success at the moment of debut. It’s understandable. Ideation is the most generous part of the craft: understanding the user, discovering what they need without being able to name it, turning it into form, material and process. I still think it is one of the most beautiful parts of working in product.

But those of us who design products are rarely taught to think long term, let alone about maintenance, unless it comes written into the specification. Profitability and delivery pressure concentrate attention on the release date: that’s where the money is invested, where the commitment to the customer sits, where the quarter closes. What happens eighteen months later belongs to another department, another budget or, often, to no one.

I tell this as personal experience, not as a verdict on all design education: plenty of schools and teams do it very well. In my case, maintenance showed up clearly when someone wrote it down as a requirement. Two products forced me to look beyond delivery, and I tell them next because they changed the way I ask questions.

The second memory is a long-range hearing aid. I keep the name as it was used on the project, and I won’t go into technical specifications here: what matters for this chapter is that durability was in the specification from the very beginning.

Remarkably, the requirement accounted for wear of the technological components and the casings, and for their possible replacements. In other words, someone had accepted on paper that certain parts would degrade and that the product had to be designed so that degradation wouldn’t make it useless. In my experience that is not the most common thing: components and casings tend to be designed for the best first day, not for replacement.

What links the playgrounds and the hearing aid is a simple idea: specifying maintenance changes materials, joints, access, modularity and sourcing. But there is a condition I learned to watch: repair has to be possible technically and economically. Having a spare part available is useless if taking the product apart costs more than replacing it; in that case the part exists and the repair does not.

Ever since, when someone shows me a product, besides asking who it is for and what it costs to make, I ask how it opens, who can open it and what happens when a part stops working.

If we look at the automobile as a business model, something appears that design tends to overlook: a product’s economic value doesn’t end at the sale. Around a vehicle live the initial sale, parts, services, financing, insurance and other later revenue. And they are not the same for everyone: the profitability structure of a manufacturer, a dealer and a workshop are different.

That is why it’s worth avoiding two simplifications. One is saying that manufacturers no longer make money selling vehicles; the other, that all their profitability depends on maintenance. Neither is true in general. What I can say is that, for many durable products, an important part of the business happens after delivery, and whoever designs the product influences how it happens.

Here an idea from chapter 4 returns: needs are not always natural; sometimes they are designed. The critique of consumption rightly points at those who generate the offer. But it is worth separating four concepts that tend to get mixed up, because each asks a different question.

In digital technology maintenance is even harder to design, because it can’t be seen. A physical object rusts, breaks, loses its paint; a system can be up and running and, at the same time, accumulating unlimited data, unsupported dependencies and unpatched vulnerabilities.

Methodologies include a complete cycle up to delivery to production. SSDLC, for example, stands for Secure Software Development Life Cycle. It is not a single methodology with an owner; it describes the idea of integrating security into the development cycle. It is different from SSDF, NIST’s Secure Software Development Framework (SP 800-218), which offers practices an organization can build into whatever development cycle it uses.

There are manuals, tests, checklists and an orderly handover, and still I see an enormous distance from real maintenance. The problem isn’t SSDLC: it appears when we treat delivery as a closing and assign the operation no capacity, budget, owners or learning.

The things we look at least in a technology implementation project are exactly the ones that weigh most afterwards: space, volume calculations, long-term security, operations maintenance and architecture maintenance. Many stakeholders don’t see them as part of the whole and they slip out of their business cases, because all of it costs, and costs more as usage grows.

In a physical product we study frequency of use, loads, environment and material resistance. Nobody designs a public bench without asking how many people will sit on it and in what climate. In a digital product the equivalent question is how much concurrency, how many requests, how much storage, how much transfer and how many dependencies it will support.

Today there are autoscaling services and serverless architectures, and that is great news. But it wasn’t always so, and even now what changes is how capacity is obtained, not its costs, limits or bottlenecks. A product can grow in users and lose margin if consumption per user, retries, support or paid third-party calls increase.

Nor is it wise to assume cost is proportional to usage. There are fixed costs, variable costs, capacity steps and economies of scale. And monthly active users (MAU) don’t measure load: two active users can consume very different amounts.

Take an example I built for this book, not a case from a product of mine: an app for natural hazards and disasters. It is an extreme but realistic case. On a normal day it might get between 1,000 and 5,600 interactions; in an emergency, depending on the locality and the size of the event, easily 50,000. Before sizing anything you have to define what an “interaction” is and over what time window it happens.

Because 50,000 interactions spread over a day are not the same as 50,000 concentrated in ten minutes. In the second window it is about 83 per second, and you still have to multiply by the technical calls each interaction triggers and by retries. With, say, four requests per interaction it would be about 333 per second and, if each takes two seconds on average, around 667 in flight at the same time, under stable conditions.

But traffic is only one part. In an emergency telecommunications degrade, latency rises, batteries run low and external providers saturate. Scaling the server doesn’t repair a downed mobile network. Operations maintenance must anticipate caching, essential information available offline, the date of the last update, pending requests and controlled degradation: the product does less, but keeps doing what’s essential.

There’s also the human perspective. Can an older person recognize the alert, understand what to do and tell current information from outdated? Does it work on an old phone, with low vision or little digital familiarity? These questions are answered before launch and they are operations maintenance, almost always invisible.

And there’s updating. Server changes and remote configuration are not the same as a new app version, and it’s unwise to promise universal automatic updates. The prudent thing is to plan compatibility, gradual rollout and rollback, and to avoid requiring anyone to update the app to reach essential information during an emergency. Rehearsals happen in test environments: you don’t remove essential protection from a group of real users to see what happens.

A practical way to start is a three-year lifecycle map: volumes, form of use, user profile and incidents. It is not a closed prediction; it is a set of revisable hypotheses questioned every time new data arrives.

For each horizon it’s worth building three scenarios — low, expected and stress use — and recording user profile, volume, frequency, incidents, cost, security, dependencies, an owner and the threshold at which you intervene.

Maintaining a physical product relies on instruments: calipers or a micrometer for dimensional loss, a coating-thickness gauge, corrosion tests, load, fatigue or abrasion tests depending on material and function, and sometimes a scale, when mass loss makes sense. What matters is keeping a record.

Weight alone doesn’t measure every form of wear, so it’s worth noting the unit or batch, exposure conditions, use cycles, measurement method, instrument, its calibration where applicable and the acceptance criterion.

In digital there is a parallel, though not a literal equivalence: material wear and software failures are not the same thing. But both leave evidence that can be measured and documented.

With a physical product you can install pilot units or follow-up groups exposed to known conditions and review them at a defined frequency. It’s worth reserving the phrase “control group” for comparisons that really have a control and a measurement design; following units in the field is valuable, but it isn’t the same as a controlled experiment.

In digital something similar happens. Cohorts, pilots and gradual rollouts are used to detect support needs, degradation and differences between profiles. An A/B test can evaluate a specific change, but it doesn’t replace recovery, security or capacity tests. And it’s worth comparing devices, networks and usage patterns so you don’t attribute to the change what belongs to the context.

All of this forms a learning cycle: measure, interpret, decide, verify. On each turn you document the problem, the evidence, the hypothesis, the intervention, the owner and the result, and you check whether the fix improved the experience and reduced the cost of sustaining it. Maintenance design doesn’t end at launch: it is an iterative process of constant learning.

I come back to the playgrounds and the hearing aid. In both cases, thinking about life after the debut changed both the object and the service that came with it. That is the part that excites me most today: maintenance isn’t only a cost to manage; many times it is a source of opportunities.

Repair, refurbishing, spare parts, extended useful life, specialized support, service levels with differentiated cost by type of customer. In digital, maintenance evidence also reveals new segments, integration needs and operational services nobody imagined at launch: market diversification born from real use.

With one warning: the opportunity to charge for an additional service is one thing and the incentive to create dependence or avoidable failures is quite another. Support tiers can vary in accompaniment or response times; basic security obligations must be met for every customer.