The document that prevents projects from quietly derailing
The simplest way to turn EMC uncertainty into a managed risk
Hi reader,
If you are responsible for a product that must pass EMC, you already know this feeling:
Despite regulations, standards, and experts,
EMC often feels unclear and unpredictable
You rely on your team, they are experts, the know And still, when testing approaches, uncertainty and panic rises
This is exactly why EMC so often turns into a gamble. My goal is simple: turn EMC from a gamble into a managed risk
Very early in a project, you are told to produce a technical description of the product
On paper, this sounds easy. In reality, it often fails because everyone interprets it differently
When the technical description is vague or incomplete, only a few people truly understand the product. Everyone else fills the gaps with assumptions
Poor technical documentation → uncontrolled EMC risk
If a question cannot be answered early in the project, it will not magically become clear later
The difference is timing:
Now: you have time, options, and flexibility
Later: you have pressure, costs, and deadlines
Early clarity keeps teams calm and decisions rational when EMC pressure increases
What a useful technical description actually contains
A technical description is not just paperwork. It is a shared reference point that aligns design, testing and management. And keeps customers happy.
What to write in a technical description?
At minimum, it should cover:
Product identification
Product name and model (or models, if more than one)
Product category (industrial controller, consumer electronics, medical accessory)
Intended market (industrial, residential, automotive)
Operating environment
Intended function
Intended users: skilled professionals or consumers
Installation environment: cabinet, residential room, vehicle, hospital
Type of operation: continuous or intermittent
EMC relevant electrical architecture
Power supply type: AC/DC, DC/DC, adapter, battery
Nominal input voltage(s) and frequency
Switching elements
Clock frequencies: processors, RF if any
Presence of intentional RF transmitters: yes/no, communication band
Interfaces and external ports
Power input(s)
Communication interfaces
I/O ports (analog, digital, sensor inputs, actuator outputs)
Cable types and lengths (fixed / variable / customer-supplied)
Shielded / unshielded connections
Operating modes relevant for EMC
Normal operation mode
Worst-case or maximum load mode
Communication active or inactive modes
Installation aspects relevant for EMC
Enclosure type: plastic, metal, mixed
Grounding
Mounting method
Cooling method
Variants
Hardware variants
Firmware versions
Optional accessories or modules
Your job as product owner
Your job is not to know every technical detail. Your job is to:
Ensure the right questions are asked
Collect the information
Keep it consistent and up to date
Do this well, and EMC will be less and less a late-stage surprise
How are you dealing with the uncertainties of EMC in your project? Reply to this email, I would love to hear it.
Link correction
In the previous chapter Standards are (not) boring, the link to the The guide for the EMC directive. was wrong. It is now corrected 🙂
Happy building! ⚒️
Ignacio