Better smart homes with connected cloud services with Kent Dickson of Yonomi

Transcript

Ledge: Okay. Would you say your full name please?

Kent: Kent Dickson.

Ledge: Kent, great to have you. Thanks for joining us today.

Kent: Hey, Ledge. It’s great to be here. Thanks for inviting me.

Ledge: Fantastic. Good to have you.

Would you mind giving maybe a two or three minute intro of yourself and your work, so the audience can get to know you a little bit?

Kent: Yeah. Sure. Again, my name is Kent. I am co-founder and CEO of a company called Yonomi. We are co-headquartered on Boulder, CO and Austin, TX – two pretty nice places.

I myself have been in the software business for 25 or so years at this point. This is the fourth startup I’ve been involved in. First time founder, however. I have had some big successes in some of these startups and a few failures along the way.

This one has been going on for about five-and-a-half years at this point. We started it in late 2013.

We wanted to tackle the arena of who the smart home was going to be for consumers – for regular old consumers. Not for geeks like we are, but for folks like me mom and my uncle and folks like that who maybe aren’t technology people but nevertheless are inevitably living in spaces with connected deices. How is that going to make their life better?

We were concerned that it was just going to make everybody’s life more complicated. So we decided to inject ourselves into the fray to see if we could have an impact on the outcome.

Ledge: How’s that turned out? Five years along, you predated the Alexas and Google Assistants of the world, so you’ve seen a few things. There’s been exponential shift in that space since then.

What does the world look like between 2013 and now?

Kent: It’s quite remarkable in many ways. The world has changed. These voice assistants didn’t exist in a mass market way when we got started with the company. We weren’t even forecasting it to come as early as it did. Nevertheless, we had this open, agnostic vision for how connected devices and services that affect people in physical spaces really needed to work together, and to built this very flexible platform.

So, when interesting things like voice assistants came around we were able to embrace them and bring them into that environment really quickly. Interestingly, that’s the thing that has created the growth in this space.

We knew we were early in the space and it was still an early adopter market, but we were playing the long game for when it would go mainstream. But the thing that caused it to go mainstream was the voice assistants.

Ledge: Sure. There’s always some trigger, like the iPhone that drops out of nowhere, where you go, that was a pivotal change moment.

Kent: That’s right. Alexa was that for the home.

Ledge: Absolutely. Runner-up points for Siri for giving people the idea, but not the best implementation.

I’m curious, my limited awareness of smart home technology going back, I remember the early adopters in the space almost having their own server closet where all these things needed to interface and you had it all wired up behind the walls in your house.

Now, IoT, fast forward and you’re connecting your toaster and your toilet seat and god knows what else to the ‘smart ecosystem’ – because some of the stuff isn’t so smart, and you have issues where you’re working your doorbell and all kinds of stuff.

How do you guys make sense of this, and how do you tie things together that it’s just absolutely ubiquitous now?

Kent: Well, we take a bunch of lessons from things that have gone before, which is the history of software. Standing on the shoulders of giants, or old wine in new bottles, whatever you want to call it.

Middleware is a thing that’s been around for a while. Most of my career I was working on some form of middleware or another. Which really is how to take these heterogeneous things – which are mostly proprietary or maybe a variety of different standards, schemas or what have you – and marry them together somehow in the middle, ideally in real time, into something that suddenly looks homogenous.

So, what we did in the enterprise middleware space back in the day when I was at BAE Systems working on web logic we’re now doing for connected devices in the home today.

Ledge: Right. Do you have a taxonomy or a data model that sort of unifies all of these disparate APIs?

I’m reminded, when I say that, of like a Zapier kind of paradigm.

Kent: Yeah. I think Zapier is an appropriate analogy to what we do. They are doing that for the enterprise, I think, and for various things that are out there. You can plug them in and have them, eventually to a consumer if you will, appear to be of a common taxonomy. That’s exactly what we’re doing.

It’s interesting device types that are there. There are probably a dozen different types of light bulbs that we integrate with today, and each one has defined their own sort of schema and their own proprietary API, but nevertheless they all have a common thread – on is on, off if off, dim is dim. If they support color, well then you can apply those types of traits as well.

So, bit by bit we’re building out all of those device types. It’s fun because there’s a lot of obvious ones, like light bulbs and door locks and thermostats, but then you start to encounter really innovative, entrepreneurial types of people who are rethinking common devices.

Dog feeders and things like that. Is it a switch? Well, maybe if you look at it, when you squint your eyes there’s sort of an on or off to it or a feed or no feed, but really it’s a unique sort of device type.

