Recently I joined The Things Network to work on the Developer Experience.

The Things Network was founded a little over a year ago and has gained huge momentum since. A slot at SXSW, a Kickstarter that raised twice the goal and most important: already 180 communities world-wide building LoRaWAN networks and use cases.

With the Kickstarter products expected to ship in November, we want to be ready for more developers and remove any obstacle in their way to build and connect amazing things!

Quite the challenge, but the team and community are on it! ?

Where to begin?

I spent my first week exploring what we already had and where we could improve the Developer Experience. On forehand, the plan was to focus on samples, tutorials and other inspiring content for the upcoming products. However, soon I felt that this only makes sense once we have the basic documentation of these products and the existing SDKs in place first.

So, now you know what I’m working on these weeks. ?

The Pyramid

While I was thinking about all this, I wondered what a natural order in the things that make a great developer experience would be. Immediately it made me think of Maslow’s hierarchy of needs. His pyramid has been applied to User Experience and even code. Of course any theoretical model will always be fall short but I wondered if a Developer Experience Pyramid would help set priorities.

So, here’s my go at it:

Why upside down?

As you progress from the fundamental needs (the product) to higher level needs you’ll spend less time on the product and more on stuff around it. And I’m sure we all agree support is pretty much able to take up any time you have left. The upside down pyramid also emphasises a well designed product is critical.

Why separate docs, quick start and other content?

Documentation

With Documentation I mean 1:1 reference of the product’s APIs and usage. Very basic, only changes when the product does and mostly written by engineers or technical writers working closely with them. I’d even argue documentation should be part of each user story, so I kept it close to the product layer.

Quick Start

With Quick Start I mean a guide to take a new developer along the minimal or happy path from zero familiarity with the product to the their first result. I’ve put this right above the Onboarding because onboarding really isn’t done when the user has signed up, but only with the first concrete result.

Content

Other Content won’t tell you anything Documentation, doesn’t but inspires and lowers barriers for developers with various backgrounds. It involves samples and tutorials for common use cases, as well as SDKs and libraries that make it easier to integrate the product with relevant platforms and programming languages.

Why include licensing?

Because it determines how easy it is for developers to try and adopt your product and whether they feel like they get value for their money. Do you have a trial? Is there a free plan for indies or non-profits?

Also whether your product is (in part) open source or not influences the developer experience. After all, with OSS developers can modify and improve the experience to their own needs. It can also make them feel more like a partner and less a customer.

I positioned this layer right above Product & Documentation and before Onboarding because the latter depends on this being decided on before we can move on.

Onboarding

Onboarding starts with your communication. It should attract the right people and set the right perception. There’s no use in pushing as many people into your funnel as you can, if a large sum of them will spill over with a bad experience.

Sign up and setup should be easy and painless. If they have to fill out tons of fields or install dozens of dependencies, developers will have a bad experience before they even touched the product.

Scaling blog & support

The top two layers of the pyramid are also the hardest ones to scale.

Blog

A Developer Blog allows you to surface updates to the product, documentation and content. But this also means that if you don’t have the discipline or time to write new blog posts, it will look as if your product (and community) is dead. So you only want to start doing this when you are sure you can follow through.

By the way, a blog is a great way to provide visibility to your community of developers, which is by far the best way to both use its activity to attract new developers as well as to motivate existing developers to contribute.

Support

Support is the other area that can eat resources like crazy. Depending on your license this layer might need to be moved closer to Product and include paid support or not. Either way, always provide people with great documentation to help themselves.

Community Support via Stack Overflow, Slack and other channels scales with the community, but will still take resources for licensing, moderation as well as motivating.

A FAQ can be a great way to filter out some of the support requests, although it should also translate to product improvements so these questions themselves will become less frequent.

Feedback welcome!

Putting this pyramid together helped me to set priorities in my work for The Things Network, but I’m sure there’s plenty of room for improvement. Let me know what you think!