Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host Eric Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Eric Walenza, CEO of IoT ONE, the consultancy that helps companies create value from data to accelerate growth. And our guest today is Francois Baldassari, CEO of Memfault. Memfault empowers teams to act proactively by enabling them to deploy OTA firm updates, remotely debug and continuously monitor their fleet of connected devices at scale.

In this talk, we discuss the shift away from historical device design to today's environment of affordable low power computers and machine learning at the edge. We also explored the change in the industry towards subscription business models and what that means for both software and hardware developers in terms of lifecycle expectations, security, best practices and analytics needs.

If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have an IoT research, strategy, or training initiative that you would like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you.

Francois, thank you for joining us today.

Francois: Pleasure is mine, Erik, cannot wait to talk with you today.

Erik: Before we get into the topic and your company Memfault, it would be great to understand a little bit of your backstory. So I think if I understand from your accent and your name, you're probably from France originally and then located to Silicon Valley sometime in the past. How did you make that migration?

Francois: You got that right. So I've been in the United States since 2005, but I'm originally from France. Those of you who see my name may ask yourself, where is that guy from? I'm actually Corsican. So it's a little island between France and Italy. And the names are Italian, the language is French. But for the past 15 years now I've been in the United States. I've lived all over the country, did my school here.

I have an electrical engineering degree from Brown University, where I met my cofounder, Chris. And really the past 10 years, I've been working in the embedded software as an embedded software engineer. So I've done consumer electronics, I’ve companies like Oculus Pebble. I also did enterprise hardware. I worked at Sun Microsystems for a while doing chip bring up and firmware for some of the big Spark systems. They're not too many of those around anymore. But they were really cool back in the day.

I actually initially came here with my family and so that's how I ended up in the United States. And I've been in California now for nine years here. And I’m in Oakland today, so on the East Bay near San Francisco.

Erik: It makes sense why you would be developing software to help companies bring hardware to market today because you've worked with companies like Pebble and Oculus, so you certainly have probably struggled through this process yourself. But maybe we can talk a bit about what led you to decide to devote now a significant number of years of your life to setting up this company. What was the struggles that you had in Pebble and an Oculus that led you to think we need a new solution here?

Francois: It all comes back for me to the years that I spent at Pebble. Pebble was a really unique company. We were a hardware company. We built a watch that had inside of it an STM 32 microcontroller. So a very small chip, it had 128 kilobytes of RAM. It had 256 kilobytes of storage. And with that very, very small chip, we had a full operating system. It had a user interface had a file system. It had third party applications that you could install and run on it. It had complex graphics and synchronization with the clouds, a really complex software stack.

And in fact, although we thought of ourselves as a hardware company, the majority of our work and the majority of the team was focused on the software. And so we started having problems that I think many of your listeners will be very, very familiar with nowadays. Our software have tons of bugs. There's Jack Ganzel, who's kind of one of the great thinkers in the embedded software industry says that there's one bug for every 100 lines of code. I don't know if that's how many bugs we had in the Pebble firmware.

But it certainly felt like it. Every day we had hundreds of people calling us and saying, the Bluetooth doesn't work very well, or the battery life isn't what I expect. And I was one of the engineers who was tasked with basically getting all those watches back from customers, cracking them open. And it required a heat gun, a hammer and a chisel to open the watches up, then connecting some wires onto the debug ports that I could try to figure out what was going on with those watches. I called it “Firmware Archaeology”.

So I was dealing with these really complex software bugs and had a really hard process to get into the debugging. Sitting next to me were these iOS and cloud engineers that were working on Pebbles, mobile applications and web applications. And these folks, they had amazing tools, they could open up a dashboard, and they would immediately see what kind of issues a customer was having with their app and what kind of issues the cloud was experiencing. They could get live performance data. And their work was so much easier than mine in many ways because they could just pull the data and start working right away. So when it took me weeks to fix a bug, they could get something done in a couple of hours.

I spent a lot of time wondering in jealousy like whether it was possible to do something similar for hardware. And I was really lucky to work for a guy named Kean Wong, who was an amazing VP of engineering. And when I told him, hey, I want to try to build some tools for ourselves to try to be as productive as the mobile engineers. Ken said, sure, take three months, go see what you can build.

