TL;DR

When creating an IoT device on a small budget, it is important to consider the following:

1. Clearly define what you want to build and document it in a Product Requirements Document (PRD)
2. Ensure the product solves an actual problem and conduct basic market research
3. Stick to a Minimum Viable Product (MVP) and avoid feature creep
4. Have a total budget in mind and plan for non-recurring engineering (NRE) costs
5. Utilize off-the-shelf components and open source hardware

What do you actually want to build?

The question is deceptively simple. Many of us have a tendency to dive head-first into work and get blindsided by issues we didn’t even know existed.

Engineers may lack awareness of business challenges, while business-oriented people may have a hard time understanding technical challenges.

Creating the product’s most important document is paramount: the PRD (Product Requirement Document). This document defines what your product looks like and which features it has. This document must be easy to read and understand.

As an example for a requirement written in a PRD:

”The device should run on battery for at least 7 days” is understandable by the whole team, while “The battery capacity should be at least 1,200mAh” makes the requirement hard to understand for non-engineers.

Normally, the PRD will be a living document in the form of a spreadsheet.

The simple one below is a starting point for designing a smartwatch:

Similar to SMART goals, PRD requirements must be Specific, Measurable, Attainable, Realistic, and of course Time-based.

Check out Mastering the Requirements Process: Getting Requirements Right, which tackles this topic in detail.

If you work with other people, it’s essential that the latest PRD is readily available to everyone on the team. Nothing breaks trust like keeping secrets (yes, we’ve seen managers hiding the PRD from their own employees).

Ideally, once this document is made, it is set in stone. In reality, this rarely happens.

Changes in the PRD along the way result in unpredictable delays on the development process and increases in cost.

Better to sit down, take some time, and define a robust, encompassing PRD. This document should go through few revisions rather than being edited every day.

A strong PRD is your first tool in keeping the project on track. Time spent on it will pay you dividends.

Look around – does this product already exist?

Legal issues could be hiding in plain sight, if you don’t play your cards well. Make sure the product name can easily be trademarked, and nobody can accuse you of plagiarizing their existing device.

If a similar product does exist, look for inspiration: what do people dig about it? What does it miss?

An opportunity might be right around the corner.

Does this product solve an actual problem?

Much has been written about Silicon Valley’s talent in designing stuff nobody needs. Juicero and Washboard come to mind, and those are only a few examples.

While one could argue that “People don’t know what they want until you show it to them,” we believe that line is best reserved for geniuses like Steve Jobs. For us mortals, instead, some basic market research is a must.

Look around yourself for the pains people go through. Can you remove that pain from their life?

Shipping something is better than nothing – Stick to the MVP

An MVP (Minimum Viable Product) for a hardware device is a version of the product that has the minimum set of features necessary to satisfy early customers and provide feedback for future development.

(from Scott M. Graffius, Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions)

The MVP is simply the list of requirements that are “must-haves” or highest priority in your PRD.

An example of an MVP for a smart home device could be a device that can control the lighting in a room using a mobile app. The MVP would include:

• A physical device (e.g. a small box) that can be installed in a room

• The ability to connect to a home’s WiFi network

• A mobile app that allows the user to turn the lights on and off and adjust the brightness

• The ability to integrate with other smart home devices such as a voice assistant

It’s important to note that MVPs are designed to be simple and minimal, so there may be additional features that are not included in the MVP but could be added later, in a new product version.

When you’re new at product design, it’s easy to catch the feature creep fever: adding features your user doesn’t need.

Instead, hold on to your horses and stick to the MVP you already identified. One of our partners recently made the choice of not having wireless connectivity in their first product. It felt bold to many on the team, but we knew it was the right choice. Adding connectivity could have meant not shipping at all (which is what usually happens). This way, instead, their users get the product they need, and in turn will provide feedback to inform the next product version.

“Great products do less, but better.” – Fabricio Teixeira, Designer at Work & Co, Founder of UX Collective

Total budget

Even a simple IoT device can easily cost you $50,000 in NRE (non-recurring engineering) costs. Add to that the cost of the hardware itself, and you better plan for a six-figure budget.

All of this budget pressure can be lightened by producing smaller batches at first and limiting features to the MVP.

Working with small clients, we normally drive toward a first prototype that can be completed on a small budget. That proto proves that the initial idea was solid and helps raise more investment.

Because we care about delivery as much as our clients do, we often push back when asked to add all the bells and whistles that will slow down progress.

For example, Bluetooth connectivity will cost you ~ $8,000 in fees even if you sell one single device.

Skills needed – what does it take to go ahead and build?

If you got to this point, chances are you have some of the skills required to build and ship a device. Maybe you’re great at writing code, or you know how to analyze the business side of things.

Either way, there’ll be areas where you need help. The following is a brief, incomplete Skills List

• Hardware design and prototyping: Knowledge of microcontrollers, sensors, and communication protocols such as Wi-Fi or Bluetooth.

• Software development: Proficiency in programming languages such as C, C++, Python, or JavaScript for writing firmware and software for the device and connecting it to the internet.

• Cloud computing: Knowledge of cloud platforms such as AWS, Azure, or Google Cloud Platform for storing and analyzing data collected by the device.

• Project management: Ability to manage the development process and coordinate the work of a team.

• Business: Understanding of the target market and the value that the IoT product can provide to customers.

Basic first proto

To reconnect with the idea of MVP: your first proto will look messy and embarrassing. And that’s OK.

The goal here is to prove all the parts of your device can play well together, even if they’re not yet in a form that can be sold to a paying customer.

Don’t waste your time polishing up the details – first, build a simple proto that works.