A system integrator I've been working with asked us for a quote earlier this year on an industrial PC platform for a new project. Their first requirement was clear:
"Use the latest generation Intel CPU."
I understand why they asked. Latest generation looks like the safe choice on paper. Higher benchmark scores. Longer expected support runway from Intel. Newer instruction sets that future software might depend on. The customer's own procurement team probably approved the spec because "latest" sounds like "less risky."
I had to tell them, gently, that I thought they were asking for the wrong thing.
Because their real requirement — the one hiding underneath "the latest CPU" — was something almost the opposite:
They needed the same hardware BOM to still be available in year 5. Their end product would ship to their customers for several years. Every mid-project hardware change would trigger revalidation cycles, re-certification, retraining for their assembly line, and updated documentation for the customers already using the earlier units.
That's not a "latest CPU" requirement. That's a "predictable lifecycle" requirement.
And in industrial computing, those two are often opposites.
Every new Intel CPU generation resets the industrial availability clock. The moment a new generation launches, Intel starts moving manufacturing capacity toward it and away from the outgoing generation. Vendor support windows begin counting down from that day. For a CPU generation released 6 months ago, the practical industrial supply runway is often shorter than for a CPU generation released 2 or 3 years ago that's already deep in its industrial extended-life program.
That's counterintuitive. It shouldn't be true. But it usually is.
Intel and the industrial ecosystem know this and manage for it — hence the embedded roadmap programs and long-life SKUs for older generations. But those programs don't cover the newest launches. They cover the generations customers stopped fighting for.
Once I explained this to the integrator, the conversation changed. They went back to their end customer, checked what the software actually needed (nothing that required latest-gen features), and came back with a revised specification: an earlier generation Intel Core i5, matched with a platform that had documented multi-year supply commitment. That's what they ordered. That's what shipped. And two years later, they're still shipping the same BOM to their customer, without a single mid-project hardware change.
I've had versions of this conversation many times now, across different customer profiles. The specific requirement changes, but the underlying pattern repeats:
The customer states a specification. What they actually need is a different specification, often the opposite one. And no one has taught them to ask the difference.
Some examples I've seen recently:
→ "I need 4 LAN ports" — real requirement was often 4 independent camera networks, or EtherCAT master compatibility. Any 4 ports won't do; specific NIC chipsets matter.
→ "I need TPM 2.0" — real requirement was sometimes just Windows 11 Autopilot registration, which fTPM covers. Sometimes it was FIPS-compliant discrete TPM. Same words, very different platforms.
→ "I need industrial-grade memory" — real requirement was often long-term supply consistency and BOM predictability, not necessarily ECC.
→ "I need the thinnest bezel possible" — real requirement was often that the display would become part of the visible face of the customer's product. Different problem, different solution.
→ "I need the highest brightness display" — real requirement was often "readable in direct sunlight without going black," which involves optical bonding and anti-reflective treatment, not just nits.
Each of these looks like a hardware specification. Each is actually a project decision hiding behind a hardware specification. And when the supplier just quotes what the customer asked for, the specification gap doesn't surface until year 2 or 3 — usually when it's most expensive to fix.
What I've learned to ask in almost every specification conversation now, before I quote anything, is a single question:
"What problem is this requirement intended to solve?"
Most of the time, the customer knows the answer. They just haven't been asked. And once we both have the real answer on the table, the specification often changes. Sometimes to a cheaper platform. Sometimes to a more expensive one. Almost always to a better-fit one for the actual project the customer is running.
For OEM engineers, system integrators, and procurement teams: what's the last requirement you specified that turned out to be different from what your project actually needed? Curious whether the gap got caught early — or only after the hardware shipped.