And at that time I built the very first DevOps kind of set of tools for Pebble. I built a way we could collect crash reports from the watch. We built ways we could collect analytics from the watch telemetry, what the battery level is minutes after minutes, what threads are running on the system, how much the Bluetooth radio is being used. And it changed the way we worked. It led to our support team being way more effective, because they can look at real data when they advise the customer. It lets our engineers to spend way less time trying to reproduce issues and instead work with hard data to resolve problems. And overall, it changed the way we looked at our product development. We became way more data driven, and we're able to move a lot faster.

And what I'm really proud is to say that our support values went way down. The Amazon reviews for the Pebble Watch improved a lot because people, we no longer had those one star reviews because of Bluetooth not working, for example and our engineers were a lot happier. At that point, we became able to ship new software every two weeks move, really fast, and it felt really, really good.

And so after that experience, I became obsessed with the idea that embedded software could be just as sophisticated and have just as good a set of tools as the rest of the software industry. And so I applied some of those ideas at Oculus as well, I built a lot of tools for the team at Oculus. And then it became clear that instead of doing it one company at a time, I should just try to build it once and for all, make one platform that every hardware company can use to move fast without breaking things.

Erik: Why were the existing products on the market that were working so well for cloud based solutions, why were those companies solving this problem? Was it that it was at that time too much of a niche because it embedded consumer products were just coming to market? Or was the problem so significantly different to solve from the web base that it required an entirely different approach?

Francois: I actually think it's both. And it's funny because you just gave me two of the talking points that I use in some of my fundraising and some of my sales call with customers. Why don't the software companies have a solution for this already? And the first point you made which is about the maturity of the firmware ecosystem, like firmware was really a niche, it's true. 15 years ago, firmware was just a control loop. It was you had a couple 100 bytes of RAM, maybe a couple kilobytes of RAM and so you didn't really have true software running on devices. And therefore, the companies that built software tools didn't really think about firmware.

It's really a new phenomenon that embedded software has gotten so complicated. I mean, nowadays, you see things like machine learning at the edge, you see things like computer vision at the edge, you see tons of software being written on those IoT devices. But that's a relatively new phenomenon. So up until recently, software companies might not have cared, and the need might not have been there. But also, the use cases are very, very different. Although the technology is very different, although the need is similar, at the end of the day, embedded devices are very, very different constraints.

Most of the observability solutions in the cloud today are focused on collecting a lot of data, and then doing processing in the clouds to figure out what to keep and what not to keep. But with embedded devices, you don't often have the bandwidth, or the storage, or the capability to collect a ton of data. So you need a different approach, you have to be very, very judicious to choose the right bits of data to send to the cloud on the device itself, and that fundamental difference in the capabilities of the devices lead to very, very different products.

So today, some companies try to take software solutions, and shoehorn it into their devices and they find that the amount of data that is coming out of their device is just too much for their BLE connection or too much for their cellular connections, and that also it takes too many resources from their microcontrollers or their small SOC s. So that's why a new solution was needed.

Erik: So you need basically a very lightweight solution that lives on the device that can identify what data is important, maybe do a little bit of preprocessing, and then only send that select data to the cloud so that you don't stress the hardware, or maybe the data feeds?

Francois: Exactly.

Erik: And is this historical shift? Where would you say we are today? Are we 80% in terms of having 80% of companies that are now building embedded devices, taking this approach? Or are we 20% along the way? Because I guess we still have a very mixed environment in terms of how embedded software has been deployed.

Francois: Yeah, it's still very early days. For example, even IoT, you might say, is still in its early days. There are a lot of devices being made even today that don't have connectivity. So IoT is early days, certainly, software infrastructure for the IoT is 1% into the journey. And so I often like to say that today we work with early adopters, companies that either have a particularly complex problem at hand or companies that are just, like to be on the cutting edge.

But these problems that we consider, the fact that software is very hard to manage at scale, and the fact that these devices have more and more software, they’re problems that every device manufacturer is going to run into sooner or later because they are they have to build interactive connected products to stay relevant in the marketplace. And as soon as their products hit a certain threshold of complexity, they will hit the issues that Memfault addresses.

