Explore the guide which will help you define and specify your future hardware or IoT product. In this blog post, we would like to share our experience of shaping and specifying an idea into requirements, and a PRD. Read on to learn more about the process.
Product definition is about specifying technical and feature-related aspects of the product.
Having well defined, specified, and documented requirements will save you precious time and money in the development and prototyping phase. More importantly, it will help you think about your IoT / hardware product from various perspectives and prioritize features, which will inevitably help you design a better product. Consider this as a “how to” tutorial guide if you are truly serious about developing your hardware or IoT product.
0. Make your market research and validate your product idea with potential customers
Although this is not the topic of this article, I still want to make 3 main points here to highlight the importance of your idea validation before specifying the hardware and software of your future product:
- Share your idea with potential customers and listen to their feedback and suggestions.
- Know your competitors! And if you think you do not have any (which is extremely rare), search for product substitutes in the market!
- Make a LEAN “business model canvas.” It will help you think of your product from various business and marketing angles, crucial for further specification and engineering development.
1. Be clear on purpose and the functions of your product
It is essential to define the exact need for creating your new product and answer the simple question: “what problems do I solve with my product? What is the purpose of my product?” The purpose translates to certain functions your product has.
It is generally easier to understand the purpose and functions of B2B hardware products. These are designed to solve a particular business problem, eliminate a specific problem/issue, or cut some process cost down or speed up an operation or a business process, i.e., increase value.
In B2C product development, it is a bit harder to formulate the purpose/problem, as it is typically tied to a particular feature or a parameter that differentiates your device and makes people want to pay for your product.
2. Describe users of your product
Once you’re finished with your new product’s purpose and background, it is a good idea to describe your product’s user. There can be different types of users for your product. For example, for the same hardware product there can be 2 users, for example: an end-user and a service engineer or a technician, or a hospital patient, and a nurse. Some users of your product may use just the hardware device, and other users will have access to only the software part.
3. Define use-cases
With users defined, further describe the use-cases, which are the cornerstone for any design type: electronics, mechanical and industrial. Documenting and describing use-cases may appear to be boring. Still, by getting deeper into the new product development, you will be pushed to write them down yourself, or else you will need to pay an expensive professional design consultancy of a freelance industrial designer to do so.
Of course, one can opt to skip defining the use-cases, but this will inevitably lead to misunderstandings between your team and designers. The consequences will entail an increased number of design + prototyping iterations and feature creep, which, in turn, will become requirements creep, scope creep, and ultimately budget creep.
4. User scenarios/user stories
Enlisted users and use-cases can be further specified in user scenarios. These are incredibly beneficial in designing product logics and algorithms, which help place the product in the relevant environment and allow you to capture the important user-specific features attributed to your idea, invention, or product.
Now the product definition splits into three major parts:
- Specify hardware requirements in your own way(both the electronics, electrical, and mechanical requirements), or in a PRD format (Product Requirements Document).
- Specify software requirements, in the professional world, are typically referred to as SRS (Software Requirements Specification).
- Towards the end of your product development program, you will need to think of specifying:
a) packaging requirements;
b) and CMF (Colors, Materials, and Finish) includes the desired list of materials, colors, and coatings.
The description below focuses on hardware requirements specification. Although at EnCata we provide full end-to-end service for both hardware and software, we generally suggest to keep the PRD/HRS, SRS, and packaging + CMF requirements separate, as there are typically different specialists working on each of these development tracks.
5. List the features of your hardware product
List as many hardware features of your product as you can. Essentially, you can do this exercise in three consecutive steps:
- Try to list and document ALL the features of your future product: for both hardware and software.
- Define the most important features or MVP (main parameters/features of value)
- Prioritize all the features from the very important (list MPVs first) to the least important.
Remember, implementing features in the design will cost you money in the development, and decomposing and prioritizing various features is absolutely crucial.
6. Defining the MPV (main parameters of value)
The term MPV is borrowed from TRIZ/TIPS (https://en.wikipedia.org/wiki/TRIZ) which is another sort of design thinking technique with particular focus in design engineering. MPV lets you laser-focus on the one or two ‘killer features’, or MPVs that your customers are willing to pay for. Do not confuse this MVP with the common MVP (minimum viable product) also used in product development.
In other words, defined MPV(s) is the essence of the customer feedback and your idea validation.
7. How many discrete devices do you have?
It is quite common that products comprise two or more discrete devices. Let us give you a few examples:
- For instance, you are developing a new IoT toothbrush powered by a battery, and you want it to rest and charge on a charging station.
- Or your IoT device and/or IoT sensors use Bluetooth to channel data to a cloud and in order to do it requires an IoT gateway, which is a separate device of its own.
- A case from e-transport can be relevant here: when designing an e-scooter or an e-bike, it is important to have a charging station or at least a charger, so the rover can replenish its battery.
We recommend you carefully weigh the pros and cons of having additional devices as part of your product and minimizing the number of devices. For example, you can get rid of the charging station and rely on micro-USB or C-type USB instead of using a charging station. Or instead of developing the IoT gateway device, you can select an IoT product off the shelf or utilize a common strategy to connect your device to the smartphone/tablet via Bluetooth/BLE. By doing so, you can cut your development and manufacturing costs nearly in half, which will accelerate your market entry and make the development of your MVP product leaner.
8. Specify future retail price / MSRP
Specifying the retail price is tied to your future product’s future production cost (COGS - Cost of Goods Sold). The MSRP (Manufacturer's Suggested Retail Price) terms are the “retail price” equivalents.
Knowing the product cost / retail price target is highly beneficial for designers when choosing the right components and optimizing volume production costs. Design engineers usually use the term ‘design-to-cost’ (DTC), referring to the process of optimizing the development strategy to meet a defined cost and design parameter in the product development process.
The rule of thumb for any hardware business is as follows: the COGS (a combination of BOM - Bill of Materials - cost and other production and logistics expenses per unit) should be around 20-25% of the MSRP.
In startups with a recurring subscription business model, the product’s sales price is kept low: only 120-180% of the BOM or COGS cost. So one can deliver the product to customers literally at cost and enable sustainable cash flow beyond the hardware item sale. These business models have become more and more popular for the IoT hardware startups, as they provide much better LTVs and are much more popular with investors.
9. Your target production size in volume manufacturing
This section refers to DTC (Direct to Consumer) and DFx (Design for Excellence, where X can be inspection, assembly, variability, cost, etc.) strategies, which are to be implemented by the hardware design team. It is enough to provide an order of magnitude number: 100s, 1000s, or tens of 1000s units per year. These ball-park numbers dictate different approaches in product architecture, component selection, and enclosure design.
10. Physical constraints: product weight and dimensions
Estimate and provide the right sizes of your product. Specify if it is critical to have small sizes/dimensions. You may approach this question from the user experience perspective and benchmark your product versus your competitors. Think about how critical is a small size, as designing miniature electronics adds cost to the design. It takes a lot more time and effort to design a small PCB (Printed Circuit Board) because it is a lot harder for the electronics designer to arrange the components tightly and produce a multilayer PCBA. Not to mention the various noise and interference issues that might arise from densely packed copper layers and components.
Weight and dimensions are obviously important in B2C consumer products, but in designing a B2B product it is also good to think about it upfront. For example, you should consider how the B2B product will be installed or moved around - will you need to disassemble the wall to mount it in the operational environment?
11. Operation environment
Generally speaking, the environment can be indoor, outdoor, or used in water.
Water resistance can be an essential but costly feature of your enclosure. Water resistance is categorized in the IP codes ( https://en.wikipedia.org/wiki/IP_Code), which refer to intrusion protection, dust- and waterproofness of your device. Designing a waterproof casing is always more expensive when achieving specific IP protection in the prototyping and production validation tests - it requires certain techniques and tricks.
Temperature and humidity are the other two important factors that impact your future design. While humidity impacts the lifespan of your product and certain measures should be implemented in enclosure design, temperature impacts electronics, and battery performance. For operating temperatures below 0 deg. C (32 deg. F) the designers should implement certain measures to prevent mechanical parts from freezing - add permanent heating for the battery or even consider replacing certain materials that change their physical properties at low temperatures.
12. Decide how will your product be powered?
Your product can be powered by a limited number of ways: batteries, power socket, solar. It is more exotic to have a fuel-cell-powered device or pneumo-powered products.
Li-ion and Li-Poly are the most common rechargeable batteries used nowadays and there can be complications in enabling the IC design (e.g., designing electronics enabling charging from an AC outlet is more complicated than a DC power source) and further certification. It can be a smart move to use a replaceable alkaline or even a Ni–MH battery in your first iteration product, which will save you much time and development costs.
If you stick to having a rechargeable battery onboard, specify how long would you like your device to work from it. This will provide the hardware engineers with valuable input for mechanical and electronics design since longer battery life requires power budget/components optimization and/or selecting a larger battery size, which dictates larger mechanical dimensions.
Engineers will love you if you specify the time your device consumes power actively and rests idle. Here is an example: you have a DC motor attached to a mechanical gear, which opens a camera lid, so you need to specify how many times per day this feature will work. Or, in the case of an agricultural IoT sensor, which measures soil humidity and triggers crop irrigation, you should specify how often your device should transmit information: e.g. it sends data packages once every 5 minutes. And when you have a GPS or a cellular connection that drives power consumption, you need to define for how long these features have to be enabled.
13. In which countries and regions will your product be sold?
Specifying the countries/target markets where your hardware / IoT product will be used is important for three reasons:
- Power outlets vary from country to country: some countries have 50 Hz frequency in the sockets, others have 60 Hz; in the USA, one has 110 V, while the EU has 220 V power socket standard;
- Telecommunication standards and wireless protocols vary from country to country. It is important to know this upfront in the design.
- Certification and standards also vary from country to country.
14. Connectivity and wireless requirements
Wireless requirements are tied to the use cases of your product. A high transmission rate of your connected hardware product will require a lot of power, and in some cases (e.g., a metallic enclosure), a custom external antenna should be selected or designed.
The leanest way to enable the connectivity is to pair your device with a smartphone using Bluetooth. But there are other wireless protocols available that serve certain needs depending on your use-case: Wi-Fi, Cellular (2G, 3G, 4G, 5G, LTE, GSM, etc.).
Your use-case should also describe the connectivity range and the amounts of data you need to transfer. In specifying these use-cases you may end up having NFC, RFID protocols, or stick to long-range IoT technologies such as LoRaWAN (or simply LoRa), ZigBee, Z-Wave, BT long-range, or others.
15. Sensor requirements for an IoT connected product
With the advances in semiconductor and material science technologies, there exists a whole range of sensors that one can employ to deliver the main functions of a particular IoT product. These include:
- GPS/BEIDOU/GLONASS,
- various accelerometers and gyroscopes,
- pressure sensors,
- compass (magnetometer) and
- magnetic field sensors,
- CO2 (carbon dioxide) and CO sensors,
- temperature and pressure sensors,
- humidity sensors.
Medical (IoMT) devices can have
- HRM (Heart Rate Monitor),
- EKG sensor,
- blood oxygenation sensor.
Modern consumer and wearable products require fingerprint and touch sensors, and there can be many more. So try to specify your sensors and relate them to the product’s features and functions as much as you can.
Remember that each sensor technology has intrinsic limitations in terms of accuracy. So it is highly beneficial to specify whether the data acquired from any type of sensor should be highly accurate, precise, or rather be qualitative.
16. Processing capacity
There are four options to choose from:
- Microcontroller (MCU),
- Chips,
- Microprocessor
- FPGA.
MCUs and chips are the typical choices for an IoT device and in 85% of the cases, one can easily get away with a cheap and reliable MCU in their design. Microcontrollers are used for low computation capacity for the data arriving from various sensors.
Chips can be viewed as miniature versions of the MCUs, incorporating some functionality of both the microcontrollers and auxiliary components like BLE, GPS, cellular, etc. Using chips is highly beneficial in wearables design, but it is sometimes forbidden as chip vendors are not willing to provide documentation and SDKs for these chips if one is not planning to place an order of 1 million chips upfront. However, in recent years some chip providers lowered the entry barrier for low volume chip procurement (such as the very popular Nordic Semiconductors) and provide very good documentation and development kits for their chips.
Microprocessors find a very particular application when one needs high computation capacity, such as real-time processing of large amounts of data from sensors or any sort of video-processing (such as in machine vision or for hardware-enabled AI/ML). You can also think of a microprocessor as a microcomputer that runs a Linux embedded, Android, or Windows operating system.
FPGA (Field-Programmable Gate Array) refers to an integrated circuit designed with custom embedded software for very specific and rare use-cases where low-volume and custom hardware-based computational capacity is required. FPGAs are often found in academic, space or defense fields and most definitely you will not need it in your product design.
17. Display
The display will be one of the most expensive components in your BOM and will drive your unit cost. The display will be consuming most of your power budget and will drain your portable device’s battery - so think about how big your display should be and what colors it should have (e.g., LCD or LED). Describe what information you want to show on your display: is it just text lines, or would you like some graphical information, pictograms, or even video to be shown?
In some cases, it may be a good idea to replace an expensive LED/LCD display with a few simple and cheap LED indicators.
18. Specify your enclosure design and product appearance
Think about how critical appearance and aesthetics are. Defining and describing the appearance of your enclosure upfront is highly beneficial for the design engineer or industrial designer. Remember, the product appearance is very qualitative and it may take several iterations for the industrial designer and design engineer to develop the final look of the product. We recommend referring to various product designs available on the market having user experience in mind.
19. Specify moving mechanical parts
Designing moving mechanical parts can be tricky. If you have any moving parts or features (fans, gears or lids), or if your product is foldable, one needs to specify that and envision the scenarios of these mechanical features as it might bring an R&D component into your product development program.
If you are not sophisticated in mechanical design, it would be beneficial to describe the purpose and logic of having a moving mechanical part.
Conclusions
This blog post discusses the general questions of any product development consultant or NPD company that would ask if you are going to develop an IoT or connected hardware product. The general advice from EnCata would be to be concise in defining the requirements and focus on technical aspects, even if you are a non-technical startup founder. And if you really struggle to answer the questions listed above, perhaps it is time to think about finding a technical co-founder or hire an engineer to manage your development process.
And remember, the product development process is about iterations. In case you missed our most recent blog post on the hardware development lifecycle, check out the article: Hardware product development stages explained: POC – EVT – DVT – PVT.
.svg)
.jpg)