So, more and more we’re adding new devices that in many cases we wouldn’t have predicted that would be in that taxonomy. We built this from the get-go knowing that there were a lot of things we didn’t know and that were unknowable, and that new, interesting things would emerge and that we needed to have a framework that could embrace those.

Ledge: How do you even begin to encapsulate a new type of device? It must be a pretty deep taxonomy. I’m thinking about the Latin names for all the genuses and species and stuff. It would be that level of complexity there.

Kent: Yeah. It can get to that level, for sure. You start with… At the end of the day, these devices, at least as far as we’re concerned… We’re really interested in the integration and the automation of them. We’re not trying to be a platform for video content or gaming or anything else. But for the physical devices that otherwise manage and control a household, they’re actuators and sensors.

Basically, at the end of the day, every device is one or both of those things. Then you just expand from there. They’re just increasingly elaborate actuators or sensors.

Ledge: So like plants and animals.

Kent: Yeah. Exactly.

Ledge: Excellent. Software challenges obviously abound there. How have you gone about solving the software staffing and build pipelines and the necessary items there to move fast enough, because this ecosystem is changing like crazy.

I’m thinking like CES and there’s a lot of stuff going on in this space. You’ve got to ingest it all real quick. You’ve got to figure out which API is exposed or not, and which ought to be consumed or not. Which things are potentially a security disaster that you should never try to integrate with.

What is the strategic roadmap on that?

Kent: You guessed it, stuff’s all over the map. Some things should be integratable but they’re not because the authors of that device really didn’t think through it correctly, maybe didn’t build APIs, didn’t build a cloud service for anything. Therefore it’s not really integratable, or if it is you have to do it in some way that maybe isn’t going to be very reliable or secure.

As a result, some of the things are just immediately off the list because they’re either not viable or they’re just simply unwise to add to the ecosystem.

Ledge: Or they’re broadcasting their admin password over your Wi-Fi.

Kent: Exactly. Yeah. Security obviously and privacy are big concerns for us. We think consumers care about these things quite a bit, and they’re going to be the things that make the IoT fail if we, the industry, get those wrong.

At the end of the day, as an integrator we can’t make the end devices by ourselves more secure, but our job is sort of like the Hippocratic Oath, “first, do no harm”. We can’t make the situation worse. In some cases we might be able to bolster it a bit, but the devices are what they are.

So,, in some cases, yeah, we just don’t want to be associated with devices that have a poor user experience or are otherwise unsecure or not really caring enough about the user experience.

I guess what I’d say is that we’re constantly evaluating the landscape of potential things that we can integrate with. One place that you quickly get to is acceptance that you’ll never do it all, and that’s okay. Our mantra has been, and continues to be, that Yonomi will work with any connected device that is likely to come into a mass market consumer’s home. So a few qualifiers in that sentence; likely and mass market.

Ledge: Does it need to meet a certain threshold before you even think about it? I mean, mass market would indicate, I don’t know what, X hundred thousand units, or something?

Kent: Yes. Geographical is the other qualifier about what mass market means. Is it mass market in the United States? What if it’s mass market in Japan? What if it’s mass market in, I don’t know, Peru?

That’s the interesting thing about IoT and the smart home, is the addressable market for it is every home on the planet that has electricity. It’s not necessarily we’re qualified by numbers, but just sort of on momentum.

In some cases, we have integrated with products that aren’t even on the market yet. You could say, well, they don’t have an audience yet. Well, no, but yet we know the firm or the company – sometimes a startup, sometimes a big company – and we believe that this thing is going to hit. We believe in it and we want to be a part of that from the get-go. We want to help enable some success there, and obviously we grow when these products grow as well.

Sometimes it’s a bet, it’s a hunch that this is going to be a mass market thing and it’s worth doing. In other cases, it’s already clearly shown itself to be a mass market thing. Philips Hue was honestly the first thing we did. That was already obviously a mass market thing, or on its way to being there.

When they’re an obvious success we’re scrambling to get there, but in some cases those APIs don’t exist or they’re not usable in a way that’s going to have a good user experience for us. So we have to wait and sometimes work with those companies.

This is part of the startup journey. The things that you learn along the way, we always have this vision about integrating and automating the things that are in the house but what we learned, from a bunch of these device manufacturers who were making things, is that they actually are not all good at creating APIs or hosting reliable cloud services. As a result, we spun up a product for some of these guys.

When we’re talking with them we say, okay, well, we’re going to need this, this and this from you in order to build this connector. And they say, oh, yeah, we’re not there yet. It’ll be another year. Or, we’re not really sure we’re going to do that. Or, we’re hiring to get this done.

