In this article we will explore how developer marketing techniques can help engagement and improve DX along the downstream developer journey; and how this can generate a viral loop — i.e. the process in which your acquired users turn into API advocates and then in turn help drive adoption of your APIs.
Viral loop steps
The viral loop is a start-up community and e-commerce concept. Simplified, it includes the following steps:
- New people start to use a product,
- some of them recommend this product to their peers,
- even more people start to use your product (= the step that makes the viral loop happen).
In a viral loop users drive adoption, which results in viral growth of your product. If your viral coefficient is higher than one, you will have free growth.
All 4 developer experience domains – user acquisition, conversion, retention, and engagement – play a major role in the 3 stages of this viral loop. User engagement is about inspiring your developers, and captivating them to become an involved user. In other words: user engagement is crucial to trigger a viral loop on your developer portal.
Intrinsic and extrinsic motivation
To engage users you need to trigger their motivation to work with/around your product. Psychologists make a distinction between intrinsic and extrinsic motivation.
“While intrinsic motivation refers to doing something because it is inherently interesting or enjoyable, extrinsic motivation refers to doing something because it leads to a separable outcome. Common extrinsic motivations are rewards (e.g. money or grades).” (Wikipedia)
It is important that you take care of both motivation types to be able to involve all of your users: developers can have different reasons for using your product (think work or hobby) and can enjoy their work differently.
How can you motivate your users in practice?
Developer marketing practices
Developers hate marketing, traditional marketing lingo that is. But marketing practices that take the developer approach (e.g. avoid hollow words, include solutions that help users to advance with the tasks at hand) can indeed have a positive effect on your users. Furthermore, developer marketing practices can help to improve the overall developer experience.
How can developer marketing motivate users both intrinsically and extrinsically?
The role of the user journey in the viral loop
The developers that use your APIs are a heterogenous group of users. Developers can start working with your API for different reasons (e.g. programming for work, programming as a hobby), they can have various skills (e.g. preference for specific programming languages, frameworks, and libraries), and have different background knowledge (think users with a wide range of experience levels). Furthermore, their learning strategy — when diving into the API — can differ (code-oriented and concept-oriented learners each tend to look for different resources). A great developer portal answers all possible individual expectations. To do that, it is important that you captivate your users along their developer journey and its stages (the moments between meeting something for the first time and reaching an end goal).
The following is an overview of the main questions that consumer developers will want to find an answer to along the developer journey stages:
To enable a viral loop and drive adoption, it is important to:
- Draw the attention of your developers along the whole developer journey,
- allow developers to enter at any stage of the developer journey, and
- make sure developers can advance smoothly towards the next stage in the developer journey.
Make it easy and worth it for developers to mobilize their peers and drive more people to visit your portal and use your APIs. Praising something to your peers is a risk you take with their opinion of you. Trust and an excellent experience are prerequisites to recommending something.
What developer marketing practices can help to inspire your users along their journey?
Developer marketing practices along the developer journey
Stage 1. Discover & Research
A great developer portal landing page serves all possible user expectations and allows quick and easy navigation throughout its content. The landing page offers the possibility to enter at any stage of the developer journey (e.g. depending on previous experience or learning approaches), and its structure allows to direct or redirect users. Its focus can differ based on the organization’s strategic business goals and user needs, with e.g. an emphasis on products, services, user types, documentation types, thematic areas etc.
Other practices at the discover & research stage
In the discover & research phase it is important to show you have solutions for specific problems and to allow users to get familiar with what the API is capable of.
Use cases can reflect the API’s purpose and showcase interesting implementations. They can help developers to decide if the given API can provide a good solution for their task at hand.
While a search function might be used to hide poor navigation, it can also help to get a very specific morsel of information fast.
Another solution to immerse users is to target specific niches of the audience directly, for example:
- a wide range of programming languages to start implementing with,
- a regional focus where one can choose documentation in their mother tongue.
Stage 2. Evaluate
You already introduced the possibilities you offer, so now visiting developers will want to test your products or know more about specific solutions. Reduce barriers to engage users to get to know the API, include e.g.
- mock APIs,
- a test account,
- try it out (playground) sections,
- a sandbox environment to test the API without having to reveal personal data. (Sandboxes are essential on developer portals that deal with financial information.)
If you need registration and API key/token provisioning, make it as fast and easy as possible. You could include a timeline and/or a nice visual rundown of the whole authentication/authorization process.
Stage 3. Get started
An uncomplicated onboarding process that makes product testing painless will make it more enticing for developers to actually get started with your API. Once the dev's (preliminary) decision is made to use the very API, we need to move towards solving the user-specific case. Some developers will jump straight to the hardcore references, but others will need more contextual information and inspiration.
Well-structured onboarding tutorials, worked examples, how-to and quickstart guides and conceptual documentation (explaining the domain-specific vocabulary) can show how to start implementing.
Make it easy for users to suggest changes in the documentation. This will improve your docs and even increase engagement, since any contribution, no matter how small can result in further affinity for your APIs through a feeling of ownership and a drive for internal consistency. Think of the IKEA-effect.
SDKs (Software Development Kits) are a good way to jumpstart, especially when you concentrate on distinct key communities and explain how to use the API inside of their unique niches and ecosystems.
Community SDKs, created by external developers are to be celebrated and embraced. It is a sign of your care and involvement with your own users if you publish and monitor their SDKs on your portal. This practice can also keep you on track with what is being recommended by search engines to your new users.
Stage 4. Develop & Troubleshoot
Once the developers get to code and implement your amazing API into their creation, it is imperative not to leave them alone: give all the opportunities you can think of for a fallback on community. The hive mind is always smarter, and there is almost no way your company can think of all the possible niche questions and implementations that may arise.
- Provide a community section or forum and third-party community pages (like GitHub) where developers can communicate with peers and solve problems.
- Have open-source projects that users can take part in.
- Enable other communication tools: you can organize meetups, provide a Slack channel to discuss specific cases.
- Ask for feedback, e.g. on FAQ pages and Knowledge Base pages, encourage edit suggestions if you can.
- Provide the reference documentation with a section where users can leave comments.
- To make users enthusiastic about coding around your APIs, you could organize hackathons or online coding competitions.
Stage 5. Celebrate
Celebration is key in the process to engage users and help them become your developer portal advocates.
Give developers a reason to share and recommend your API. We already mentioned Twilio, where users with interesting API integrations receive attention. But also think about non-technical ways you could help developers succeed.
Another way to help implementations gain visibility is to ask for a guest blog posts — if you have a blog.
Make a virtue out of necessity: if you need to enlist outsiders to make your documentation better or more specific, you could entice your active developer users to contribute (e.g. by paying them).
Stage 6. Maintain
Make it clear what a developer will need to do to maintain an API implementation. Release notes and/or a status page is the least you can do, and any critical changes will have to reach your users asap. Encourage users with different goals by providing different versions of the same information (e.g. detail vs overview).
Motivate, Engage, Involve
When necessary documentation parts are missing or difficult to find then even your most galvanized users will have a hard time implementing and they get frustrated. Think about a combination of developer marketing techniques that both fit your organization’s strategic goals and address your primary stakeholders well.
Pronovix organizes information architecture & UX/DX workshops. Contact us for more details!
Developer Portal: Strategy Series, Part 1 Through this series of posts we aim to provide you with strategies for raising the standards of both internal or external developer portals.Read more
This post was co-written by Kristof Van Tomme, who recently talked about developer experience in relation to documentation at the Write the Docs meetup in Amsterdam. Read more: When docs become DX. Many thanks to Laura Vass for the editing!