Developer experience for IoT

Speaker 1: Thank you. So I'm Nicolas. I'm dealing with developer relations at Sigfox since, shorter than two years. I'll try to tell you about two things that maybe most of people don't do right, including me, which are developer relations, developer experience and IoT, so mixing the old buzzwords today. I'll straight to the point about IoT.

Speaker 1: Very often, the first feedback I have from developers is just burn it with fire. Maybe a couple of you are familiar with Internet of Shit, Twitter handle, for example, that kind of stuff, Mirai botnet. A lot of nice stuff around the IoT buzzword recently. So very easy to me to deal with that, explaining to people, no, no, no, that's different IoT. So we had a lot of difference of misunderstanding about what people hear when they think about IoT and what we really mean.

Speaker 1: IoT is not just only our useless gadgets, the Internet of shit ones, the stuff for gigs that never works, that ends up in your Kickstarter drawer, that kind of stuff. That's part of it, but that's not the main one. That's at least not the reason why we do developer experience. We do developer relations at Sigfox. We may need Sigfox.

Speaker 1: Bluetooth is good for gadget, for personal devices, but not everything has a smartphone, not everybody. Lampost don't have a smartphone, usually pallets that you are tracking using low power networks, don't have access to a Wi Fi hotspot, that kind of stuff. And, yeah, one thing about the Mirai botnet, VCR security cameras, it's nice to call them IoT devices, but in the end, are just computers with a dedicated use, with an IP access, ports all open, very fine. That's not what I'm talking about. I'm talking about things, sending messages every now and then.

Speaker 1: The good news is you can use Sigfox. You won't be an attack vector to your Netflix, to your favorite website or whatever. Different architecture. I can speak about that later on. I'll try not to make it too Sigfox talk of course.

Speaker 1: A little backstory about how and why I joined Sigfox so shorter than two two years ago. It all started because I started using Sigfox summer two thousand fourteen when it was starting to get a little known, at least in France, a nice funding round, new investors and so on. So I tried to use it. I used it for a customer project and I gave a talk at a local meetup about that. So it's still online.

Speaker 1: Didn't remove it. So this was one of my slides in this meetup. So okay, the service was great. This was a developer portal at the time. To be honest, you can check developer.cfx.com today.

Speaker 1: That's still a four zero four, which was another name, but we have a dedicated portal now which is called makers.cfx.com. That was a state there. So that's what I was telling two years ago was, okay, the service is great. Once you manage to get your hand on something that works, get access to the service, the experience was crap, basically. And six weeks after doing that talk, I had a message saying, we're trying to improve that and we want to hire someone to lead the effort on that.

Speaker 1: So that was my reaction, say, oh, fuck. I I just wanted to complain. So okay. So I need I had to walk the talk to make it happen, to make sure that the experience for the IoT developers looks like something usable, at least that was not the case. First issue is what is the IoT developer?

Speaker 1: Okay. So this one is reading a gQuery minified code, but maybe it's doing other things. So it's just your usual developer. All you need is APIs, APIs, tokens to test your APIs before onboarding, good sample codes using all your languages and so on. Yeah, that's some of the IoT developers.

Speaker 1: Or maybe your IoT developer is an electronics guy. All he cares about are millivolts, not bytes, not your API, whatever. So you have to be able to talk to this guy as well, make sure that your hardware part is right, how does it work, how to get started with the hardware part. So electronics, embedded systems, that's not the same guy, you may guess, usually. Or if you're lucky, you'll have to deal with the IoT developer with all about radio, maybe a radio ham, maybe someone who just want to hear about DB, budget link, DBM, DBI, name it.

Speaker 1: You have to get ready for that, to give him something to eat, something to sync, to understand that it may work for him. What is the configuration of your base stations? Wow. What is the sensitivity? You have to deal with all of that.

Speaker 1: So it's not just about API. The IoT world is about the physical world as well as the digital one. So you have to speak to all these different profiles and try to make them, all of them happy, which is not that easy, obviously. And the IoT world, it's a nice buzzword, but it's not only a brand new world. It's an old world evolving.

Speaker 1: You're speaking to developers that are working on old systems in old industries. It's not just about your fancy startup, fortunately or unfortunately. As I said, you have people that worked in electronics for twenty five years. You have to provide them with the right materials that fit their culture the way they are used to work. Maybe they are more into formal documentation or data sheets that's your fancy webpage.

