Building Impactful IOT Developer Programs
By Linda Campbell, originally published on LinkedIn, June 2018 (but still true…) :-)
Technology trends such as the Internet of Things, Cloud Computing and Big Data make developers a critical audience to many businesses in industries that haven’t typically had to consider them in the past. These historically non-technology companies are becoming more digitized both internally, as their products and processes evolve, and externally in how they interact with their customers and partners. Walmart, Siemens, Deutsche Bank, John Deere and Itron, a long-time leader in the utilities space, where I work, are just a few examples of such companies. These companies are investing, some for the first time, in programs focused specifically on developer outreach, enablement and support. This article offers some practical advice based on my experience in building successful platform ecosystems.
Who are They?
Developers are at the heart of any technical ecosystem, and the first instinct is to consider them as a homogenous category. As with any successful marketing program, it is key to understand your audience and lumping all developers in one box is impractical. In a technology ecosystem, developers are everywhere. They work for you, for your customers, for your partners, they work at startups and sometimes they work from their garages and coffee shops. They write device drivers, APIs, user interfaces, operating systems, frameworks, cloud apps, desktop apps and mobile apps. Some of them write code that ends up in finished products, others write code that become components or microservices used by other developers. They might use C, C++, C#, Ruby, Java, JavaScript, Active X, or Python. And that’s just software developers. Some are motivated by money, others by status, and some by passion for a cause or affinity to a particular technology. They are not all the same.
You want to know as much as possible about them – who are they? What are they working on now? Who do they work for? What do they care about? Where can you find them? Not only are they all not alike, they are not all equally important to your business. Which developers to target is totally dependent on your business objectives in enabling them in the first place and on the applicability of your technology platform. How specific is it? Can any developer use it or is it only of interest to someone with a very precise problem to solve? Perhaps it’s only relevant to companies in exactly the same business as yours.
The scale of your developer audience also depends on how much you’re willing to invest in your program and what kind of results you’re trying to achieve. It costs money to do a good job of developer enablement and these programs are not always directly tied to revenue which reinforces the need to focus on the developers that matter. Be smart and be frugal about who you enable unless success for your platform depends on broad ubiquitous adoption by developers at large.
Why Should They Care?
It’s a mistake to assume that developers are just waiting for you to engage. A common misperception is that if you make it free and easy to access, then developers will flock to it. And while both price and accessibility have an impact on the success of any developer strategy, they are not enough on their own.
Why would they engage - what’s it in for them? Developers and the companies they work for are not charities, they don’t typically like to work for free. You may be able to get them to look at your platform, but very quickly they want to know how they’ll make money. This means they need a path to commercial product, a quantifiable market, a channel to that market, and appropriate time to market.
For example, when I ran the ecosystem program for QNX CAR, an automotive computing platform, we initially had a lot of interest from mobile app providers, especially after we were acquired by BlackBerry. These mobile app developers either saw the car as a natural extension of their use case or they saw it more generically as an opportunity to expand their addressable market. But once we started discussing time to market and the channel to the ultimate consumer, most of them backed away. At the time, in-vehicle computing was a highly fragmented market, there was no standard application platform. Each car company built their own environment, and sometimes these platforms even varied by vehicle model. There was no single, scalable channel to market, not to the car companies nor their end customers, the consumers.
Finally, the real pain point came with time to market - back then, a design win with an automotive OEM typically meant production two years later, maybe 18 months at best. And these OEMs were serviced by multiple tiers of suppliers who often had responsibility for building the computer systems that got deployed in vehicles. In summary, the path to a quantifiable, commercial market involved supporting multiple application platforms, there was no clear and easy channel to market, and the time to market was greater than a year.
I often hear people referencing the smart phone industry as a template for engaging and enabling developer communities. The benefit in doing so is that it does serve as a common reference point for discussion. However, there are significant differences that need to be considered, like in the automotive example above, that might make it difficult for a developer to ultimately make a good return on their investment supporting a new platform.
Now, How?
So, now that you know your developer audience and you know there is a path to revenue for them, the next step is to consider how you will enable them. You need to do this from four perspectives: technical, operational, commercial and legal. And all are closely interrelated, a decision in one area has impact on the others.
Operationally, the key is to make it easy for developers to engage based on low barriers to entry and minimal friction points. Most developers don’t want to talk to a sales person to get permission to download your APIs. If you ask for a phone number, they’ll likely make one up. They also don’t want to fill out lengthy online forms that read like sales leads (no one does). The key to developer enablement is to make it as low touch as possible, make it easy for them to self-identify and self-serve. The challenge here is that doing this successfully requires an investment of time, people and supporting infrastructure. So, you need to match this investment based on the scale of your program – both the size of the audience and the size of your budget. I’m a big believer in starting small and building up, kind of like doing an MVP (minimum viable product) for your overall program. For example, before making a massive investment in staff, process and infrastructure, you might want to invite a small number of developers to act as advisors – providing insight on overall feasibility and attractiveness from their perspective. Working with an advisory board on an ongoing basis could also help to shape the program and prioritize investments.
From a legal perspective, I am always very impressed by how knowledgeable most developers are about licensing. Click-through agreements are the norm, but you should assume they will be read in detail. And you should describe your commercial model in an FAQ that supports what you outline in the legalese.
There is no magic here except having clarity about what you’re willing to share and on what terms. This sounds easy enough but it’s surprising how confusing this can be. With developer enablement, the goal is always to be as open as possible while protecting your IP and your ability to make money. (Which does require you be crystal clear about where you make money.) Usually when you talk about publishing open APIs for your platform whether its software or hardware driven, the debate centers on the competitive downside as in: what if our competitors copy and implement the same APIs on their platforms? In my opinion, the answer is best captured by the familiar quote, “imitation is the sincerest form of flattery”. Of course, this is very much dependent on your business, your competitors, your platform and more, but again, the goal is to be as open as possible. You might even end up getting credit for establishing a de facto industry standard based on your APIs.
The other thing to keep in mind is that legal agreements can be staged based on where you are in the developer engagement cycle. As a rule, developers want to be able to evaluate and prototype with minimal interaction, but once they’re committed, they’ll want to know what the commercial terms are related to productizing their work. At this point, they’re even willing to talk to a sales person (but only if absolutely necessary).
The technical component of your program is reflective of your platform, but here I want to point out something critical that ties back to the commercial aspects of your engagement. You need to understand the difference between “development” and “deployment”, especially in IOT. You need a clear path from the development project to the deployed product. This is true from a commercial perspective but also a technical one. Are there special considerations for security in a real-world deployment? Are there either internal or industry certifications necessary for deployment? Is the development product intended to stand up to the rigors of harsh in-field environments? Are you truly ready to enable an IoT ecosystem?
In summary, before you launch your IoT developer program, make sure (1) you know exactly who you’re going after and why, (2) there is real value for the developer (time to money matters) and (3) your platform is ready for adoption externally, you’ve thought through enablement from development to deployment and all the various legal, commercial and operational facets in between.
Most importantly, you need to be super clear as an organization on your objectives, why are you doing this and to what end? How will you measure success and secure ongoing funding? In my experience, when budgets get cut, programs aimed at developers and ecosystems are often the first sacrificed to protect customer facing and direct revenue programs. I’m not arguing the prioritization, developers follow opportunities created by a platform. Therefore, customers always come first. But retraction of program benefits or access to technology can damage a company’s reputation. Equally there might be other value derived from your developer community that is harder to measure. An engaged community may be a source of product innovation and validation, as well as early adopters and beta testers. Therefore, it is very important to be thinking about your fallback position (in addition to everything else outlined above), as you start planning your developer program. In doing so, you might be able to design it to survive for the long run in addition to being effective with it now.
