IoT (Internet of Things) projects are unique in that they straddle the line between software and (physical) product design. Depending on the state of things going into the project -- do you already have a product of some sort? -- the process could either look more like product design or more like a software project.
Ultimately IoT is about bring software to places it normally doesn't go, so at the end of the day IoT is a little more like a software project. The following is the timeline I recommend.
IoT projects start for a variety of reasons. Some times it's as vague as
we need to be in IoT. It could be that the CEO just bought an Alexa. Or it could be an IoT product from a competitor.
Whatever the reason, there's a difference between having an idea and having requirements. Developing requirements forces you to think harder and more critically about the idea you have. The main question to answer is:
- What is the essential value the user derives from this product?
The answer might be as simple as connecting a physical product to their phones and voice assistants, and that's ok! The requirements process is all about clarification. Simplifying requirements creates better products.
One of the most important parts of identifying requirements is decided what are essential features and what are not. Often we start out with ambitious product ideas but later realize that achieving the idea will take too much time or be too costly. When a company reaches that point they often give up entirely.
If you scale back your idea during requirements gathering you can avoid the disappointment later. This doesn't mean giving up on your ambition, it means ranking requirements in terms of importance. I like to rank features like this:
- The absolutely essential features that without wouldn't be a viable product at all. In the software world this is called a minimum viable product.
- Features that differentiate your product from the crowd. Some times these features are part of the MVP, and need to be. On the other hand we often talk ourselves into thinking a feature is essential when it's really not. Playing it on the safe side and putting fewer things into the MVP bucket greatly increases the likelyhood of project success.
- Everything else. These could be extended integrations with other products, or it could be things like analytics that your marketing team would like to have. These things can add major value to your business, but are not core to the user experience. This doesn't mean they are any less important, just that they are unnecessary to prove out our MVP.
Remember that just because you didn't achieve your ambitious vision in the first iteration of a product doesn't mean you can't do so later.
Design a Solution
The next three steps are about developing, prototyping, and testing a solution to the requirements. There is a careful balance between good architecture and fast iteration. Remember, at this point we still don't know if we have a real viable product. So spending the time architecting a perfect solution is premature. That will come, but not until later. At the same time we don't want to build something too quickly that won't reflect what actually gets built later. So again, there's balance to have. In the scale, I tip slightly more towards getting to user testing quicker.
IoT can be a complex product to build in that it spans both hardware and software, both locally and in the cloud. A good diagram goes a long way.
The first diagram I like to build is an architecture diagram for viewing all of the components in the system. This is the physical product, the microcontroller, the connection to the cloud (such as AWS IoT), other services used in the cloud such as databases, and back down to other connected devices such as mobile phones and voice assistants (Alexa). This helps to visualize the components and the connections that they have.
There are free diagram tools online such as Google Drawing and diagrams.net that can be used to create basic architectural diagrams. A more featureful pay tool is Lucidchart. Lucidchart lets you create more advanced diagrams of a variety of types.
However you build them, diagrams are good tools to communicate with the project stakeholders. A good diagram can help non-technical team members understand the scope of the project. Some times when a solution is designed it leads to rethinking the requirements.
Think of all of these steps in the development process as iterative. You can always go back!
In addition to designing the techinical solution, this is also the time to start thinking about the cost associated with running this full cloud solution and how that might affect the product's price. I've had clients who thought it was better to make the IoT part a separate add-on to their core product, and that can make sense for a large number of products where connectedness isn't the core reason people buy it.
Calculating the cost of running the cloud services is pretty straightforward and your cloud provider likely provides tools with calculating how much that part will cost. The hardware part is less straight forward, but there is a lot of information online about sourcing microcontroller manufacturers. If you're working with a consultant they might know people who can provide estimates for this as well.
Build a Prototype
At this point you know more or less how the full system should work, you know that it's financially viable, and what features are most critical. Building a prototype is a crucial step in the process where all of your planning comes together. The prototype serves several purposes, among them:
- The prototype is meant to prove out the solution designed in the previous step. Often it uncovers things you hadn't thought about.
- The prototype is the version of the product we can take to a group of users to test and show that it provides the value we think it does.
Often there are 2 phases to building a prototype. In the first you merely get everything connected and working, a "hello world" of your IoT project, if you will. The second is a slightly more polished version that adds the essential features decided upon in the Identity Requirements phase of the project.
On the hardware side you'll use a development board, like one of the many Arduino boards, not the board that will be manufactured as part of the final project. These boards are designed for rapid prototyping. If you are developing an Alexa project, the Alexa Connect Kit is an amazing development board that allows you to quickly connect a product to the Alexa cloud.
Once you have a prototype that encompasses the product's core functionality it's good to proceed to user testing. There are many resources online to explain user testing (or usability testing) and how to get the most out of the process. Hiring someone with experience to guide you through the process can be a good idea as well.
The gist of the idea is to put users into a room and observe them using your product. You might give them a goal such as
I want you to use voice to set the temperature to 72˚. Watching how they interact with the product will help you determine a few things such as:
- Whether the user understands your product. Do they understand what the goal is for the IoT integration? Does it make intuitive sense? If they struggle getting through the process it might not.
- The level of complexity. With IoT you are dealing with a certain level of complexity no matter what, reducing the complexity in the parts you control is central. Users who find a process too cumbersome might just skip it.
The takeaway from user testing is almost always that you should refine the product further. This is expected and good.
On some rarer occasions user testing can sour your feeling on product. I recommend always going at least 2 or 3 iterations on a product before letting user testing influence a decision to abandon a project. For one, different users will have different reactions to a product. And even when something looks hopeless, little tweaks in usage flow can have massive positive impacts.
Specify and Develop
At this point you have a solid prototype that you feel good about. Through iteration you started with a bare bones prototype and have developed it to the point where, to the user, it looks like the product you plan to sell.
Through the prototype phase you have been refining the software and hardware components but now is the time to finish them off. This means taking those architecture diagrams you built earlier in the development process and build out all of the pieces more fully. Think about things such as what happens when there is connectivity issues, when the device is not able to read from its sensors, etc. The prototype phase focused on the
happy path, now we have to think about the less happy path.
Additionally we want to think about things such as:
- Scaling the solution to support the number of users we hope to have. Using cloud providers such as AWS mostly solves this problem for you.
- Deployment processes to make the solution multi-regional, if multiple regions are part of your demographic.
At the same time the software is being finished off, work on the product specification. The product specification is a document that you give to your manufacturer detailing the requirements of the product. This is a very important document, one that you want to have as detailed as possible. There are many resources online to help with building the product specification. If this is your first time you might consider hiring outside help to guide you through the process. Having a detailed product specification ensures that the manufacturer builds exactly what you want.
Once the product specification is ready, send it along with the prototype to your manufacturer. This is the time to finalize your marketing plan, talk to retailers, and those sorts of things.
On the engineering side you should continue to test your infrastructure to ensure it's production ready. If you haven't already done so now's the time to hire a security company to perform pen testing. Prepare like you assume your project will be a major success.
Once your project has launched to consumers and the dust as settled you can start to revisit some of the requirements that were identified earlier in the process but didn't make it to the final product. Are those requirements still desired? Some times the development process can change stakeholders minds on this. Some times the success of the project changes things as well.
For the next phase of the project start the development process from the first step, only now with the knowledge that you've gained from the first phase. One mistake physical product companies make when entering IoT is assuming that you get one try at it. The Alexa Skills Store is littered with skills from companies who gave up after their first try wasn't as successful as they hoped. With software it's about iteration.
If your company needs experienced consultants for IoT projects, please contact me and let's chat.