Speaker 1: They have to deal with telco veterans, radio analysts, and make sure that everybody has the right information and the right path to get started quickly and to get the right understanding. And what can make it even more difficult to us especially is that we deal both with hardware, with a cloud platform, and we have our own dedicated architecture, meaning like I have a lot of things to explain to developers, a lot of information to give them to explain them why it's not working for them today, which happens, unfortunately. So the first goal, the first thing we had to do was to back up our claims, make sure we can start building trust with developers proving that we are not only pushing marketing claims, that we are not only a company raising money, for example, that kind of stuff. So those were, let's say, the three main claims that we had when I joined, which we are aiming for global coverage with our service. We have an open hardware ecosystem.

Speaker 1: We have the best radio protocol ever and so on. So this is very easy to claim, but you have to back this up to make sure that people have some trust in you and want to get started and do that quickly, efficiently. So global coverage, we pushed. We had the precise map, which is available online. So no more doubt for the users.

Speaker 1: You see what you'll get. Data sheets, whatever is available, you have all the information available about the modules, the way to build your own communication module with your own MCU, radio transceiver, whatever you want if you're hardware geek. We detail, we speak more about how it works on the protocol side, how it's built, what are the design choices are, again, building trust. And the main goal, what we are working hard and what you have to do in this is make things simple, simple, simple. But the only thing that we need to focus on, we are addressing so many different needs that as soon as it starts to get complicated, you lose people, you get people quitting or not wanting to move forward with you.

Speaker 1: So simple means simple to order when we speak about development kits. Two years ago, a development kit for to use a Sigfox service was between €100 and €115 You had no way to order it online in less than a dozen clicks. You had to ask for a quote to get an access to the service that was costing something like €15. So simple to order, simple to get started with, and simple to integrate with what you already have. You're working with Arduinos for your prototyping, use an Arduino based solution.

Speaker 1: You are working with Raspberry Pis, do it. You are using Nucleo kits, do it. You need to have your own compatible solution available so you don't have to change everything just to test or to try out this new service, this new technology. So again, very easy to say, kind of harder to do, but keeping that focus on this and simplicity is what we need to do on all parts of the activity, be it on the hardware, development kits and on the cloud platform way. Because things that may be obvious to software developers, myself, I come from a web background, I did that for fifteen years, is not for electronic people, people that worked in embedded system for twenty years.

Speaker 1: As soon as you start speaking about, yeah, it's a REST API, very easy, you just do a POST request and then you'll get JSON. No. No chance. Really, chance. So make it simple, explain simply what it means, that you'll get the data coming in your own application server or rely on tutorials made by our partners, be it Amazon, Microsoft, IBM.

Speaker 1: Whoever integrates, make it simple for people to trust it and to either build their own solution or if it's not their core business skill, to just take something off the shelf, they get started quickly, copy and paste, and then they'll have time to sync to improve that. So make as many things as possible public, available, and again, simple and simple. Don't consider that everybody will have the knowledge about the whole ecosystem in the IoT from the hardware to the radio communications to the cloud platform integration, security, whatever. And again, something maybe obvious, but I think a few people spoke about that this morning. The importance of taking a step back, especially in this business, which is brand new, You can very easily get drowned in handling today's core issue.

Speaker 1: We need to help this developer, this one company, this one team solve this issue. You can get drowned in that very quickly. We are a very small team. The whole Sigfox DevRel team is here today, which is two. So the hard part is taking a step back, think, work on your strategy to make sure that it will be better for people in three months' time because otherwise, you will just run after incoming emails, incoming tickets, incoming whatever, and in the end, you won't help anybody.

Speaker 1: So that has been the hard part. Let's say, this the hard way by joining, hoping from an event to a meetup to a conference and not doing anything in the end. And, yeah, what I strongly believe is once you have a question that pops into your inbox or in your forum, on your Slack more than two times, there is something wrong on your side. Either the product is an issue, either your documentation is one, there is something missing, something that either missing or not clear enough, mostly more often that's the case. So stop answering these emails and just put that online so you you won't get bothered again by the same question coming in.

Speaker 1: It's not always about the user not being able to understand. Most of the time, it's your product or the way you explain it, but it's not good. And this one, very easy to say. Everybody pretends that. Let's say that, what we say in January and when, October comes, you realize that you are stuck in this.

