The market for connected products has exploded over the past few years, so it’s natural there’s lots of interest from designers, engineers, and product managers in how to successfully create and deliver IoT-enabled services.

On May 21, just a few short weeks away, Fuzz will host a webinar on this exact topic. We’ve been lucky enough to partner with a number of clients to ship products for a wide variety of settings, including the connected home, gym, and office. During the webinar, we’ll be offering a peek inside our process, including strategies for overcoming key challenges, and the best practices we’ve built up along the way. We welcome anyone to join!

An integral part of Fuzz’s IoT practice is our CTO JP Pereyra, a veteran engineer who has a long track record of working on successful connected products. I caught up with JP via video chat to ask him why he loves IoT projects, how he got started with them, and what he’s learned by working closely with hardware engineers.

Below is our interview, edited for clarity. If you want to dig in more on these topics, and see members of the Fuzz team live in action, please join us at 2–3pm ET on May 21 for our webinar, “Mastering Connected Experiences: How Teams Can Deliver Best-in-Class IoT Products.”

DK: I know from our past conversations that IoT-enabled products have long been a passion of yours. What got you started? And what types of connected experiences have you worked on?

JPP: My interest in hardware goes back to high school, when I taught myself enough about analog electronics to build my own hi-fi audio equipment. At that time in Argentina, where I grew up, some audio parts were very hard to find, so I had to design around what I had. The best thing I made was a 200W switching power supply, custom coils and all! Of course, due to an issue with a diode bridge, it wouldn’t stay on for more than a few seconds under load.

In my professional career, I’ve worked on a number of IoT projects, but there are two that really shaped me as an engineer: first, designing and implementing a digital clearing house for mobile and fixed electric loads in California. This was a project with the California Energy Commission to connect several disjointed information systems to create a more efficient, resilient network, given the rising popularity of electric cars. I got to work with the ISO 15118 standard, OpenADR, and other private and public data sources to create a great experience for drivers and bring more predictability to the network.

The other experience that taught me a lot, was spending two years immersed in the world of industrial automation, this really opened my eyes to new (and valuable old) ways of thinking.

Anyways, I still keep a box full of controllers, sensors, batteries, etc. right next to my workstation at home…It’s like my playground.

Knowing you, I can’t say I’m shocked.

Haha! Well, that’s just the tip of the iceberg. When working with clients, I always try to bring an IoT perspective. In software development and design, we’ve become accustomed to thinking in terms of screens and web, but not so much in terms of custom, purpose-specific hardware devices.

Working with hardware in this way often leads to a new perspective, even if it’s just a prototype. For example, for a leading financial institution, I worked with a team to build a connected piggy bank — basically an ambient device that activates based on the activity in the account it’s linked to. This opened a whole new world of possibility in teaching kids financial responsibility. Parents would be able transfer money to a special account once their kid completed a chore, for example, and the piggy bank would light up: instant gratification!

This was as simple as connecting a Particle electron we had lying around in the lab, 3D-printing a fun-looking case, and arranging some LEDs. This led to several iterations of more refined prototypes, improved through multiple rounds of user testing.

I know privacy is a huge concern when it comes to connected products. How do you ensure personal data is truly kept private while unlocking the power of that data to drive personalized experiences?

This is a very interesting problem, and although we have several pieces of the puzzle figured out, it’s still an evolving field in and of itself. The components of experience design and technology design need to work closely together. It’s very important that users have a good, intuitive understanding of what data they share by using a product, and that they’re comfortable with how that data will be used. The same is true for us as product designers and engineers; what data could we obtain? For what purpose? Most importantly: what data do we really want to be responsible for?

As opposed to more traditional client-server architectures, in the world of physical things there are many places where computing, data transformation, and storage can be happening: in the sensor itself (quantization, for example), in the controller, the gateway, a mobile device, backend proprietary or 3rd party services, etc. Also, there are many ways in which that data can be transported: internal bus, through an unsecured wifi connection, Bluetooth, RFID, cellular, Zigbee, and so on.

In a nutshell, an engineer who’s used to web architectures will need to reacquaint themselves with the security considerations at every level of the OSI model and pay special attention to the threat modeling process.

There have been some very well-known breaches in this area, right?

Definitely, from botnets to privacy intrusion and everything in between. This is an evolving issue, and I believe that self regulation is a necessary thing. As product designers and engineers we’re responsible for keeping security not only top of mind, but also as a central topic in the development process.

When we step out of the realm of mainstream software and into the world of IoT, everything is more diverse and nuanced; a solution that might work for the web will come apart easily in this ecosystem.