Erik: So if we look at the different categories of IoT solutions, then maybe you would be supporting things like smartwatches, maybe medical devices, edge computers, maybe embedded computing in vehicles or in other mobility solutions, but you wouldn't be addressing things like maybe a smart sensor or something? What would be the categories that have enough compute power and complexity that makes sense to use this approach today? And what are the categories that are still going to be using maybe a very legacy approach, or for whatever reason would not be suitable for your solutions today?

Francois: We look at three things to evaluate suitability for a given device. Number one, how much compute do you have? So if you're running on a 32 bit microcontroller, and you have maybe 100 kilobytes of RAM or more, you're likely a good candidate for four Memfaults. If you're running an 8 bit system, a 16 bit system, one of those big microcontrollers, it's probably not yet appropriate. That's the first thing.

The second thing is how are you connected? If you have 1,000 bits per second of burst bandwidth, we can make this work. But if you're on a very, very low bandwidth solution, you have maybe a couple 100 bytes per hour. And there are use cases. There are some lower radios that get into those very, very low bit rates. Here again, you're probably not quite the right company or the right product for us.

And then last but not least, and this is a nontechnical consideration, but oftentimes as a business model consideration if you're building a product that is connected to a services revenue stream or a recurring revenue stream of one form or another, you're much more likely to care about continuing operations, and to care about quality. Because if your product doesn't work, all of a sudden that revenue is at risk. And so you start caring about quality a lot more.

So if you have a 32 bit MCU, you have connectivity, that's more than 1,000 bits per second and you have a revenue model that supports investing in continuing operations, oftentimes, that's a really, really good use case. And so what that means in practice is that industrial IoT is a really good place for us to work. Access control systems, so things like the smart buildings, smart office type of applications are really great for us. Payment processing hardware has been really an awesome place for us, and to a lesser extent, automotive and medical devices, because some of those companies are still on more transactional business models with much less connected hardware.

Erik: So far, I think we've kind of touched on to two changes in the marketplace. So, one is the change in the compute hardware and migration from hard coding on hardware to using more modern software approach to enable features. Second, is this subscription model. What about the changing connectivity landscape? So certainly, we see quite rapid change in the ability to send data, the cost structure around sending data. But how does this impact the use of your solutions?

Francois: The proliferation of connectivity is a big enabler for us. Back when devices were connected on 900 megahertz networks that were very, very low bandwidth, you might not have been able to collect as much diagnostics because you were very, very bandwidth limited and you might have wanted to conserve your bandwidth as much as possible to enable your use cases, your actual products, rather than to collect diagnostics.

But today, as you mentioned, there's connectivity is becoming more and more accessible for device makers. You can put a low power LTE radio on your device, and have tons of bandwidth, you can probably get a pretty cheap plan that gets you 10 megabytes per month or something like that, which is actually a lot of data when you're a small microcontroller class device. And so this means that you can start thinking about new ways to use that data. And I think diagnostics, telemetry and fleet management type solutions are definitely one of the things you would consider.

And to your points, it's one of many trends that is driving adoption. Fundamentally, in my opinion, what this comes down to is connectivity computes, those things are enabling more software to be built and more software means more software problems. And the business model change that I mentioned around subscription, I actually see that business model change as an effect rather than a cause. It's actually driven by the adoption of software, that we're seeing more and more subscription models. Because when the majority of what you're building is software, you have a lot of ongoing costs, you have servers that are running your cloud software, you need to pay software engineers to constantly fix bugs and ship new features, and therefore you need some sort of recurring revenue model to support that.

So I think this industry shift that we're seeing in terms of capability, connectivity, revenue models, they're all actually part of the same trend, which is, there's more and more software being built in the hardware industry.

Erik: Let's then discuss a bit the use cases here. And maybe at least for me, a useful way to think through it is to think about it in terms of the development the DevOps process. So solution development, you have deployment and monitoring and maintaining uptime and devices and proper functioning, and then you have maybe troubleshooting, and then you have the continuous improvement process. But how do you think about this? And then where do your solutions fit into the DevOps process?