In those cases we just say, well, look, we’ve got this very straightforward turnkey thing that you can deploy essentially tomorrow and get on track with this.

It’s not a requirement, but it is something we found there was a surprisingly large market for.

Ledge: So that’s like an SDK that you can develop your APIs and infrastructure around so that it can be publicly accessible?

Kent: Yeah. It’s a deployable framework. It’s a server. It’s a serverless solution that just deploys on top of AWS, and it’s got all the commissioning and provisioning and remote API access and storage and things like that that you need. All the building blocks of course are therein AWS and we assumed at the time, oh, all these companies probably employ good software engineers who can go build this stuff out and help build these bespoke things.

Then we kind of figured out, well, why does it really need to build a bespoke thing? Furthermore, they actually don’t have the talent to do this in many cases, and shouldn’t be doing that. They’re really good at hardware design, maybe they’re great at firmware, maybe they’re even excellent at networking, but they don’t have to be experts at cloud computing.

We’ve just got a thing, they can push a button, deploy it to AWS. We’ll actually manage it 24/7 because we’re in the business of doing that anyway, and it’s cheaper, faster and better for everybody, we’ve found.

That was a surprise discovery along the way. That wasn’t one of the products we had on the roadmap but suddenly it came into view and, oh my gosh, we just have to do this because otherwise the rest of our business is going to be held back. Obviously, there’s a revenue opportunity here too that we’d otherwise be missing.

Ledge: Yeah. You kind of organically discovered the need for vertical expansion to enable your core business, and you got paid for it. That’s a pretty good find.

What was the whiteboard session like to get there? That had to be a pivotal moment there. That’s a little bit of a pivot, I guess, or an additional pivot at least.

Kent: Yeah. Well, it was certainly an expansion of what we were doing. I think we kept on the track that we were on at the beginning.

This is what I was going to say initially. One interesting thing. Even though the world has changed in five-and-a-half years, and what IoT looks like and who the players are and how people are consuming it, the vision for having this open, agnostic way to make everything work together has still held really true.

That original mission statement has remained largely unchanged. But it has expanded in that, we’re also offering this additional platform that isn’t, by itself, about integration and automation of third party devices, it’s actually how to get a first-party device to be a good citizen of that third-party ecosystem.

Ledge: I’m curious if you have had thoughts and experiences around that. I mean, you basically set a standard and a taxonomy which on the one hand is a strategic, intellectual property asset, but on the other hand we all know that standards get better when everyone can be at the table and contribute and can also use them.

How have you threaded that? It’s cumbersome to become the standards body unless you… Once you let the world come sit at the table you open yourself to competitive pressures, but it’s also a really good way to expand.

What’s that thinking been like?

Kent: Well, yeah. We love standards, and in my career I’ve participated in building and running a number of standards bodies.

We sort of made the guess a long time ago that in our space, in the consumer IoT space, that a single standard taxonomy that we could get the world to agree on was probably never going to happen. There’s some hope that there maybe will be just a few standards – less than 10 hopefully – but I think the reality is that there’s nothing requiring the community to congregate around those standards anymore.

Folks are just going headlong towards creating product and getting it out there and validating that; consumers actually do want the robot vacuum cleaner, or whatever it is, and are unconcerned about the interoperability.

That’s the whole reason we exist, and so we make that interoperability happen. We do that real time translation across those things.

So, yes, we have created the taxonomy, and it looks very similar to some of the other attempts at standards out there – OCF and things like that, or Dotdot. Again, there’s a dozen of these things. They all start to look pretty similar. Our job as a translator in some ways gets easier when they become more similar.

Maybe I’m just a pessimist, but I just don’t believe that there will ever be a one. In previous lives, not in this company, I’ve wasted very good years and brain cells by sitting through standards committee meetings and arguing about is this a ‘shall’ or a ‘should’, type of a thing, and the politics that go into that.

Ledge: Well, you know, the good thing about standards is my standard is always better than your standard.

Kent: Yeah. Exactly. And you don’t like it you just go create a new one.

Ledge: Absolutely.

Kent: At any rate, we’ve kind of created our own. What’s interesting, how we’ve seen the APIs at third-party is, while they’re still technically proprietary they are becoming more similar. There’s enough of us out there talking about it in a similar way, bout what archetypes are and traits and things like that, that they’re awfully similar. So when you get to doing translation, in some ways it’s getting easier.

Ledge: How have you thought about the translation layer there and helping other people to be good citizens?

It reminds me of a conversation I’ve had relative to healthcare technology, whereby most of the bodies who were thinking about and trying to democratize data in healthcare are thinking of machine-to-machine architecture being the best way… If you’re going to build a thing, make your data machine-readable.

