Episode 266's Sponsor: Silicon Labs

Silicon Labs, a leader in secure, intelligent wireless technology has launched their 2023 Tech Talk schedule. This year's Tech Talks include a dedicated technology series for Matter, Wi-Fi, Bluetooth, and LPWAN in order to help you build the development skills needed to deliver cutting edge IoT products. Join Silicon Labs experts, industry leaders for these one-hour, live virtual trainings created for developers by developers. Accelerate your device development today by registering at silabs.com.

When developing IoT products, there are many hidden challenges that can delay product delivery. Ryan Carlson and Kenta Yasukawa of Soracom join Ryan Chacon on the IoT For All Podcast to discuss bringing IoT products to market. They explore different product phases like exploration, validation, acceleration, and commercialization, how challenges change in different product phases, getting stakeholders on board, overcoming outdated opinions and biases, distinguishing customers, and IoT trends and predictions for 2023 and the role of artificial intelligence.

About Ryan

Ryan Carlson is the Head of Digital Marketing at Soracom and a veteran of connected product development, electronics manufacturing, product marketing, and user-centered design. His early career was spent pioneering internet-enabled hardware and web-hosted software for remotely monitoring and managing loyalty programs and accepting credit card payments for carwash and laundromat chains across the globe from 2001 to 2012. As a solutions architect and IoT consultant, he has been part of over a dozen successful product launches while guiding both product teams and executive stakeholders that sought to explore the business value of investing in connectivity.

Interested in connecting with Ryan? Reach out on LinkedIn!

About Kenta

Kenta Yasukawa is CTO and Co-Founder of Soracom, where he has led deployment of the industry’s most advanced cloud-native telecom platform, designed specifically for the needs of connected devices. Before co-founding Soracom, Kenta served as a Solutions Architect with AWS and conducted research for connected homes and cars at Ericsson Research in Tokyo and Stockholm. Kenta holds a PhD in Engineering from the Tokyo Institute of Technology, with additional studies in Computer Science at Columbia University's Fu Foundation School of Engineering and Applied Science.

Interested in connecting with Kenta? Reach out on LinkedIn!

About Soracom

Soracom is a worldwide provider of cellular connectivity for intelligent devices, offering a unique type of wireless data service that is specifically designed to meet the demands of IoT deployments.

Their products and services include:

- Self-Provisioned: Cellular Connectivity in Less Than 5 Minutes

- Multicarrier Wireless: One SIM, 130+ countries with multi-carrier coverage

- OTA Updates: Access new carriers, plans, and network profiles without swapping SIMs

- Broad Coverage: Connect with the strongest available coverage over 2G, 3G, LTE, Cat M1 and LPWA networks

- Cloud Native: Connect devices securely to your cloud of choice

- Complete Control: Manage secure networks and devices in real time with a built-in user console and API

- Programmable Provisioning: Manage device certificates and credentials on the fly

- Secure Connectivity: Create your own bidirectional IoT LAN, peer with your AWS VPC, and get bi-directional communication to remotely SSH into devices in the field

Key Questions and Topics from this Episode:

(01:26) Introduction to Ryan, Kenta, and Soracom

(03:13) Challenges of bringing an IoT product to market

(15:20) How do challenges change in different product phases?

(16:26) Getting stakeholders on board

(21:10) How do you overcome outdated opinions and biases?

(23:07) Distinguishing different types of customers

(34:39) IoT trends and AI in 2023

Transcript:

- [Ryan] Hello everyone and welcome to another episode of the IoT For All podcast. I'm Ryan Chacon. And on today's episode, we are going to talk about the unforeseen challenges and tradeoffs when it comes to bringing an IoT product and solution to market. With me today are two members of the Soracom team, Ryan Carlson, the head of digital marketing for North America, and Kenta Yasukawa, the co-founder and CTO. Soracom is a worldwide provider of cellular connectivity for intelligent devices. Please subscribe to our channel. Hit that bell icon, so you get the latest episodes as soon as they're out, and give this video a thumbs up. All right, but before we get into it, we have a quick word from our sponsor. Silicon Labs, a leader in secure intelligent wireless technology, has launched their 2023 Tech Talk schedule. This year's Tech Talks include dedicated technology series for Matter, Wi-Fi, Bluetooth, and LPWAN, in order to help you build the development skills needed to deliver cutting edge IoT products. Join Silicon Labs experts, industry leaders, for these one hour, live virtual trainings created for developers by developers. Accelerate your device development today by registering at silabs.com. That's the letter s, the letter i, l-a-b-s, dot com. Welcome Ryan and Kenta to the IoT for All podcast. Thanks for being here this week.