Francois: What you just described is the like, the figure eights diagram that people often think about when they talk about DevOps, where the left side of your figure eight is the design, the implementation and maybe continuous integration part of the DevOps cycle. And the right side of that figure eight is deployments, monitoring and troubleshooting. And so Memfault is squarely focused on the right side of that figure, it’s the deployments, the monitoring, and the troubleshooting of your fleet of devices. And those are the three pillars of our products.

And so we've actually built three product experiences that address these three pillars. The first one is deployment, which for IoT use cases means management of over the air updates. So we've built a fairly straightforward solution that lets us deliver software update binaries to devices anywhere in the world cost effectively and intelligently so that you can do something like stage rollouts, where you update 5% of your fleet and 10% of your fleets and 20% of your fleets, and have the ability to accelerate or slow that roll rollouts if you see errors in the fields.

We then have the second pillar, which is Monitoring. Monitoring is the ability to collect attributes, but also time series data from your devices. You can collect things like what the battery level is, how much free memory the device has, how many bytes it's sending over its network connection and how many bytes are being written to flash. We make it very, very easy to select any kind of data that you want to collect with just a couple lines of C codes. That data all ends up uploaded to the cloud where you can query it, you can search devices based on it, you can say, I want to find a device that has poor battery life. We can help you find that device and dig into it more.

But we also aggregate that data. So you can see, on average, how much free memory do my devices have? And has that change since my last release? Is this getting better? Is this getting worse?

And of course, the last pillar is debugging. Because no matter how hard we try, bugs come up and problems come up in the fields. Debugging allows us to collect a payload whenever an error report or crash reports, whenever a device encounters an issue. We're able to collect things like a back trace from the software. We can collect snapshots of the memory of the device that you can dig into specific variables in your code that might be meaningful in your debugging efforts. We can collect register values. We can collect logs.

We take all of that data, we route it over whatever network you have. We can send it over Bluetooth. We can send it over ZigBee. We can send it over a serial bus to a gateway and pass it on to the cloud, and then get the diagnostics data back to the cloud where we then able to map it back to symbols, it’s called D symbol locating it, as well as duplicating it. So taking all the reports from all of your devices in the fleet and merging them together so that instead of looking at 100 different reports that say that a device experienced a specific issue, you're looking at one report that tells you 100 devices experienced this one issue. And so that makes it super easy to prioritize and spend your debugging time and energy on the few issues that really matter.

Erik: And when you're selling this basically your solution, what are the KPIs that your customers are monitoring around this and that you're focused on improving? There's a lot of labor involved in this process, there's customer service issues, but what are the key KPIs for you?

Francois: We look at four main KPIs. The first time is what's called MTTD, Mean Time To Detection, how quickly your team is able to find out about a problem. So without Memfault, it might take you days before a customer calls you and tells you there's a problem. With Memfault, we're able to identify a problem and immediately bring it to your attention. So from days to minutes is the improvement in the meantime to detection. That's the first KPI.

The second KPI is Mean Time To Resolution: how quickly when there is a problem, do you get to the bottom of it and fix it. And so here again, we can accelerate that significantly. Because by giving your engineers all the data they need to fix the problem, and making it so that they can get to troubleshooting without having to reproduce the issue locally, or without having to get their hands on the device experiencing the problem, either by sending a technician out or getting the device mailed back to the office, we shrink back how quickly you can resolve the issue by a lot. And we've seen customers go from spending six months tracking down a particularly hairy Bluetooth bug to resolving that issue within days of deployment fault. So on Mean Time To Resolution goes from weeks or month to two hours or days. Here, again, a major improvement.

And then we look at more kind of operational numbers for the broader organization. So number of returns and support requests, for example, basically, how much of your margin is going to servicing your customers as they are today? So how much of your margin you're spending on customer support and warranty returns? If we can fix every software bug in your fleet, you can imagine that we can drop down your number of warranty returns by a lot and we can also drop down the number of customer support requests by a lot. So how much money you're spending on those things are really important KPIs for us.

