Taking your developer program to the next level

Over the past 15 years of building developer programs, it wasn’t until my work at RingCentral that it all began to crystalize into a framework that others could easily follow in building their own. Welcome to part 2 of a 3-part series deconstructing the “Developer Pyramid,” a tool to help teams build and improve upon developer programs. As discussed in part 1, the Pyramid has three levels. The first is devoted to your platform’s Learners.

In part two we discuss the second level, which focuses on supporting the Builders on your platform.

Who are Builders?

To support your Builders throughout their journey, let’s take a moment to better understand this persona. What motivates them? What do they need?

Builders have intent

Builders are developers who have made a conscious decision to go off-script, to venture beyond the safety of a getting-started guide, and to make something of their own design. Almost by definition, Builders have intent, and it is the job of your developer program to help these developers in fulfilling that intent. In other words, you want to help them be successful in building something — arguably, anything that utilizes your platform.

Builders are inquiry-driven

A Learner, as discussed in part 1, has a simple goal: gain enough familiarity and knowledge of a platform to enable them to progress to the next level as quickly as possible, or to complete their evaluation of your platform. That is why Learners are the most likely persona to follow a path set out for them.

As a Learner transitions into a Builder, they move away from following a path set for them, and towards a path they forge for themselves, one more closely aligned with their ultimate destination.

Builders, therefore, rely more on search and other forms of inquiry as they begin to piece together a design and ultimately a fully functional product to meet specific goals.

Builders are more social

By and large, Learners are more solitary in that they can and should be able to meet their learning objectives in a self-service manner. Granted, Learners will occasionally reach out to a community to ask a question, but only because they couldn’t find the answer on their own. Strive to anticipate and pre-empt these setbacks so that you minimize a Learner’s need to seek outside help.

The nature of a Builder is one of a pioneer — as they venture willingly into uncharted territory. The problems they are trying to solve are harder, more unique, and thus, their solutions naturally increase in complexity.

Builders, therefore, have a growing need to engage with other developers to collaborate with, share ideas with, and to learn from. What we see, especially in an enterprise context, is that many Builders are part of a team. Depending upon the scale of the project, individual developers may begin building an ad-hoc team of their own. At Roblox, for example, as young developers began building their own games, we saw them reach out to members of the community to pull in talent and skills they lacked themselves. Likewise, individual contributors to open-source projects begin the process of establishing their reputation in the community. In these ways and others, Builders tend to become more and more social, and reliant on others.

The Builder’s journey

Before we discuss what resources to put in place to support Builders, we should understand their journey in order to provide scaffolding around each step they are expected to take. Bear in mind of course that your mileage may vary, as every developer’s journey is different depending upon their experience, background, and needs.

Early Builders

Even though Builders have satisfied their basic needs with regard to learning the fundamentals of your platform, they still have tons of questions. In particular, is the following:

Developers went so far as to try out your platform by building something simple because you succeeded in helping them see your platform’s potential. Now, the rubber needs to meet the road.

Developers will begin searching for specific code samples, tutorials, and content from which they can begin piecing together a solution. Where there are gaps in their knowledge or architecture that they are unable to fill on their own, they will seek support, either from the community or from your support team.

If you observe an increase in this behavior, then it is a key signal that a Learner may be transitioning into Builder. It may also mean that a Learner has hit a wall and they are reaching out for help — either way, this is a key time to engage with the developer to ensure they are adequately supported. Another signal is that the developer has begun working on a second project or application, possibly a proof of concept, or even their final solution. Maybe this means they created a second application or project on your platform, but maybe it means they have begun to edit the configuration of the app they built as a Learner. The key is understanding what actions a developer may take on your platform to signal the forging of their own path.

Builders in development

Having gained confidence in the solution they envision, developers begin the process of building the final product. As a practitioner of developer relations, there is little need to outline the development process here, but bear in mind these questions and challenges developers will inevitably face as you assemble resources to support them:

• How will I authenticate users of my application?
• How will I package, configure, and deploy my application?
• What errors am I likely to encounter?
• How will I monitor my application?
• How will I collect feedback and maintain my application?

Builders taking a product to market

While it is reasonable to conclude that a developer’s primary journey on a platform ends when they finally ship their product, doing so would rob you of your greatest potential to deliver something the developer may actually value more than your API: customers.