- [Ryan Carlson] No problem, thank you Ryan C. It's funny 'cause we both are Ryan C, so.

- [Ryan] Absolutely.

- [Ryan Carlson] That's not challenging, so. No, you're absolutely welcome. We're excited to be here and participate.

- [Ryan] Yeah, and Kenta, it's great to have you back. I know we've done this before together, so it's great to have you. It sounds like a lot of exciting things are going on over at Soracom. Maybe you can kick us off by just introducing yourself again, talking about the company a little bit. And then Ryan jump in, give yourself an introduction as well.

- [Kenta] Yeah, sounds good. Yeah, definitely. Thank you for having me back again, Ryan. It was a little bit time ago that we did this together, and I'm so excited being back here. Yes, let me talk a little bit about the company and myself. We are a company called Soracom. We offer smart connectivity platform, so that anybody who has an idea with connected products can get started on connecting those devices to cloud environment, and make sure everything works smoothly and also secure, and they can accelerate their project by using our platform features. And I'm CTO and co-founder of the company, and I've been working with exciting customers and partners to be able to make the world a better place by joining forces with everyone together.

- [Ryan] Fantastic. Ryan, you wanna give a quick introduction?

- [Ryan Carlson] Yeah, I'm Ryan Carlson. I've been in the IoT industry for about 23 years. Much of it was actually building products in the commercial space, so car washes, laundromats, retail facilities, and have then also been suppliers, IoT platforms. So I've kind of seen all the different angles of building, creating, marketing, selling, and have made more mistakes than I'm even happy to admit. But that's how we all learn, right? I'll say you can't tell people what to do, you can only share your relevant life experience. And that's why I'm looking forward to today's conversation.

- [Ryan] Yeah, I've been looking forward too, ever since we kind of kind of put our brains together to figure out, you know, what would be make a good episode for our audience, given the experience you both have. And I know we kind of settled on talking about the unforeseen challenges and trade-offs that come with bringing an IoT product to market. And I thought it'd be good for us to kind of break that down based on the stages of development, from the early exploration through the prototyping, all the way, you know, kind of to the commercialization of it all. So maybe what we can do is just start with those early stages. So early exploration, design, up to the prototyping and pilot stage. And just kind of walk us through, from each of your perspectives, how you see or what you see are some of those unforeseen challenges and trade-offs that happen throughout those stages. That would be good to kinda educate our audience on and to be on the lookout for and how to overcome them.

- [Ryan Carlson] Great. I think that it's worth setting the stage by talking about the seasons that a project and a product team goes through. So this is a loose framework that I've used in the past. Everyone can map their own process and labels to however they wish, but I think of it as exploration, validation, acceleration and commercialization. So a lot of -tions. In exploration, this is where it is an early idea. We may not even have presented it to the internal team. There may be no budget. Someone went to a conference, saw an idea, and so exploration is also sometimes thought of as discovery. And it's where you are now, gathering the information that you need to kind of build that initial business case. You may have very few resources to support you in that effort. Validation is we're gonna have the proof of feasibility, the proof of business viability. So there's two tracks that kind of run parallel in most businesses. You're building out the business case and then in the technical case. Then acceleration is where we're typically, we've gotten funding, we've got a lighthouse customer, there's probably some field testing, using prototypes. You know, you're kind of cobbling things together. There's some pilots, maybe some early alpha. And that's where you're really proving to the customers that have you done the things you need to do before you go and do your first article of manufacturing. So somewhere in that process, you're ramping up to commercialization. And commercialization is where most companies end up kind of running the gambit. So let's start at the first season, at exploration, and where I think the unforeseen situation is, or the circumstances. I'd say the first one is the shiny syndrome. And that's where you, I mean just think ChatGPT. You know, it's almost like, "Oh whoa, we've gotta do something with X, Y, Z technology. We're building a connected product. Well, we've gotta use the latest carbon-dingulator," or whatever it is that came out. And there's a lot of waste without actually thinking through the business case. And now this is all like elementary. Yeah, of course Ryan, everyone knows you don't go running ahead. But I want to think about that exploration to validation to acceleration, that whole track, as two separate tracks; a technology engineering track, and then that business track. The unforeseen danger that I've seen in dozens of projects is when one of those tracks skips too far ahead in the process. And so let's all think about those projects. If we run too far ahead on the technology track, we're running with a prototype, maybe even putting something in the field. We haven't thought about how much it costs, how much we're gonna charge, what the size of the market is, or even who else thinks it's gonna be neat other than the person that built it on the test bench. So the further you jump ahead, the more risk that gets introduced. It's also the opposite too. Vaporware comes from someone with an idea or a big idea running out ahead and pre-selling the thing, right? You're almost at commercialization and engineering is just catching up, and it introduces a significant amount of risk, right? So I would find that exploration is where it's important, where sometimes you have to slow down in order to speed up.

