Start Your IoT Product Development Off Right

If you want the best chance of a successful IoT product development project, you need to start with a focus on early preparation. Without proper planning and documentation, you can easily create project dead-ends that waste a lot of time and money. You can even paint yourself into a corner where you think you’re done – until you realize you have to change something major. There are many pitfalls and unforeseen problems that can be avoided through proper documentation of your use cases and requirements. After all, you wouldn’t construct a house without a blueprint. The same goes for electronic device development.

Below, we’ll discuss these early steps in product development in a bit more detail.

Step 1: High-level discussion

At F3, every development project starts with a high-level discussion. We use this time to establish the use cases, actors (who will use the device), and how they will use it. This includes a checklist of questions, including:

• Geographic markets where it will be used

• Parts that must be included in the design, including long-term availbility

• How it will be powered

• Preferred vendors or suppliers (established business relationships)

• What can and can’t change with the design

• A description of how the device will be used once in production

• Security, data, connectivity, and product lifecycle expectations

We also use this time to define roles for each stakeholder in the project.

Step 2: Requirements gathering

Once we understand the use case, we will start gathering and documenting requirements. At F3 we always give this phase the attention it desrves, as the documentation provides the foundation for the rest of the project.

The requirements phase outlines what the device will do. We discuss mechanical, software, regulatory, cybersecurity, data, and communication requirements, including, but not limited to:

• Environmental considerations (temperature, vibration, moisture, size constraints, etc.)

• Certification requirements

• How the device is to be powered (wall power, battery, etc)

• How the device will be provisioned for use during manufacturing

• How the device is set up, used, monitored and supported in the field

• How the device firmware will be securely updated over time

• How data will be collected, stored, accessed, and protected

This is also where we make sure every stakeholder agrees on what will be built, tested, and supported.

Step 3: Design and testing

Once the requirements are determined and agreed upon, the project can move into design. We estimate costs and timelines for the rest of the project and get everyone aligned

There are two paths the design of a device can take:

1. Proof of concept (PoC) – This is typically a prototype that can prove feasibility and functionality to investors and stakeholders. These typically are not full designs, but are scaled down in terms of features. Off-the-shelf development kits can often be used as a starting point, and elements of the design may or may not be used in actual development once a project gets the green light. It’s important to understand that the nature of a proof of concept is to do things quickly and cheaply unless it is intentionally built with production requirements in mind. Thus, much of the work done for a PoC may not be usable for the real product.

2. Fully funded project – This is when we start creating specifications for the actual product right away and start selecting high-level components. This includes firmware, mechanical design, system architecture, electrical components, modems, processors, and security requirements.

All engineering is iterative. You design as much as you can of the real product, build it, and test it. Then you take everything you learned, adjust the design, build new prototypes, and test again. This cycle is repeated until the results are good enough. The requirements define what “good enough” means. The first iteration is typically a printed or machined prototype of the mechanical design, the first electronic assembly, and firmware features that enable hardware and security testing to see if changes are needed. Then, in the second phase, we develop what is intended to be the final design, perform design verification testing again, and start preparing for certifications, including security-related requirements where applicable, so there are no surprises. The key in this phase is to have accurate, signed-off requirements that best reflect the product functionality.

Test and manufacture with confidence

Even after you test the implementation to meet requirements, you still have to complete system-level validation testing to ensure the product works with everything else in your system and meets government, agency, and cybersecurity certification requirements. This is where your preparation pays off, as you do not want to miss any requirements or use cases that will come back to haunt you down the line.

Typically, we start setting up the manufacturing process after the first development phase. The pilot production run is when we can accurately test devices in the field. At this phase, any kinks that need to be worked out can be fixed before scaling up production. This is also the time that manufacturing test support is discussed so development of a manufacturing tester can be planned, quoted, and started.

Good product requirements and use cases are essential to successful product development. There’s no “secret sauce” to achieving success. Just requirements that are thoroughly documented, fully reviewed, and a product that is properly designed, tested, and supported. And F3 can help you do it right.

Read about how F3 provided complete development, design, and manufacturing management for GotRad, a wireless product company: https://f3wireless.com/gotrad/