And then last, but not least, is product quality. If we fix the top issues, you'll see things like your ratings, whether they come from customer testimonials on your website or just an Amazon review go up. So those are the four things that we focus on improving.

Erik: Very broadly, I define customers in the IoT segment into digital native companies, which are often venture backed startups, and then the legacy companies that might be a large industrial company that's been in the market for decades and is now also building IoT solutions. But across the different customer segments, are they already tracking these four KPIs that you've mentioned historically? Or are you basically going in and saying this is what is important for you to track, and we can help you improve them, but you then maybe need to set up a baseline first? What's the status quo?

Francois: It's very, very dependent by industry. So for example, if you look at companies that make lighting systems or smart city systems, big industrial companies that have been around for a really long time that sold your city the city lights that illuminate your streets, those companies actually track things like uptime, because they have SLAs that they offer to the cities to the state governments. And so they have to track how well their devices are working and how quickly they can resolve an incident when it happens.

And the digital native companies, of course, track things like incidents, bugs, and because their software and they're used to doing that. But to your points, I would say the vast majority of companies that have been building hardware for a very long time, they're oftentimes very operational and very financially driven. So they likely have an idea of how much it costs them to do customer support, they have an idea of how many returns they see and how much that costs them. That's a good place for us to start the conversation. But they typically don't really know what type of software bugs they have, how quickly they get resolved. So this MTTR, MTTD concepts are things we have to teach them.

So we approach every customer based on the industry they're in, and every company we talk to with fresh eyes, and we look at what are the concepts that make sense to you, how do these concepts affect your business, and how can we give you the language and show you the methods and the processes that we've developed so that you may improve on the things you care about? So if you have an SLA with the city of Paris, you might care about fulfilling that SLA. If you are a medical device company, of course, you'll care about quickly identifying problems and hopefully having none of them that ship outside of your factory. So I think different companies care about different things.

Erik: Where are the majority of your customers come in from today?

Francois: We have a couple segments that work really well for us. So today, I think top of mind for me are the energy sector. So, for example, End Phase and Sunpower, two companies in the solar energy space are customers of ours. The connected fitness space is very good for US. Companies like Whoop, I-fit which makes a bunch of treadmills and gym equipment, the hardware that does payment processing, you think about your credit card terminals, coffee shop, things like that, as well as the micro mobility space. So, scooters, bikes, the electric devices that you use to get around your city. Those are four spaces that today we found a lot of traction in.

There are others like access control and some consumer electronics because that's where we started our career. But I liked those four segments. We think there's a lot more we can do there.

Erik: I guess like uptime would be a big consideration for all of those. But is there a silver lining, or is it just that they all have unique needs that happened to be addressed by your solution?

Francois: So they all have a service driven business model. All of those categories, they often time make money, not by selling you the hardware operating it. So I think that that's a really important consideration because they spend a lot more energy thinking about how are we going to operate these devices for the next 10 years? Then a company that sells you consumer electronics. That's the first thing.

And I think the second thing is they are fairly complex devices with quite a bit of software. And so, I would say, half of the companies that we talk to in those spaces have machine learning strategy. Half of those companies think about how they are going to accelerate their adoption of digital tools and digital technologies. And so I think those industries we've found traction in because they are typically at the leading edge of some of those transformations.

Erik: Let's talk a bit about the stakeholder side. So who are you selling to? Who are then the users of the solution? And are you typically selling direct? Or are you going through partners who could be design firms or who could be providing some other service already to these customers?

Francois: The majority of our customers today come direct. We have started building partnerships. So we have partnerships with chip makers. For example, Nordic semiconductor, Sai Labs, NXP are partners of ours and they're basically helping us make Memfault better integrated into their chipsets and distributing it to more of their customers. But overwhelmingly, the majority of our customers today come to us, we sell to them direct.

And our primary user is the embedded software engineer. So we focus first and foremost on making the embedded software engineers more productive and giving them the tools they need to accomplish the business goals that are set for them. That means that our buyer is oftentimes a VP of engineering. The person we go and sign a contract with is a VP of engineering or a CTO, sometimes a director of engineering.