Speaker 1: But really, that's what worked for us and this is very important. I think it's more than for all dev population activities, but very in this kind of space, which is the IoT, which is a mess, to be honest, most of the people don't know what they are doing. You have people launching startups that never produce a hardware device in their life. You may guess that usually it doesn't end very well or that's why you have your delivery two years after backing a project online, that kind of stuff. So take time and make sure you are helping people in a few months that everybody will be able to move fast.

Speaker 1: Something important as well, as I said, the IoT world is somehow an old world evolving, old companies shifting to digitalization, adding something on the old product. So that means that you will not only be speaking to developers that are all about the latest fancy technology and so on. Same for insight. Internal issues, you have people that come from lot of various backgrounds, and you have to prove them, and developer relations is not just about having fun, traveling around, speaking in conference, not doing any actual work. Get ready for that kind of comments, but walk your way internally as well, prove the interest of that as soon as you're able to prove your sales team that you are the one building their bonus for the next year, They may be more interested in what you do, in helping you on your feedback loop because you have to work closely both with sales, marketing, communication, engineering.

Speaker 1: I think everybody's saying that since that morning, the DevRel activities, neither marketing, neither engineering, neither whatever, but it's a mix of all of that depending one way to one day to the other. So the hard part is that it doesn't add any value. We all know that it's hard to measure to have relevant KPIs about the efficiency of what we do in developer relations. But if you mess up the developer experience, the fact is that you will lose customers even before you knew they were prospects because every major company starts by doing a prototype with a small team of engineers working, trying to order an evaluation board online. If it works within a couple of hours, you'll get a phone call after that, and it will be pretty easy for your sales team.

Speaker 1: If it doesn't work, if they had to spend weeks to just get the stuff working, you'll have a hard time making that happen afterwards. I'm pretty good on the timing. Usually, speak way too much. I'm pretty happy of me today. So if it was too long anyway, I had a plan b about trying to push that in a couple of slides.

Speaker 1: So the main one, as I said, don't be blind by the two days issue. That's not what is relevant for your overall activity. Take the time to work on what is strategic and what is not. Maybe one of your users is very vocal, but that doesn't make him the more relevant. Sometimes the user that you don't hear about is the important one because if you don't hear about him or her, it's because they just quit because the experience was terrible, and you you you are losing them.

Speaker 1: So getting back in touch, making sure that everything is okay, what is not is a good way to make progress. Simplicity, I told them a lot. The whole thing I think is for the developer experience to be as simple as possible, as minimal, let's say, that people don't even notice it, but they forget about your service, about the way they get started with that, and that it's just useful to the overall thing they are building. Yes. One important, I just added it this morning, it's about helping your ecosystem, especially the kind of stuff we are doing at Sigfox, is that you are not alone.

Speaker 1: As I said, IoT covers a wide range of activities, You cannot do it yourself. You have to have good partners in the hardware part, cloud platforms, service applications. Treat them well, work together so everybody could help each other improving the overall experience. This one is an example of something that was published this morning by one of our partner. We did a demo at whatever event, I don't know.

Speaker 1: So he's using Sigfox, but it's just only a part of the equation. He's using Sigfox as one of the bricks of his system, which has a washing machine, so some nasty hardware, the IBM solutions. You may guess that's someone from IBM. So it's only a brick of it. So help your ecosystem, work with them, don't pretend you will change the world alone.

Speaker 1: You need others to work with you to make it, working. Online, as I said, online is key. You cannot be in every event in the world speaking to developers in Australia and The US and South Africa and whatever with two people, but it will be key once people start to get a basic understanding about what IoT is about. We are getting there, slowly, but we are getting there. As I said, as an intro, we need to get rid maybe of the buzzword itself, IoT, so people can think about what it's actually about.

Speaker 1: Online is good. Nobody wants to speak to people. You just want to get the information available online when you need it. You don't want to spend time saying the same thing again and again. So focus on that.

Speaker 1: That's what we are doing now. Don't be too harsh if you have a look at portal. We're working slowly, but we are working. And build trust. Again, the most important stuff, your experience, the experience that developers have with your product is here to build trust for them to be maybe the customers of tomorrow or at least not the one that will make you lose customers because they will tell around that your product is either shitty or very complex to use.

Speaker 1: It must be simple and trustable. Thank you.