A connected electronic product is not simply a standard device with an attached radio.
On the surface, adding connectivity sounds like a simple, isolated decision: choose a wireless protocol, integrate a module and write some firmware to handle the communication.
In practice though, that single decision affects power budget, antenna placement, enclosure geometry, compliance obligations, backend architecture and the software layer where the product’s commercial value actually lives.
This guide explains what electronics product design for connected devices genuinely involves. It covers which decisions carry the most weight early on, and explores why hardware, firmware, connectivity and software need to be understood as one system rather than a set of workstreams to be handed off in sequence.
What IoT Electronics Product Design actually involves
Designing a connected electronic product (IoT product) means bringing four disciplines together as one system.
1. Product design is the physical product: the enclosure, its ergonomics, its aesthetics and how the end user experiences it. The design is one of the most underestimated parts of the process.
Decisions about a device’s form, material, size, mounting or servicing and how it communicates its state to a user all directly shape its layout, antenna placement, thermal management and manufacture.
Product design is not a finishing layer. It runs alongside electronics and firmware from the very first architecture conversation.
2. Electronics hardware is the foundation of the printed circuit board (PCB) assembly. It handles sensing, processing, power management and communication. It’s essential to integrate component selection, PCB layout, connector positions and thermal design with the enclosure and firmware development from day one.
3. Firmware is the embedded software that controls the hardware. This includes power states, communication timing, diagnostic modes, update handling and security behaviour.
Firmware requirements shape hardware decisions. Hardware constraints shape firmware capabilities.
They are not two separate workstreams.
4. Connectivity and software act as a bridge by which the data leaves the device and reaches the web or app layer where it becomes useful. For a significant number of connected products, the thing the end user actually buys is the web view.
A practical example is a smart energy monitor.
The hardware measures consumption, and the connectivity carries it. The value to the user is live pricing, automated switching and visibility over time. Without the software layer, the hardware has no commercial purpose.
Decisions in any one of these disciplines directly constrain the others. It all starts with making early choices across all four disciplines: data frequency, update strategy, diagnostic capability and security architecture.
Where the complexity lives
Around 5.7 billion people worldwide own a smartphone. Most people use one every day without giving a second thought to the wireless engineering inside it.
Such familiarity is useful in daily life, but it creates a blind spot when starting a connected product project. The assumption tends to be that because wireless connectivity is everywhere, adding it to a new device is straightforward.
It is not.
Teams of hundreds of engineers build smartphones, and their sole responsibility is making wireless performance invisible to the user. The same underlying complexity is present in any connected product, including relatively simple ones.
Three areas consistently present the greatest challenge.
1. Antenna placement
An antenna needs clear space, away from metal.
A larger physical size improves its performance, while its position in the enclosure affects range, data rate, power draw and connection reliability.
Leaving antenna placement until the final enclosure design severely limits your options, reducing your choices to varying degrees of poor performance.
Antenna placement is not a finishing detail. It shapes enclosure design from the first sketch, which is precisely why product design and electronics need to be a part of the conversation from the start.
2. Battery life
Battery life is not just a firmware problem. The radio, antenna, PCB layout, operating environment and shipping route all affect the battery.
Carriers enforce specific rules regarding the transport of lithium cells, which become relevant the moment a product needs to reach an international market.
Additionally, temperature affects performance and lifespan in ways that matter more for products installed outdoors or in industrial environments.
3. The relationship between the two
A poorly placed antenna draws more power to maintain a connection, which then reduces battery life or requires a larger battery. A larger battery constrains the PCB layout, which then constrains antenna placement.
These are not independent decisions to be made in sequence. They need to be resolved together, with enclosure geometry and PCB layout considered simultaneously.
This interdependency makes connected product development harder than it first appears. It’s not a single problem. It’s a web of interacting issues.
What to resolve before development begins
A useful rule of thumb in engineering is that a problem identified at the design stage will cost roughly 10 times less to fix than the same problem identified at the testing stage. And if the problem appears after manufacture, it costs significantly more.
For connected products requiring cross-discipline integration, late discoveries lead to exponentially higher costs.
| Decision | What it affects downstream |
| Connectivity method | Antenna design, power budget, firmware architecture, compliance requirements |
| Battery and power strategy | Enclosure dimensions, PCB layout, firmware power management |
| Enclosure and product design | Antenna placement, PCB dimensions, thermal management, connector positions, ergonomics |
| Target unit cost and volume | Component selection, assembly approach, supplier choices |
| Compliance jurisdictions | Test plan, design requirements, certification timeline, cost |
| Security architecture | Firmware design, cloud architecture, compliance obligations |
Decisions on security architecture deserve particular attention.
In 2016, the Mirai botnet attack compromised hundreds of thousands of connected consumer devices. It happened primarily because they shipped with default credentials, no meaningful authentication and no mechanism for security updates. The attack took down large parts of the internet for an entire day.
These devices were not defective in a conventional sense. Their security system was simply treated as someone else’s problem.
EN 18031 and the EU Cyber Resilience Act exist partly in response to exactly this situation. These frameworks now require security to be designed into connected products from the outset in European markets. Clients who have not launched a connected product in the last few years are sometimes surprised to find that features they previously treated as optional are now legal obligations.
Finding this out during certification testing is expensive. Incorporating it in the architecture stage is far more cost-effective.
For businesses adding connectivity to an existing product, these decisions apply with equal force. Integrating a radio into a device inevitably impacts its enclosure design, thermal management and compliance obligations. Businesses must address these factors directly and early on.
Why product design, electronics and firmware need to work as one
Consider how this integration plays out when disciplines fail to coordinate.
A firmware team specifies a large battery to simplify power management, but the enclosure team doesn’t find out until the PCB layout is fixed. Now they are working with a constraint nobody initially communicated.
Or an electronics team positions an antenna for convenient routing rather than RF performance. As a result, the cost appears in the field as unreliable connectivity and a shorter battery life than the specification originally promised. So a product designer receives a locked PCB layout and needs to build an enclosure around it and must work around decisions that should have been made weeks earlier.
None of these are failures of competence. They are failures of structure.
Each discipline made a reasonable decision within its own brief. The problem is that the decisions interacted in ways nobody could predict until it was expensive to change them.
We cover this in more depth in our post on electronic device development fragmentation, but the principle is especially consequential for connected products. Because the interaction between radio, power, enclosure and software creates a category of risk, sequential development is structurally ill-equipped to manage it.
Our process at 3Point1 means product design, electronics, firmware, software and manufacturing readiness work in parallel from day one.
When choosing a connectivity method, the product designer and enclosure engineer must be in the same room, as must the firmware engineer and the owner of the compliance plan. A compromise that one discipline might make on its own becomes a decision that all disciplines make together, with a shared understanding of what it costs.
A typical life cycle of an IoT project
Discovery
A new IoT project begins with a structured conversation to understand the full picture. This includes what the product does, what constraints already exist and what has been built so far.
If technical work has already been done, then the reasons for any decisions matter as much as the decisions themselves.
An undocumented decision is a risk. It might be a hard constraint that cannot move. Or it could be a temporary fix that was never revisited. Until you understand the decisions, you cannot safely build on them.
Architecture
Once the product architecture is clear, critical component decisions can follow.
First, a team chooses the radio, CPU, power system and connectivity method with the enclosure geometry, product design requirements, firmware constraints and compliance targets already in view.
Once they confirm the radio and CPU, firmware development can begin on kits before the final PCB exists.
This way, product design and enclosure work can proceed with known PCB dimensions and antenna placement requirements.
Parallel development
All four disciplines work concurrently, rather than handing work over in stages. This compresses the programme and eliminates the late-stage rework inherent to a sequential approach.
Testing and compliance
The design process integrates pre-compliance thinking. EMC, radio performance and safety requirements are considered during development. This allows for shaping decisions while there is still time to change them, rather than revealing problems when it’s too late.
Manufacture
Manufacturing input is introduced before the design is frozen. Teams can review component availability, assembly steps, tolerances and build documentation while the design is still flexible.
A project in practice: BLE Temperature Sensor Network
A client came to us at 3Point1 with a requirement for distributed temperature monitoring across a large facility. And they needed readings reported online to a central system.
The first significant decision we made was Bluetooth stack selection. We chose Nordic Zephyr for its flexibility and long-term support characteristics.
The client wanted to reuse an existing enclosure and battery rather than design new ones, primarily to contain cost and timeline. Before committing to that direction, our 3Point1 team verified that performance within those constraints would be acceptable. This early check saved significant downstream work.
Managing a large sensor mesh reliably from a single hub turned out to be the most demanding part of the project. The hub was originally designed with Wi-Fi, Ethernet and GSM. This combination added complexity but gave the product genuine flexibility across different deployment environments.
In hindsight, a single-board computer running Linux might have simplified some of that architecture.
Honesty about missed decisions earlier in the process is the key to running better future projects.
Outcome: the sensors have been running in the field on the original enclosure and battery. The early decisions held.
What separates a well-designed IoT product from one that simply has connectivity added
The distinction usually becomes visible 18 months into a product’s life in the field.
A well-designed connected product operates reliably across a variety of sectors. It should:
- Run on battery power that matches or exceeds specifications
- Maintain a stable connection that doesn’t require intervention
- Support remote firmware updates without a site visit
- Feature an enclosure built to withstand the environment it was designed for
- Scale production as volumes grow, without requiring structural rework
Products that fall short of these qualities share a recognisable history.
It could be that connectivity was specified after the industrial design was largely settled, compromising antenna placement from the start. Security may have been deferred because it felt like a future problem. Or the software layer could have been designed without full visibility of what the firmware could deliver.
Product categorisation decisions are generally made in the first few weeks of a programme. This is when they are cheapest to get right and easiest to change.
A pre-emptive checklist
Work through these questions before your first conversation with a development partner.
What do you have?
- What does your product do, and who uses it?
- Do you have existing designs, hardware or firmware? If so, do you know why the key decisions were made?
- What is still unknown or unresolved?
What does the product need to do?
- Which markets will your product sell into, and what compliance jurisdictions apply?
- Does it need to be real-time, low-power, long-range or a combination?
- Is it battery or mains powered, and are there any constraints on enclosure size or form?
- What are the expected production volumes and target unit cost?
What are you not sure about?
- Write these down too. Unknowns that you present at the start become part of the plan. Unknowns that stay unnamed tend to surface mid-project when they’re harder to resolve.
Ready to map your connected product from concept to manufacture?
Contact 3Point1 to book a scoping call. Bring whatever you have. The most useful thing we can do early on is look at the full picture together.
