7 things to do before starting IoT product prototyping

Suppose that you have done some research and created a Lean Canvas for your product. You’ve also studied your competitors and are aware of who and how you will outperform. Your engineering team has created PCBs and the system algorithm. Now that you have a device mockup, you are prepared to build your IoT device prototype. 

‍What are the IoT prototype and prototyping?

An IoT product comprises 3 components:

• physical device – hardware component (1. devices themselves – a PCB, sensors; 2. embedded software that makes devices work, and is inseparable with them);
• UI application;
• backend.

Prototyping of Internet of Things devices can be further classified into developing a minimum functional unit covering the below aspects:

• A User Interface (UI) on either a web app or mobile app or both;
• A hardware device with the chosen IoT protocol;
• Backend system to drive the business logic; 
• Connectivity of all the 3 components.

Since the development of hardware products is the primary focus of our company, we would like to share our knowledge of prototyping a hardware component of an IoT system.

A hardware prototype is a physical version of your product which is developed for testing. Prototypes can vary, and they should, in our view, match a corresponding product development stage.‍

Make a plan

As our experience proves, you should take some time to carefully consider your plans before you begin prototyping your Internet of Things device. You should adhere to the following 7 steps to take the most of the prototype stage:

1. Decide what you want the prototype to assist you with. We’re not talking about the entire system now, but specifically about the prototype as a milestone in new product development.
2. Define the testing methods for the prototype.
3. Verify the overall IoT system and each individual device in it using calculations and models.
4. Mock up individual assemblies and subsystems that cannot be tested using calculations or models from step 3.
5. Calculate the cost and availability of components.
6. Select industrial solutions.
7. Consider the prototype from the viewpoint of the user.

1. Begin with "WHY"

The objectives of prototyping are different from those of developing an entire product. For Internet of Things devices, we usually highlight the following goals: 

• To test whether the conceptual technical solution achieves the desired user characteristics;
• To show a prototype to a potential customer or investor; 
• To evaluate the technical capabilities and functionality of the product under load, or to evaluate the rickiest technical solutions. 

Say, you want to market a smart motion sensor for shopping malls. Checking Amazon and AliExpress would be our first piece of advice (which is a bad joke proved by our experience). However, if you take this product as an abstract example, the aforementioned prototyping objectives might be stated as follows: 

• To create a prototype without an enclosure that you can install in your office to see how accurate it is at counting the number of entering guests or employees, and at the same time to find out how much power the system uses when it operates close to how it would in real life;
• To build a prototype in an exquisite enclosure and write a simple data collection application to show the entire system at an exhibition;
• To create a prototype and place it on a test stand that stimulates a big flow of people to assess the sensor response time and peak power consumption.

Set reasonable objectives for yourself. For instance, testing in a real mall is not a good objective for the first prototype of our sensor. Most likely, something will go wrong at the start or even the mechanical installation phase – the prototype may simply lack the proper holes in the enclosure. 

To set the right objectives, we recommend studying technology readiness levels. This will allow you to go from simple to complex, and build a reliable technical solution for your Internet of Things devices. That’s what we frequently call our projects – TRLs.  The TRL-4 sensor prototype, for instance, makes it clear to everyone in our company that the prototype will be tested in a lab setting. 

2. Define How to test results

Plan out how you will test your prototype. You need to have a plan for the parameters you'll be testing and how you'll be testing them. It is preferable to organize your ideas as a table that lists the parameter, its goal value, and the testing method. Use a storytelling technique to express the hypothesis and the anticipated outcome in words for qualities that are challenging to give an objective estimate for. 

This table demonstrates that you lack the necessary tools and expertise. It’s best to identify the issue before investing time and money in a prototype.

If going on with the example of our sensor, then one of the parameters might be the greatest sensing distance.  In this case, it’s easy enough to complete our expectation-reality table. 

You will need storytelling to test, for example, the ergonomics of the enclosure. You make up a story about how the technician would install the sensor. After that, you hand it over to another technician, who hasn’t worked with the device, and ask them to install the same sensor. Your job will be to watch for and record any inconsistencies with your story.

You obviously can’t resist the urge to try out your prototype yourself. Nobody forbids it, but keep in mind the mantra of sales managers: “You’re not relevant”.

Some parameters are costly, challenging, or even hazardous to evaluate on your own. So they might require unique setups or tools, such as a climate chamber, or they may need to be verified in approved labs. It would be wiser in this situation to consult professionals rather than refuse testing. Prepare a test program and technique that will serve as a framework for them. 

Product owners frequently cut corners and ignore their product’s flaws. It’s easy to tell yourself “So intended”, and convince your colleagues of that, in case of failure. Don’t fall into such a trap. 

3. Check yourself with simple calculations

Before you begin prototyping, go over the schematics and drawings once again. Verify the design calculations once more. Look up references and free publications on the web. It’s possible that some of the queries you raised in step 1 have already been addressed by someone. That way you can formulate the problem more precisely.

