Prototyping IoT Products and Services

DOTMAGAZINE: What’s involved in the prototyping of an IoT product or service?

SEBASTIAN FLOSS: Prototyping is a way of working, more than a well-defined activity. Ask random people what a prototype is and you get vague descriptions like “something new”, “unfinished”, or “fragile”. That’s because a prototype can be a lot of different things – even a drawing or a papier maché model can serve as a prototype. And as diverse as the prototypes themselves is the process, even when limited to IoT products and services.

Even though IoT prototyping puts some limits on who and what we can work with, it ranges from being heavy on the design side when the final product is something that people are supposed to interact with, and more engineering when the end result will be something living inside a control cabinet.

Prototyping is a process of innovating, and in the IoT context that’s mostly about electronics, user interfaces, and software. This requires a team of experts from different fields, who need to have a very broad general knowledge and good communication skills. They need to have a lot of aspects and constraints in mind all the time, like required certifications or design considerations to make something mass-producible. 

So, in my opinion good prototyping is mostly about the right combination of creative people. Designers, programmers, engineers, even mathematicians, because the IoT is a lot about cryptography. The actual tools and materials used to build a prototype play a smaller role, with 3D printers available off the shelf, and small batch production of circuit boards being state of the art.

DOT: What stages are there in the IoT prototyping process? 

FLOSS: Depending on who you ask, you will get a different answer to that question, but since you’re asking me, I can say what has proven the best for our work. I recently heard someone sum up the process like this: “Explore the problems to build the right thing, then build the thing right.” And that’s exactly how we do it: we iterate through three stages: build, test, learn, and then repeat it. 

In the build stage we “tinker” in a very positive sense of the word until we solve a certain problem. We deliberately create small, intermediate results, just enough so they can be validated in the test-stage. Validation can be either against the usability by real people or sometimes just the laws of physics, if the question we want to answer is “can this be built?”.

Let me add: If the prototype needs to be tested against actual users, the crucial part is that it has to happen “in the wild”. I’m saying this, because there is a tendency to assemble focus groups at this point and that doesn’t really nail it. You can never ask people explicitly if they like something when they’re not actually using it. It’s a bit like Henry Ford said: “If I asked people what they want they would have said: faster horses.”

In the end, we take the learnings from the tests and improve the prototype, or sometimes start over from scratch. And here’s another culprit: The learnings from a test aren’t always obvious, and yet too many people neglect this important stage.

DOT: Do the stages differ greatly depending on the product or service? 

FLOSS: The stages don’t so much. But they’re just an abstract guideline on a larger scale. Every project is different and it would be wishful thinking to assume it can be made into an automatable process.

Currently we see two major kinds of projects, though: 

The first one comes from the manufacturers in the B2C market, who are always looking for unoccupied market niches or want to increase their existing market share with new products. The “smartification” of existing products is big at the moment. Prototyping is employed to create “minimum viable products”, instead of a full-fledged development process, in order to find out what features people would spend money on.

The other type of project comes from industrial clients. Here, the majority are looking for solutions to boost productivity. “Predictive maintenance” and “digital twin” are the hyped technologies. Prototyping is used to validate feasibility and potential to save money, though more and more companies are starting to use it for improving usability, too, which I think is good.

Apart from those two, there’s still everything in between – and I actually like the projects the most where people want to try something new, because they’re more challenging most of the time.

DOT: How much might a product or service evolve and change during the prototyping? 

FLOSS: The process itself isn’t designed to have an end, so it’s up to you to stop the evolution anytime.

Prototyping is just about getting answers fast and acting upon them.  So, when it’s done right, you have something that works at all times in the process and the feature set of the prototype depends on how often you want to iterate.

Think about well-known products like the iPhone. That has changed a lot and evolved in the past ten years. But is it finished? My point is: After something goes into production, then that’s the testing stage and the learnings from the market are the entry point for the next iteration prototype. 

DOT: How do you evaluate the potential success of an IoT prototype?

FLOSS: That’s actually difficult to answer. As I said, prototyping is about getting closure, and that ironically means: even failing can mean success sometimes. You want to see if something is possible? You prototype and find out: no, not possible on your terms. But the prototyping was successful.

For me personally, it’s a success when things add up at some point and we have created something that adds value, that people actually want to use, but I guess that’s more an answer to why I am in the business.

But from a client’s perspective, it really depends on what they expect in the first place. So unless we get a detailed spec sheet we usually sit together a lot with our clients and discuss their requirements until we have something that we can start prototyping with, and that everybody can agree on, to determine if we were successful. But we keep adjusting as we go, because in the testing and learning phase the definition of success can change a lot.

DOT: How can a company get started with prototyping an IoT product or service?

FLOSS: Doing prototyping inside of a company is difficult, because it means needing to overcome two challenges.

The first one is: You need real commitment to the process. In big companies the process is often reduced to “build something quick and cheaply” and instead of doing the testing and learning with real users, things will be decided somewhere along the chain of command. That doesn’t work.

The other challenge is the availability of the right people. Most creative people love the variety in their work which conflicts with the commitment to one company making one certain type of product or service. Sure, companies like Google or Amazon and the like have those people on board, but smaller or less “cool“ companies don’t. That’s where companies like us that offer prototyping as a service come into play. 

But nevertheless, more companies should get started with prototyping. At the moment almost any IoT related technology is at the infamous “peak of inflated expectations” in the Gartner hype cycle, and all the companies want IoT in their products, for their production processes, or both.

Many of them are struggling to find business cases or applications, so they just equip what they have got with Internet access. That’s part of the security problem we have in IoT, but it also isn’t innovation because it doesn’t add value.

Think of GoogleX and their moon shot projects. More companies need to do this on a small scale. I mean, take tiny “leaps of faith” with inexpensive prototyping projects. Then we would see a lot more innovation.

Sebastian Floss is the founder of ImagineOn, a development studio for digital and electronic products and a consultancy for development and manufacturing processes. For nearly twenty years now his mission has been to help create more usable, reliable, and secure software for almost any kind of device. His personal expertise covers development in C/C++ as well as electronics prototyping and design for manufacturability.