Most product instincts are calibrated to a user in their normal day - someone with spare attention, a few seconds to look around, and the option to come back later if the tool gets in the way. Operators under load often do not have that luxury. They are running a live operation through your product, the operation does not pause for the tool to catch up, and the minute that decides whether the product is any good is the worst minute, not the average one. Almost every instinct I had carried in from normal product work broke the first time I built for that context and the interesting part was working out which instincts to keep and which to throw out.
I have seen this from both sides. For 5 years I was the PM leading a real-time platform that sits at the centre of an airport’s operations - the system airport duty managers, operations controllers, ground handlers and other service providers use to decide which aircraft taxis where, when a stand reopens, and how to absorb a delay before it cascades. The platform scaled to dozens of airports, with the largest ones having over 50 critical systems and data integrations feeding it.
Before product, I was also an operator. Early in my career, I worked as a junior doctor in one of London’s biggest hospitals, and I ran patient care through software during exactly the conditions where a clumsy tool costs you attention you do not have. And I spent a couple of years on the trading floor at a large US investment bank and a market maker, which is the same problem again in a third domain.
The operators
It is worth being precise about who this is, because the category is narrower than “professional users” and wider than any one industry.
An operator under load is someone for whom your product is not the task but the instrument the task runs through, under time pressure, with real consequences for getting it wrong, and usually with several other things demanding attention at the same time.
An ops controller deciding stand allocation, a doctor managing a deteriorating patient across three systems, a trader managing exposure into a print - the surface differs but the shape does not. The work cannot stop for the tool, there is no “I’ll deal with this later” and the consequence of a slow or confusing product is not just a worse experience but a worse decision in running that operation.
That shape inverts a few defaults that are otherwise safe. In normal product work, you can design for the median session, treat attention as roughly available, add features because more capability reads as more value, and assume the user will adapt to your product model. Under load, each of those can be costly mistakes.
The following four shifts held true across all three domains, be it medicine, finance or aviation. The domain itself only put into perspective how important it is to take them into account when building products within that particular area. I hold them as observations from inside the work rather than strict constraints, but they have transferred across three large, complex domains, which is more than most product lessons get tested against.
The worst minute, not the average minute
During an extreme weather event at one of our larger airports, the data flowing through the platform jumped 5-10x its normal rate for hours at a stretch. Some integrations went from a few hundred messages a second to over a thousand. Active users roughly doubled over the same window. Both happened at once, as it usually happens with disruptions: more data arriving, more people needing to see it, more decisions needing to be coordinated, all in the same hour. The load on the system and the load on the people peak together, which is precisely when the product matters most and precisely when it is under the most strain.
The platform held, but only because we had built for that hour explicitly rather than discovering it during the crisis. If we had sized capacity to the average minute, the system would have degraded at the exact moment it was most needed - and a tool for operators that fails when the operation is hardest is not a tool that mostly works with an occasional bad day. It is a tool that fails at its job, because its job is the bad day. The average minute does not need much of a product, because it is much easier to manage a calm operation.
The shift here is that the design target moves from the average minute to the worst one. That changes ordinary decisions. Capacity overhead has to exist before the surge, because there is no time to provision it during the surge. Degradation has to be graceful and legible, so an operator can see what the system is still doing rather than guessing. Latency budgets are set against peak concurrency, not against the steady, calm state.
This only gets prioritised if the worst minute is the thing you are designing for, and the default pull of a roadmap is always toward the common case. From my experience, what is worth asking early is not “how does this perform normally” but “what does the worst hour this product will ever see look like, and have we built for it or just hoped we would not face it”.
Don’t compete with the operator for thinking
An ops controller making a stand-allocation decision has somewhere between 5 and 30 seconds before the next decision arrives. Inside that window, anything the product demands that is not about the decision itself is a tax on the operator’s actual job. Filtering, finding, switching context, navigating a menu - all of these are impactful. Each one siphons off attention the operator needs for the work the tool exists to support. The tool is supposed to be carrying part of the decision, and instead it is competing with the decision for the same scarce resource.
This is the shift I felt most directly as an operator rather than a builder. Managing acutely unwell patients, the attention cost of fighting software was practical - it was a worse decision, made slower, with cognition spent on the interface that should have gone to the patient in front of me. A system that makes you hunt for the value before it can change your decision has, by the time you find it, already taken the thing you could least spare.
So the work is to remove the tool from the cognitive path rather than add to it:
- Custom views, shaped to a role, so the state that matters is already in front of the operator.
- Filters that apply in a single click, keyboard shortcut or a hotkey, not in three separate steps.
- Search that supports the way a person under pressure actually types, with shortcuts and partial matches rather than exact strings.
None of these were technical achievements and none of them demo particularly well, because the value of each is something not happening: a context switch avoided, a step removed, a question the operator did not have to stop and form. The normal-product instinct is to add features, because a feature is visible and more features reads as more value. Under load, the instinct that worked was the opposite: the value was in the surface area that disappeared. The test a change has to pass is whether it reduces the thinking the operator spends on the tool, and a surprising number of “improvements” fail that test because they add a capability at the cost of a decision.
Defaults are decisions
There is a test worth running on every default and constraint in an operator product: in the worst hour, what does it prevent and who does it lock out? For example, a commonly used commercial model for professional software is per-seat licensing. It is a reasonable model for a tool people use occasionally, and the wrong one for a tool at the centre of an operation - and the reason is operational, not commercial. When a disruption starts, the operation wants every relevant stakeholder (the duty manager, the ops controller, the ground handling supervisor, whoever turns out to be needed) in the system within minutes, with the right permissions. A per-seat limit turns that into a budget decision made in advance instead of an operational one made in the moment. Someone ends up rationing seats, and the person locked out during a calm week is the person most needed during the surge. A constraint like that has to come out of the operator’s path the same way a three-click filter does.
Every default in a product is also an operational decision and often a business one, whether or not anyone framed it that way. A default filter, a permission model, a notification threshold, a rate limit - each encodes an assumption about how the operation runs, and under load the wrong default does not just annoy the user, it blocks the operation. On the trading floor, I learnt that the defaults a desk runs with - what is shown, what is one key away, what requires confirmation - are not interface preferences, they are decisions about what the operation can do in the seconds it has. The work is to notice which of the defaults are silently making operational decisions, and to make those deliberately rather than inheriting them from a pricing model or a framework’s out-of-the-box settings.
Absorb the environment
Airports do not get to choose the systems they integrate with. They have flight information displays built in different decades, baggage handling from various vendors, old or very old security systems, and third-party feeds each carrying their own protocol. A standard data engine that assumes a predefined transport and a clean schema breaks against that reality on the first connection. A product that wants to sit at the centre of that operation has to invert the assumption: a routing layer that does not much care what format the data arrives in or how it gets there, and turns the mess into something the rest of the platform can rely on. That flexibility is a minimum requirement for the integration to work at all.
This does not just apply to the aviation industry. For any product that sits in the middle of an environment someone else already built, the job is to absorb the messiness of what exists rather than to demand that the environment conform to your shape. The operator cannot rip out the systems they have, and they will not, so a product that requires a clean world to function is a product that does not function where it is needed. Some may argue that this cuts against a reasonable business instinct, which is defining the interface you want and making everyone else meet it. That works when you have the leverage to set the standard. In someone else’s operation you almost never do, and the leverage instead comes from being the component that fits everything else - the part of the system that adapts so the rest of it does not have to. None of this is free - absorbing variety means more code, more edge cases, and integration work that never quite finishes. But the alternative is a product that only runs where the environment is clean, and operators do not work in clean environments.
Where the bar sits
Operators under load exist anywhere the work cannot pause for the tool: trading floors, hospital wards, network operations centres, emergency response, airport operations rooms. The specifics differ and the four shifts seem to hold across them - design for the worst minute, stay out of the operator’s thinking, treat defaults as operational decisions, and absorb the environment rather than fighting it. For operators under load, the product is judged in the worst minute, and everything that matters during that minute is actually built way before it arrives.