For an IoT product, for example, you can calculate the theoretical power consumption so that you don’t run into this problem after plugging the battery into your prototype.

Compare the estimated cost of the product, based on the current design, with the value you put in your business plan. If the difference is large, the best course of action is to return to the design phase and consider cost-cutting options. 

Miracles do not happen. If a Customer approaches us with a $150 prototype and requests to reduce the price to $5, it’s either not achievable or necessitates whole new technical solutions. This means that all previous work will be crossed out. The functionality will require engineers to reevaluate their options.

4. Create a POC to test critical functionality

We are not going to speculate here about the meaning of the term "critical”. Every product owner knows what their product predicates on. According to our experience, the POC is a crucial step that can help you save a ton of time. Because the POC may not accurately represent the entire system, we constantly distinguish it from prototyping.

For IoT devices, the range and quality of connectivity to the network or other devices, as well as power consumption, will be the key features. 

For instance, your product must provide data simultaneously across Bluetooth to several devices. Then it would be sensible to put together a POC to evaluate the signal stability and distance. 

This will give you the information you need to choose the parts and antenna options for your device.

Also, you can run the main parts through different modes of operation and check their power consumption. 

A POC allows you to test the viability of a product, is quite distinct from fully-featured prototypes and much more so from mass-produced solutions. At the POC stage, we advise using a breadboard, low-cost parts, testing modules separately, utilizing standard solutions, and ready-made assemblies. Understanding every dependency in your POC is crucial. The causes and consequences of the system’s behavior must be visible. All the knowledge you gained will need to be double-checked during prototyping.

5 Use the industrial approach

An MVP of an IoT could be assembled from ready-made electronic modules, such as Arduino and Raspberry Pi, and open platforms. The resulting MVP prototype will be unstable and the functionality will be incomplete.

To test such a device on actual people would be costly and even dangerous. It has to do with the fact that software can be used to increase functionality, but the product's iron core needs to be 99% complete before testing. There is a risk of drowning in the same-type complaints, which:

• won’t add up value to your product;
• will spoil your brand opinion - users will find it hard to make themselves think that it's just a prototype. Rather, they will register that the quality of the product is at a low level.

By no means do we discourage the use of an Arduino or Raspberry Pi. You must realize the objectives you establish for yourself. The Raspberry Pi prototype would be excellent for exhibitions or as a starting point for creating the system's server component.

Don't forget to check the compatibility of the software and hardware components. During the prototyping, it’s okay to encounter some glitches and failed iterations. Don’t lose heart and keep persevering until you have a full, working prototype in your hands. And just be careful while going through step 1.

6 Look into the future

Check the year of manufacture and availability of electronic components in stock. Is this component available for purchase? Does the manufacturer recommend it for new projects? The goal is to make sure that the component is not being discontinued.

It is often the case that your IoT product is part of your hobby, something you do at weekends. Such developments can go on for months or even years. For example, you're building a motion sensor, which we discussed earlier. You started doing it in 2019, designed the circuit board yourself since you've always been into electronics. You assembled the POC and wrote test firmware. You started making the case design. Then the pandemic struck and you put the project on hold. After returning to normal life, you made the decision to pick up the project again. You finalized the enclosure model and are ready to create a prototype.

Therefore, we advise employing the most recent components and iterations of existing ones in your applications when they are first being developed. This will enable you to obtain a novel technical solution without the drawbacks or prior iterations. Newer models of components could cost more than previous versions, but their price will balance off after the supply grows and the old models are no longer available. Reworking an entire project because your components are discontinued carries a cost risk that is not comparable to overpaying a few dollars per chip.

Therefore, check the manufacturers’ websites and verify the production status of components. 

‍‍

7 Don’t forget about the user

You may have already done some or all of these steps. Consider them from the viewpoint of an end user.

We work a lot with technology enthusiasts, entrepreneurs with a technical background. These people offer the market non-standard solutions, make effective processes where people have been losing time, money and nerves for years. In the pursuit of an innovative technical solution, any techie can forget about who it is all created for. Your prototype should not be an end in itself, but a tool to help you understand your customer. The hardware prototype should help you:

• test the work of the UI;
• take into account the interests of specialists who will maintain the system;
• build the right server logic and test the back end of the system;
• test the system for compliance with standards.

An IoT prototype should always be tested in conjunction with the rest of the product. For example, the sensor in our example has very low power consumption when collecting and transmitting data to the server. On the outside everything is fine, but when testing the system as a whole it may turn out that we are polling it too often. The majority of power is used for checking the status, not for transferring useful data.

Or you may have established outstanding communication stability with the server, but the User needs to make additional settings in order to use it.  If these settings are hidden deeply in the menu, the average buyer will never discover all the enticing features of your product.

When formulating the goals and requirements for a hardware prototype, in our opinion, it is crucial to keep in mind that it’s only part of the IoT system. No matter how advanced the technology in your product is, the user doesn't care. They anticipate that it will effectively address their difficulties.

‍