But I think there are actually more and more stakeholders that are getting involved in the conversation. So I was very surprised, for example, to see some of our customers very quickly start onboarding support teams on our tool because their support teams would get customers calling them, saying I can't get my device to connect to my phone or something like that. And because they would have no data whatsoever, the only thing they could do is ask the customer questions.

So our customers started onboarding their customer support teams on Memfault so that they could pool up the devices data and say, oh, I see that your device has this issue or is doing that. And that's really enabled them. We've also seen product teams, so not just the engineers but the product managers start to use our product more and more. And these are things that happen organically without necessarily us thinking about it or prompting it. And so we're building more things to make those use cases a little bit more economic.

Erik: I work with a lot of companies that are selling legacy equipment, things like construction equipment, and often once the product rolls out the door, they never see it or hear from it again and they have no idea who's using it, how it's being used, what functions are being used, etcetera. And obviously, that's all very valuable data to bring back to the product development function and also to some extent, the sales and marketing function so they know where to focus their communication. Is that part of what you're doing? Or are there other solutions that are more oriented around that, that kind of data stream?

Francois: So we try to tread lightly around that. We see ourselves as first and foremost DevOps and Devo patrol solution rather than what you might call a product analytic solution, which is a company like Amplitude or MixPanel that you used to understand the usage patterns of your product. And the reason that we've really focused on the Devo patrol side is because we think the privacy implications are very challenging around product analytics for IoT. You're talking about devices that might be always on in people's homes, that might have microphones, that might have cameras. And so product analytics is very, very difficult to do in a privacy respecting way. We've decided to stay at arm's length from that.

That being said, some of the diagnostic data that we collect is useful for product managers to figure out which things are working well and which things are not working well. But we stay away from things like how many hours the user watching YouTube on my android-based device? Because that's a little too personal and a little too sensitive, we think.

Erik: This is one of the big tensions in the IoT market is that a lot of the value is interacting with privacy issues. Your business model then, are you based company? Is this like pay per device or pay for product category? Or how does that look?

Francois: We’re a SaaS company. We have the ability to do on-premise deployment for the customers really need it. But overwhelmingly, we focus on SaaS use cases and that's how our customers use our product today. So that means that we have a SaaS business model. Our pricing is a little bit complex, but at the end of the day it comes down to how much data and compute are you going to consume and how much is that going to cost us? And for most of our customers, the easiest way to figure that out understand how many devices they're going on board on the service and give them a price per device based on how much data we believe those devices will consume.

So it's a per device price, but that underlying it is a compute and data business model that we try to shoehorn into a per device price. And the reason that the per device is still our focus is because CFOs of hardware companies wants a predictable cost of fronts. They want to know how much is this going to cost me this year. And meter building, which is very typical in DevOps use cases for the clown and mobile markets, meter building gives you very unpredictable costs that might change from month to month.

So we got a lot of negative feedback at the beginning of the life of our company that meter building wasn't going to work for these hardware companies that sometimes planned their budgets three years in advance. So that's why we focused on upfront capacity that they basically say the biplane for up to so many devices upfront paid annually, and that creates a lot of predictability for our hardware makers.

Erik: Let's wrap-up here with a case study, and you mentioned that Panic might be a good one. Maybe we can start with just who you know who Panic is, what they do, and then we can get into what exactly you are supporting them with.

Francois: I'm very excited to talk about Panic because their product, which is the Playdate. It's a handheld game system, is just now starting to get into customers hands, and so it's a very cool product. I have one and I've been so thrilled to be part of their journey. And at Panic, we've been working with Mark Jessome, who is one of their embedded software engineer, and we've been working with Greg Maletic, who is one of the product managers and leading the overall project, and they've been fantastic partners.

Erik: So you said this is a relatively young company just bringing the product out to market, how are they using Memfault?

Francois: So Panic actually has been around for a long time, but they're one of those companies that does all kinds of different things. So they build video games. They've built IGEs. They've built Get clients and SH clients and all kinds of tools for desktop, for mobile and other things. You can think of them as a product creation studio. And Playdate is their latest products handheld game system that comes with subscription, where you get a new game every week.

