80°C — where the PowerPoint ends and the product begins
A HW+SW product isn't ready when it passes the demo. It's ready when it survives the field. On thermals, compliance, and the Field Readiness Gate.
80°C doesn’t have to mean failure. It’s the CPU core temperature at which a lot of embedded platforms stop behaving the way they did in the demo. The processor throttles so it won’t fry itself. The model drops frames. A retry loop heats the board. The system still “works”, just slower, less stable, and in ways nobody tested.
On the slides everything looks ready. Sales has a date. The board has an expectation. The customer has a promise.
Then the field arrives.
And the field doesn’t test the feature. It tests the whole chain of decisions that led to that feature: power, mounting, thermals, workload, support.
A HW+SW product isn’t ready when it passes the demo. It’s ready when it survives the conditions the customer won’t know how, or want, to debug.
The field isn’t a stress test — it’s normal
The gap between the lab and the field is mundane, and companies keep losing on it:
- Temperature: not a 22°C office, but a 38°C production hall or -5°C at the customer site
- Mounting: not a precise test rig, but a rail under the ceiling with whatever cable was around
- Power supply: not the one R&D approved, just “the one that was there”
- Workload: not a 5-minute demo scenario, but 8 hours of continuous run with no restart
None of these conditions is a surprise. Every one is known from day one of the project. The problem isn’t that they couldn’t be predicted. It’s that nobody owned turning them into a decision gate. R&D looks at its piece, procurement at its own, compliance at its own, sales at the deadline. The gap between them, the moment the demo has to become a product in the field, is rarely anyone’s job.
Four places where HW+SW fails quietly
In pure software the bug sits in the code. In HW+SW the bug can be physics interacting with logic, which makes it harder to find: the symptom shows up far from the cause. Four common ones, ordered from the most visible to the most deeply buried.
The CPU throttles, the product slows down. The device processes video or data in real time. At high temperature the processor cuts its clock to bring the heat down. The model starts dropping frames or answering late. Support hunts for a software bug while the problem is temperature. The log doesn’t say “throttling”. It says “slow response”.
A firmware retry loop heats the board. A communication error spawns a loop: try, timeout, retry, hundreds of times a minute. Invisible under normal conditions because it’s too rare. In the heat it adds a few more degrees on the board and triggers the same throttling as above. You only see the correlation once you line the comms logs up against temperature.
Premium enclosure, no thermal path. Slick design, IP65, great photos for the brochure. With IP65 the enclosure is sealed by design, so you can’t just ventilate it. The heat has to leave some other way: conduction, a thermal pad, the mass of the housing, a heat sink sized for the real load. If the industrial design was signed off without a thermal review, that path usually just isn’t there. The problem isn’t the sealing, it’s the missing designed heat path. Who, and at what stage, was supposed to put that gate up? The PM.
A power supply with a label, not a system spec. On the supplier’s page: 12V 5A, 120 mV ripple. System requirement: 50 mV. Same catalog number, actually a different manufacturer. The supply meets the component spec but not the system spec. That’s the difference a PM has to understand: a component datasheet is not the same as a system requirement.
One question — and what to do with the answer
A PM doesn’t have to design the heat sink. They have to know the moment its absence becomes the customer’s, support’s, and the margin’s problem. And one question is enough:
“Where is the test report for this device: sealed, in its target mounting, on the final power supply, under full workload, for 72 hours at the maximum ambient temperature in the product spec?”
Skipping the environmental test isn’t saving time. It’s moving the cost from R&D onto support, the customer, and your reputation. A “72h sanity check” isn’t full environmental validation. It’s the minimum that moves the risk from “we don’t know” to “we know what can go wrong and we have a plan”.
The power supply that cost six months
A company wanted to change the switching power supply in one of its devices, a PLC controller. The reason was mundane: the old model was going out of production. Except the change touched both spare parts for hundreds of existing installations and new units going into production at the same time. It wasn’t a purchasing problem. It was a business-continuity problem.
A replacement was available. But the regulations had changed in the meantime, and its certifications forced a different flammability class. To get there, the whole controller’s fire protection had to go up: non-flammable wiring inside, extra safeguards, and a destructive test on one unit, burning a controller to see how it behaves in a fire. On top of that the new supply ran too hot.
From spotting the problem to deciding what to do about it: six months. Spare parts were stuck, new units waited on an approved BOM, and the team went in circles between the supplier, compliance and procurement.
Lesson learned: swapping one component in a certified device isn’t a swap. It opens the whole chain: certification, wiring, thermals, supply chain, and the rest of the technical dependencies. The earlier you know them, the cheaper your options are.
The decision gate — before the product ships
I call it the Field Readiness Gate: a single decision gate between “works in the demo” and “ships to the customer”. It’s not full environmental validation, just the minimum someone has to own before the device goes into the field.
Environment and design
- Environmental tests matching the requirements for that product type, or documented confirmation that the internal components meet every requirement and the product can be approved on that basis
- A PoC at the final customer, in a test location or a lab that’s closest to the real load at the end customer
- Target mounting: orientation, fixing, distances from walls and other devices
Load
- The full operational workload, defined concretely: what runs, which processes, what intensity
- Retry behavior: what happens on communication errors under load and high temperature at the same time
Monitoring
- The system logs CPU temperature, throttling state, voltages, restarts, communication errors
- An alert threshold before throttling, with an action on breach, not just a notification
- It’s clear what data to collect when someone reports “it’s slower” or “it hangs”
Decision
- Who has the test report? Who signed off the deviations? What are the conditions limiting the pilot?
Your product ships to the customer in six weeks. Ask one question: is there a test report in the target installation conditions, at the maximum ambient temperature in the spec?
If there is, you have a basis for a decision. If there isn’t, you don’t have a product ready for the field yet. You have a demo with a sales date.
Then there are three honest options: delay the release, limit the pilot to controlled conditions with monitoring, or knowingly accept the risk and write down who made that call.
The worst option is to pretend that missing data means no problem. In HW+SW the risk doesn’t disappear. It waits until the customer finds it.
If your product is heading toward a pilot and you’re not sure it will survive field conditions, let’s check it before the customer does.