- [Ryan] Hmm.

- [Ryan Carlson] Right? So, my experience has been, be aware of how far down the road you are. And I've seen it most often, engineering has run ahead with a big idea and you miss very important business requirements, regulatory pieces, certifications, and even legal. It's unfortunate that at the legal council at a company I was at, couple places back said, "Yep, I'm pretty much the last person that anyone talks to." And, it's actually almost kind of sad. They're like, "I really wish someone would've come in, you know, early on, because I could've told you that, you know, x, y, z, this consideration, that consideration.

- [Ryan] Right.

- [Ryan Carlson] So, yeah. Maybe you consult an internal legal, early and often with a new idea.

- [Ryan] Well it's funny 'cause like even, that's a comment I've gotten from security companies too, where they sometimes have come in, been brought in later, and it's partially because their people aren't thinking about security early on. It's changing now for sure. But when you mentioned the legal situation, it reminded me of conversations I've had with some security companies where they've been brought in later, and it's caused lots of problems and become pretty expensive for companies to kind of go back and make changes on the security side. Kenta, from your perspective on that exploration phase, what are some of the challenges and trade-offs that you see and are worth noting?

- [Kenta] Yeah, Ryan made a good point about the uncertainty in the exploration phase. The other platform service provider, we have covered all the life cycle stages in the product development, and during the first season that he mentioned, there can be many unknown parameters. And developers and businesses, they need to adapt their direction, adapt to changes, and also they change their course, depending on what they are discovering as they move forward. So in that stage they cannot predict, you know, how many devices will be sold or how much data is going to be used, and things like that, yet. And often when you prototype on IoT devices, and especially when you need to use the external connectivity service like cellular or LP WAN, you need to contract with some service provider. And if you are asked questions like, "Okay, so how many devices are you going to have and how much data you're going to use?" You can't really answer. And even if you answer something, it can be totally wrong when you deploy. So because of that, as a platform, we have a totally transparent pay-as-you-go model for everyone to get started easily. And they can be bought usage or the number of devices anytime. We just, you know, accommodate all the changes and customers can just pay what they use. So by using that, they can actually, you know, get started without having a fear of failure. In case they need to pivot, they can. You know, we can just adapt to that. And also when you start the exploring phase, you may not know what kind of cloud backend to use or what kind of systems to build. So we have features to make it easier for sending data and storing them, and visualize on the dashboard so that you can actually focus on how the devices work, and how the data they are collecting look like, and what kind of user interactions you may have in the early stage of the exploration phase of the project. So by having all these, you know, the platform support to be able to adapt to changes, I think that's an important thing in the early phase of the IoT projects, or any kind of connected product development.