And so we were lucky to meet the Playdate team at the very beginning of their project. They're a digital native company, that is they are a software company that was building their first hardware products. And as a software company, they immediately knew how are we going to know how well this works, how are we going to fix bugs once we find them in the fields, and how are we going to distribute software to these devices? It can't possibly be that we have to build this all ourselves. And so, through word-of-mouth, they found Memfault and we were put in touch with them. And it's been really, really fruitful partnership because they are very sophisticated software engineers.

So they had a lot of feedback for us and we understand the hardware market very well so we could help them think about trouble shooting and think about how the guts of their product might work. I think that today Playdate use Memfault for all of their over-the-year updates, they use Memfault for all of their diagnostics, their metrics and they're seeing a hugely successful launch with products that are working very well. And I think that we played a small part in that. Of course, their engineers did all the heavy lifting. But I was very happy to be able to help them in that.

And I think that without Memfault, they would have had to build this for themselves. And as a very small team, this is a massive investment, building your own OT infrastructure, building your own monitoring, or just doing away with it, deciding that you can't do it, and so going blind with a big product launch. So I've been very happy with how that's worked. I think they're very happy. They actually have a case study on our website that you can read in more details where we have some great quotes from them.

Erik: I think we've covered a good amount of territory here. Anything that we haven't touched on for us that would be important for folks to understand?

Francois: I think the one thing that I'll leave you with is that we're only getting started. At Memfault today, we do over-the-air updates, metrics error reporting, and debugging. But we're constantly thinking about where DevOps is going to go in the future for the hardware industry. So I'll leave you with three things that I'm excited about.

The first one is experimentation frameworks. So AB tests, feature flags, the ability to toggle behavior and update what your device is doing, tune parameters remotely so that you don't have to do a full firmware update when you want to tweak a little bit the behavior of your device or run an experiment. So that's something that we're thinking about a lot and we'd love to invest in more.

Number two is security. As you know, security in the IoT space has become a hot topic, and there are many companies wondering how they're going to make sure that their devices are secure in the future. Memfault has a unique point of view there because we have agents running on so many devices that already monitor the behavior and the performance of the device. It would be an incremental step for us to start looking for security flaws and automatically start detecting things, like a hacker trying to connect to your IP camera or trying to connect to your access control system. And I think there's a lot of value there. So I'm excited to dig into that topic more.

Last but not least, we're increasingly building integration across different platforms. So let's say that you have a device that inside of the box has a Mac controller, an SoC-running Android, or perhaps another CPU running Linux, maybe a combination of all of those in one box, with Memfault, we have the ability to instrument all three of those operating systems and give you an overall picture of how that device is working. This kind of introspection both very deeply at the microcontroller level, but also at a higher level, putting together the data for an entire system is something that we're doing more and more, and we think we can deliver a lot of value to companies that make very complex devices.

Companies like car manufacturers who might have hundreds of Mac controllers instead of one device, it's not good enough to just be able to get data from a couple of those. Wouldn't it be exciting if Menfault could give you all 200 Mac-control telemetry from all 200 Mac controllers at once to tell you what parts of the vehicle are working well and what parts aren't? I think that's something that I'm really excited to explore.

Erik: As you said, we're just starting here with the IoT journey, and this set of problems that you're solving is a set that everybody has to solve one way or another. Really the last question here, and I've got to ask this just because we have a lot of CBCs and VCs listening on the podcast. I saw that you'd raised your last raise in Q2 2021, at least according to CrunchBase. Anything planned for the near future on the fundraising side?

Francois: We don't have our plan completely laid out. But I expect that in the next 9-12 months, we will raise an additional round of funding. We, up until now, have had great partnerships with our investors. And I've had a relatively fruitful conversation with every investor we've talked to. And so we look forward to meeting more of them and bringing more people on board for the journey.

Erik: Great. Francios, thank you for taking the time today.

Francois: Erik, the pleasure was mine. And if anyone found this conversation interesting and wants to continue the conversation or ask any questions, don't hesitate to send me an email at francois@memfault.com.

Erik: Thanks for tuning into another edition of the IoT spotlight podcast. If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have an IoT research, strategy or training initiative that you would like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you.