One story that I find very interesting: when the Microsoft team set out to create the Xbox One system (let’s remember that the Xbox 360 was successfully hacked several times), one of the first questions they needed to answer was, “Why are we not using the Windows’ security stack?” Clearly a lot of years of very smart engineering had gone into that product. The answer was simple: the threat model is totally different. In the case of an Xbox, it’s the owner who’s the attacker; they want to play games without paying for them. I imagine that saying no to the Windows team, at Microsoft, and instead investing in a new and bespoke solution might not have been an easy thing.

But I digress. I want to stress that while in more mainstream software engineering disciplines the security construct is clearer and better defined, when working with IoT devices there’s a lot more work to do to arrive at a secure solution. Something as simple as default passwords have proven to be a huge issue in this industry.

Something I’m very interested in is high performance computing at the edge, I can now run a machine learning model in something as basic as a Raspberry PI with a USB TPU unit attached to it. Industrial automation is also looking at this; Rockwell Automation has the Logix AI module that attaches directly to the backplane, right next to the controller enabling advanced predictions, without sending the raw data into the OT network. So I can process raw, sensitive data, extract valuable insights, and act on it right then and there, minimizing the attack surface.

What have you learned by working with engineers who have a much stronger focus on hardware in their day-to-day roles?

I learned a ton! Working with hardware is a different mindset, and collaborating with engineers who are focused on physical products pushed me in the best possible way.

First of all, there’s a lot of… well, physics. Things that need to operate at certain times, or frequencies, for very specific purposes. In motion applications specifically, there are the limitations imposed by mass, inertia, wear and tear; a motor will have acceleration and deceleration curves that need to match its rating and load specs. These requirements permeate the whole ecosystem and make you more aware, and make you think in different ways.

The first thing I really grasped is how much smaller the margin for error is when it comes to hardware — and how important it is to plan ahead. Software engineers are used to rolling back deployments if things fail. From the safety of our software bubble, we have the flexibility to try new things without worrying all that much about catastrophic failure. Agile is really not possible in these environments, given constraints such as lead times for manufacturing and supply chains, so the ability to think through and simulate the outcomes of complex decisions becomes critical. It took some time for me to think in that way, and I’m indebted to my hardware and control engineer buddies for whatever growth I’ve achieved here.

Lastly, I’d say it made me develop a taste for systems that last, evolve gracefully, and are resilient. Basically, I have a deep appreciation for frameworks and tools that can stand the test of time.

What are some principles that are key to engineering and shipping great connected experiences?

There’s a book I like on this subject: Bringing a Hardware Product to Market, by Elaine Chen. The author describes each phase of the product development lifecycle, it’s short and sweet, and I feel it’s written especially for software developers.

Keys for me are:

• Keep the hardware at the center of the process: It’s easy to abstract away from it and lose touch with the real-world implications.
• Prototype early and often: Get your cardboard and duct tape prototypes into users hands early, get out of the office, repeat tests in various real-world scenarios.
• Have your stakeholders touch what you make, and keep them involved in the process. They may be used to screen-based development, but it’s likely IoT will be new to them.
• Allocate plenty of time for threat modeling, pen testing to avoid simple mistakes.
• Keep critical components as simple as possible.
• Give your design plenty of room to evolve: you don’t want your system to be running at high utilization on day one, then discover that you’re unable to launch an important new feature. Encourage careful, critical thinking, and more importantly allow plenty of time for this.

From my personal experience I’ve learned that, when it comes to IoT, because we have so many new technologies at our disposal, connected hardware projects are really fun.

But there’s one thing that’s critical as more and more IoT technologies become available: we can’t lose focus on the core experience of what we’re building.

This is true enough for software. Any seasoned engineer who’s been around the block has made a bloated app or two, right? And we all learn the hard way that this is expensive for stakeholders, and distracting for users. But when it comes to connected experiences, the problem of feature bloat is much more costly. You’ve got to think really carefully about what you’re going to build into the hardware. That’s why you don’t see Nest or Philips Hue doing a million things. Successful IoT products are created around very focused user experiences. They do a few core things really, really well.

That sounds right. The connected products getting attention aren’t exactly Swiss Army knives. Sonos isn’t trying to build home security into its speaker system, for example.

Exactly. Now, on the flip side, and this might sound contradictory — but at the same time as focusing the core experience, you’ve got to prepare your IoT platform for the future, when you will want to make more features available to your users. Look at Tesla. They put a ton of computing power into the car. And over time, they have the ability to add things on top of that solid foundation, as user needs and expectations shift.

At the end of the day, engineering great connected experiences is about bringing the best of the iterating mindset that’s the hallmark of the software world, and pairing that with the advanced planning, rigorous simulation, and deep expertise that hardware engineers bring to the fold.