- [Ryan Carlson] That's something that you'd mentioned there, Kenta, that brings up a little PTSD for me, was a smart pump deployment that was being put out into the world. Cellular in a lot of the projects is something that is, that's something you just wait till the end. So there's not a whole lot of discovery. It's like, "Yeah, yeah, of course, there's gonna be regions where we deploy and it's outside of that area. And so the test engineers were testing both cellular where our R & D facility was. So all of the testing was done where a cellular tower's right across the street. And so some of the early discovery or the early exploration was just assuming that you had excellent bandwidth, almost no latency, all of the speed that your corporate connection could provide. And then when it was lighting up the radio, it was picking up on a radio that was just right across the street within a metropolitan area. But when we had to go to the outer reaches of Canada, you know, even at the prototyping phase, it was prototyping in a parking lot. We didn't prototype out in the wild and understanding how latency or understanding how the real world scenario is. And so I'd say during that exploration and validation stage, one of the dangers is assuming that the R & D that's being done on the test bench isn't bringing in some of these interference, machine noise. In the car wash instance, we used our first wireless card readers out in wash bays. And if anyone knows about RF, water is an excellent way of absorbing radio frequencies, right? It's also great at absorbing radioactive material as well. But when you think about a car wash bay where the self-service ones were a bunch of air and mist, you know, misting is going up in the air, that accumulated moisture was dropping the wireless signal down drastically. And so it meant looking at an entirely different set of repeaters, which were not spec'd early on. We had to go to a whole different type of commercial grade. And so all of the pricing that was done at the point, because we would run them, but we never ran and like washed cars and tried to do it at the same time. So it's that idea of thinking through a lot of those other variables which are unforeseen as the environmental conditions. Or doing cabling. If you're doing IoT and you've got data lines, something that caught us at least six different times where we've flown a technician out to do an installation and we found that fluorescent lights, if you're running lengthwise, and then the fluorescent light bays were going in an opposite direction, it creates an interference for ethernet, for RS232, and introduced noise in on a data line. And so these are the things that you lose days of downtime, putting people up in hotels. And then it's the goodwill of the customer, and they might even be prototype, you know, one of those early beta testers. So yeah, I think the environment wins on this one. Mother nature kicks my butt every time.

- [Ryan] Yeah, definitely. So if we move into those next few, I actually have something I want to come back to at the end of these four phases, kind of seasons that we're talking about here. But if we move into the validation and then the acceleration side, how should people be thinking about those challenges and trade offs? Like what changes once you get past the exploration, into now validation, into acceleration, and going from there?

- [Ryan Carlson] Validation and acceleration depend on every project. But usually between those two is getting the green light from the boss, the corporate. You're given the, you know, it's usually stage gate two or three in a corporate setting, where you officially just got money to really go forth and make a run at it. You probably have a project manager, you're given some engineering resources. So early validation is usually a small team, maybe even a pet project. Acceleration is, there's now a team behind you and there's eyes on that project. So the performance of that project can make or break careers as well.

- [Ryan] Yeah, what I've seen in the past is where we talked a lot of other companies and experts who have said in that early stage, kind of this validation stage you're talking about, it's really important to ensure that there's some level of alignment between that small team and these stakeholders, at least at some level. Obviously, they need to be knowledgeable that you're doing this, but ensure that you kind of set out what you think the ROI is going to look like, what success metrics are. So that when you do get to that ability to accelerate forward and get towards scale and so forth, you have their support, and you're not kind of starting from scratch and trying to kinda now sell this back into them to explain why there's value here, 'cause that definitely can derail any momentum and progress that's been made, and the investment that's already been put forth. So how do you all kind of think about that? And I'll be curious just to kinda get your opinions on how people can kind of go about getting that buy-in, in that validation stage, so that when they're ready for acceleration, there's less of a delay and they can kind of progress forward.

- [Ryan Carlson] That's a good question.

- [Ryan] Kenta, what do you think?

- [Kenta] Yeah, definitely, you know, when it comes to the validation and acceleration phase, there's a, you know, the checkpoint to pass. And the one important thing to do during the verification phase is to have a POC available, a successful POC and demoing that to stakeholders, and preferably, also with the potential users in the target audience, and to get feedback. And, you know, if the feedback and all the stakeholders' opinions are positive, it's gonna be smoother towards the acceleration phase. But if there are some, you know, things to adjust, again, you know, it's just always the case that there can be something to fix, you know? And what is important is you don't get afraid of getting negative feedback at that stage. It's always the case that there is something to fix before moving forward. So, you know, having that mind set and also welcoming all these negative feedbacks or constructive feedback, and apply that to the POC before acceleration is an important thing. You know, once you accelerate it and realizes there's something to fix, it's gonna be much more costly and affect the project timeline longer. But if you can detect that in a verification phase, and fix it, and then accelerate, then it's gonna be much more smoother and efficient. So those things are important.