Is that the guidance that adheres to this space as well?

Kent: Without a doubt. Yes.

Ledge: How have you guys actually worked the software layer here? You talk about AWS, obviously that’s an important stack and pretty soon all of us are just going to say we all… AWS is like McDonald’s. It’s just on every corner and we all depend on it one way or another.

I’m curious about your software stack and the other technologies and tools that you use in there to enable the rapid development.

Kent: Well, our integration and automation engine that does all the third-party automation is probably what you would imagine a very high level. It’s very microservice-ey. There is a connector framework in there, and that’s where the translations happen – kind of coming and going.

Then it gets into a normalized layer and data store. Then there’s rules engines and message buses. All these things as microservices so they can each independently scale, loosely coupled and all those things that you like to do in software.

Then we’ve put a whole lot of monitoring and Ops and convenience layers. Then obviously APIs and SDKs around that so people can consume them in interesting ways.

That’s all built on AWS, in some cases using things like Heroku for certain services and using ANQP types of message buses and whatnot.

What was interesting, when we went about building out the products for first-party device makers I mentioned earlier, we call that thin cloud, one of the things that we knew was going to be really important – it’s important across consumer IoT and I think people maybe don’t quite understand how acute this issue is – but cost is a very big deal.

If you’re a device manufacturer and you make light bulb, you sell that light bulb for $10 or $20, that light bulb, which is an LED of course, is probably going to last for 10 years, maybe 20.

The implication of buying a smart light bulb is, it’s going to stay on the network and stay connected to your other things. That implies that there’s some level of cloud computing going on there. Yet, that consumer who bought that $10 light bulb isn’t paying a subscription for that thing. No way.

How do you, as a manufacturer, think about or contemplate 10 years worth of cloud services for that light bulb that you have to capture somehow in that original $10?

That’s a big deal. As we built out the stack for hosting those things in thin cloud, we did everything with the most modern, highly efficient architecture. Serverless is a big buzzword these days, but is very much a great use case for serverless technology. Which is, never waste resources at all. Don’t be spending on resources if you don’t have to at any given time.

So shut down…

Ledge: Idle compute units.

Kent: Yeah. Exactly. No idle compute ever.

So we built it in a really interesting way that allows that light bulb manufacturer to be able to collapse 10 years worth of cloud costs into a really palatable size that can go in the bottom of the product.

Ledge: Serverless Lambda didn’t exist in 2013, so this was later.

Kent: That’s right. This was later. Yeah. We really started working on that product. That was the epiphany products that I mentioned where we expanded our roadmap. I think we started on that in 2016.

Ledge: So is it Python? Node? What are you actually writing in?

Kent: We do almost everything in Node.js. That’s been good for us.

Ledge: Which has also come a very long way since 2013. I mean, that was no way mature until even that ’15,’16 range there.

Kent: Indeed. Indeed it has, but we feel good about that choice and we’ve been with that from the beginning.

Ledge: Also, a lot of conversations around Node and security in the last year.

You all must be very cognizant of the open source communities there. How have you conceptualized all the discussions around licensing and the tit for tat that’s been going on in the open source world now?

Kent: I don’t know. We’re letting that do what it will. We’ve got product roadmaps to worry about, and we’re kind of staying out of the fray there for the most part.

Obviously paying attention, but for the most part it hasn’t been a huge distraction for us.

Ledge: You’re also running for office, I see.

Kent: [laughs] Right.

Ledge: Well played. Well played.

Well, Kent, great conversation. This is super interesting. It’s good spending time with you, and thanks for joining us today.

Kent: Likewise. Thanks for inviting me. Great to speak with you, and keep up the good work over there.

Ledge: Absolutely. How can the audience experience your product? What does everybody do and how do they get involved?

Kent: Our website is yonomi.com – or .co, we use to just be .co. Yonomi is spelled Y-O-N-O-M-I.

On there, if you want to download our free consumer app, you may do that. If you’ve got connected devices in your own home, download the app. It’ll automatically discover your devices and get them working together in a minute or too.

We’d love you for you to give that a try and give us some feedback.

If you’re a developer, which I know a lot of your audience are, and interested in either building smart home devices or applications or services that use the existing devices in the home, you can check out some of our developer resources on the website too for how you can leverage our platform to do those things.

Ledge: Well, I’m quite sure you’re going to see an uptick in people downloading.

Kent: Oh, fantastic.

Ledge: Well, Kent, thanks so much. Good spending time with you.

Kent: Likewise. Have a great day.