Your developer program should, therefore, help them not only build their application but promote it as well. At RingCentral, as do many platforms, we provide a marketplace, an App Gallery, in which developers can list their products. In addition, we operate a number of partner programs to help us identify solutions relevant to our customers, and to help our developers reach them. For example, we provide partners with access to lead generation data from visitors to our App Gallery, we work with developers on co-marketing collateral to help amplify each other’s benefits, and we provide developers with advertising initiatives to harvest demand in the market.

Platforms that help developers acquire customers and revenue will be looked upon and talked about very differently in the market. That is why it is so important that a developer’s journey doesn’t end when they finally ship their application. In many respects, it has only just begun.

Supporting the Builders’ journey

Let’s turn our attention to the various resources and programs you might create to support the developers actively building an application or product for your platform.

Forums

Builders will need a place to ask questions. Forums are great because every question asked there will leave behind an answer that can help future developers. Forums are also a logical and natural place for developer communities to take root because they provide the means for developers to interface with each other, and establish and promote their expertise and status.

When contemplating how best to help developers find answers to their questions, consider the following:

1. An inactive forum may actually be worse than having no forum at all. If your forums receive very few questions, it may have the unintended consequence of making your community seem inactive — turning some developers off. Therefore, consider relying on email-based support at first, or directing developers to a third-party developer Q&A site like Stack Overflow.
2. Who will staff your forums? Everyone yearns for the day when the community begins to answer questions, and not just ask them. Before that day comes, if it ever does, it is crucial that questions never go unanswered. Consider what people from your team will be responsible for supervising your forums, and answering questions community members do not.
3. How can your support team make knowledge base articles a more natural by-product of their work? Support agents answer questions all day long, but many of their answers are provided privately. Making those answers discoverable to search engines will go a long way to help you scale your support operation.

Personalized support

Builders are going to hit walls, and when they do, their instinct will be to turn to you for support. Unfortunately, not every question they have can be answered by the community or already has an answer published online somewhere. The fact of the matter is that the need to provide developers with personalized and private support is inevitable.

Therefore, hire a capable developer support team early. In the early phases of your program, they will be the backbone of your outbound support initiatives and will work to ensure developers seeking help will find answers. As your program grows, they will assist strategic partners with bringing products to market, they will publish content to help deflect support inquiries, and they can help your engineering team by being a source of early feedback on new features and platform capabilities.

High-touch support is difficult and expensive to scale. So it is essential to build a strong discipline on the team to document and share everything they learn that could be used by future developers.

Tutorials and how-tos

The success and scalability of your developer program will correspond closely to your ability to help developers to help themselves. To do that, the top three things to focus on are content, content, and content.

Almost every interaction with a developer creates an opportunity for new content. We have already discussed how forums and a culture of creating knowledgebase articles can help deflect developer questions away from the support team. However one cannot rely exclusively on this ad-hoc and reactive documentation process.

Balance your content initiatives with an editorial process that supports developers throughout their entire development process, and not just on the usage of your core platform offering. Do your best to anticipate their needs with content and sample code that many developers will have a common need for that goes beyond answering questions about how to leverage a particular feature. For example:

• Authentication and authorization
• CI/CD integration
• Webhooks
• Debugging and troubleshooting
• Monitoring and quality control

Tools

As your program matures, and as your library of content is fleshed out, turn your sights to developing tools to help your Builders increase their visibility into their application running on your platform. Create tools that support them throughout their entire journey, from building, testing, and ultimately the acquisition and support of users/customers. Here are some tools you may consider building along the way:

• SDKs. Identify common design patterns and make implementing them easier.
• Analytics. Give the developer insight into the API calls being made by the product, highlight potential problems (errors, high latency, low throughout, etc. )
• Token management. Help developers generate tokens to make calling the API easier. Give them a way of revoking access tokens in use by customers.
• Real-time activity stream. Help them troubleshoot their development or a customer’s use of the product with a real-time view of API calls generated by their application.
• Error console. Give developers visibility into the errors (requests and responses) generated by their application.

Laying the groundwork for future advocates

Having a robust ecosystem of Builders should be the goal of every developer program. However, every Builder has the potential to become something more, something even more valuable to a platform: they can become an advocate.

Advocates are what help platforms scale. They drive platform growth and mindshare faster and more efficiently than all of your marketing resources combined. So strive to create experiences that resonate with Builders in such a way that they are inspired not only to build something but also stand up in front of a room full of developers to tell them that they should build something on your platform too.

Up next

In the third and final article in this series, we will finish our climb to the top of the Developer Pyramid, where we will discuss the role of advocates in your platform, and the kinds of support, services, and programs that will help cultivate them.