- [Ryan Carlson] I found that.

- [Kenta] Kinda similar to software development process, but some of them can be applied to hardware product development as well.

- [Ryan] Sure.

- [Kenta] Sorry. Ryan.

- [Ryan] Sure.

- [Ryan Carlson] No, no problem. It was something that you were, you know, the proving it to the stakeholders, I find that one of the best pieces of advice is to create some sort of visual output, a simple dashboard, something that is tied to a business outcome. And I've seen predictive maintenance or like pump monitoring or motor vibration monitoring, various initiatives where it's just starting with, we picked the most troublesome asset in this facility and it's the one that gives us an issue every week. And the output is something that the executive team would see, was something as simple as red, green, yellow. And if it's green, it means we're making money. If it's yellow, it means check engine light. We already know that we've got people on it. Red means something is wrong. Right here, this is just a simple visualization that says everything is okay. Or, you know, on this right side, it shows just the number of events going up. It's just a visual cue versus getting into the wave forms and the algorithmic insights of the different sensor datas and readings. Like, it's very easy to lose a stakeholder. Nobody wants to buy a sensor. They want to buy understanding of what's happening in a particular situation, right? So I think the story of what does it look like one year in the future if everything's going well, is oftentimes lost. Especially when it's an engineering led project. Especially if it's a passion project. It's important to equate it into how does this help internal process?

- [Ryan] Building that business case.

- [Ryan Carlson] Bottom line, right? Yeah, draw that business case.

- [Ryan] Building that business case right.

- [Ryan Carlson] Exactly.

- [Ryan] Yeah. From your all's experience, when you've worked with companies and they've maybe, you know, or maybe you have run into this situation when you're talking to companies, is they have potentially outdated opinions and biases, and things that are attached to IoT, the different talent technologies associated with IoT, bringing this into their established kind of companies and processes. How can companies kind of be thinking and approaching that prior to going down that road? Because I'm sure a lot of our listeners run into that where they're talked to a potential customer, or the team that they're working with at a company is now going and selling this back into their management, and they have to combat management's outdated opinions, biases, kind of things that maybe are not as accurate. How do you advise them and how do you kind of approach handling that, or being prepared to handle that?

- [Kenta] One thing that I -

- [Ryan Carlson] You don't have some -

- [Kenta] Oh, one thing that you made me think of regarding that is that, you know, the stakeholders and management may not be the actual users of the product or application that you are building. So even if you get a feedback from them, it may not be right. So even if, when we are building some feature, I may not be the right person, right target user of the new feature. So one thing that I'm always encouraging the team is to go to customer and who is actually going to use the feature, and get their feedback back, and then work from there. So what we do usually is to build something quickly after listening to customer's conversation and pain points in the development, and build something, and then offer to the customer, and get feedback. That will be more accurate feedback than, you know, anybody in the inside company or engineering team. So that's what I would recommend.

- [Ryan] That's a really good point, 'cause we've framed it in this way in the past where it's building kind of from that end user backwards when you start venturing down this path, you know, figuring out where the real pain points are, talking to those people and framing it from there, bringing in the business case, Ryan, that you mentioned. But just kind of working backwards from there as opposed to working from the technology forward. Usually, it kind of helps tie the real pain point, the real need for this to the people that internally is still trying to get there, but they're buying from, because you're actually talking about real problems that exist, because you're collecting them from those end users. But Ryan, what do you think? I know you, you're gonna kinda jump in there before Kenta.

- [Ryan Carlson] I was going to say that when we say customer, understand that it is an incredibly loaded statement.

- [Ryan] Sure.

- [Ryan Carlson] A customer, there are buyers and users, and they are rarely the same person, especially in B2B. So when we are speaking to a stakeholder, they are usually in the buyer or an influencer, then there's the users, and then there's the beneficiaries. Without having the voice of either one of those users or those beneficiaries to speak on behalf,