The Marketing Funnel Applied to Developer Audiences

The Marketing Funnel Applied to Developer Audiences — 7 minute read

Let us take a look at how DevRel interacts with developers, and how this differs from product marketing approaches. We shall begin with a term most marketers are familiar with - the funnel. We build on that concept to understand the developer journey. We will then discuss the importance of maximising the effectiveness of developer journeys and explore tactics for improving them!

The Marketing Funnel

The funnel is a mainstay of marketing practice. It was forged in the world of advertising, and has been around since 1898. It is intertwined with sales techniques such as the Awareness-Interest-Desire-Action model. Suffice to say it is a classic and continues to be relevant in today’s marketing practice, over 100 years later!

Image source: Marketing Funnel - SproutSocial

The basic idea is that this provides a mental model for marketers. It helps to visualise a customer going through stages of their journey with your brand. You can approximate potential customers as “top of funnel”; with existing customers as “bottom of funnel”.

Image source: The Marketing Funnel - Ahrefs

This allows us to plan marketing tactics. Different sets of tactics at each stage of a customer journey. By defining these stages, we can measure the conversion rate of customers. This is the fraction of customers at each stage who move on to the next stage. If that fraction is too low, then that stage of the funnel is considered leaky. This indicates that the marketing tactics employed at that stage need to be changed. Or perhaps even that the marketing strategy as a whole needs an overhaul.

This context is important for understanding the developer journey.

The Developer Journey

When developers interact with your platform, they will encounter it in different places. They will experience it in different ways. These are developer touchpoints.

For example, they might search for “How to ${SOME_TASK} using ${SOME_TECHNOLOGY}” on Google. From there, they might click through one of the search results to a Q&A on Stackoverflow. (Both Google and Stackoverflow are examples of external touchpoints.) They might click through to another search result to an example Github repo. Or click through to your documentation site. (Both your Github repo and your documentation site are examples of internal touchpoints.)

The developer may find the answer they were looking for among one of these touchpoints. If they have found it, they are likely to move to the next step/ touchpoint. If not, more often than not, they will bail.

Image source: Dev Journey Tube Map - DevRel Agency

This sequence of actions is a journey that a developer takes. They do so to figure out how to accomplish a specific task on your platform. DevRel maps all this out by identifying the touchpoints. They work out the flow of how these are connected together. This results in a developer journey for your platform.

Notice that this sequence of actions is not a linear sequence. Rather, it is one that branches, reverses, and sometimes even loops. We immediately see the limits of the funnel based model of understanding a customer journey. It does not properly map to understanding a developer journey. In fact, developer journeys have more in common with a train network than they do with funnels!

Friction Points

The developer journey is not something that you, the DevRel team, can design. It is not fully within the locus of your control. You can only exert direct influence over the internal touchpoints. External touchpoints are usually only indirectly influenceable, or sometimes not influenceable at all. The route individual developers take through these touchpoints is also only indirectly influenceable.

What DevRel can do to improve the developer journey has much to do with friction points. When a developer encounters a particular touchpoint in their journey, what happens next? Do they tend to get frustrated? Do they get stuck there? If so, why? These are friction points. The goal for DevRel is to identify them. Of course, once identified, minimise or remove them. The article on Developer Experience in this series will go into much more detail on this.

The fewer friction points there are, the more efficient the developer journey will be. Recall the concept of the “leaky funnel” described earlier. Too many friction points are analogous to a leaky funnel. Recall from earlier: “If they have found it, they are likely to move to the next step/ touchpoint.” Therefore DevRel’s mission is to minimise or remove friction points. We want to turn every “if” into an “of course” where possible.

Image source: The Core Competencies of Developer Relations - Reto Meier

DevRel can improve the developer journey in another critical way. This has to do with communications, where the DevRel team acts as an information valve. The DevRel team sits sandwiched between two groups. The internal product/ engineering teams and the external developers building on your platform. This is an integral part of discovering and addressing friction points. Doing so improves the developer journey. The valve part of “information valve” refers to filtering and amplifying messages between these groups. Importantly, this valve needs to be bidirectional.

Image source: Developer Relations, Chapter 2, Lewko & Parton

The DevRel team should map out multiple developer journeys. One per targeted developer persona. (Note that developer personas should be discovered or selected prior.) The touchpoints in these developer journeys will likely have significant overlap. However, do note that different developers can experience the same touchpoint differently. Thus the friction points they encounter may be different.

Metrics and Return on Investment

Mapping out developer journeys with your platform has many benefits. One of the main ones is that you can start to measure them. Some potential metrics include:

  • The frequency of encountering friction points
  • The conversion rate of each touchpoint

Simply knowing the values for metrics like these is not particularly useful. They become interesting when we (1) use them to identify which areas need improvement. Then, (2) implement the needed changes. Finally, (3) measure them again. By comparing the before and after values for these metrics, you can quantify the return on investment (ROI). In other words, how much did the developer journey improve? How much resources were needed to effect that improvement?

Be sure to incorporate these metrics into goals planning for the DevRel team.

Image src: Goals Planning for your DevRel Team using OKRs - Brendan Graetz

Wrap Up

The classic marketing funnel is a great lens to understand developers as a first cut. You can use them to understand developer journeys, touchpoints, and friction points. However, funnels only provide a crude approximation of them. Developers interact with a platform in fundamentally different ways compared to consumer products. Thus it is important for marketers to understand the developer journey. Building on this, they should cultivate a different approach to engage with developers.

Product marketing tends to use unidirectional information flows in its activities. DevRel, on the other hand, must be bidirectional. It acts as an information valve between internal developers and external developers. Cultivating that feedback loop is a long-tail effort. It requires an intrinsic understanding of developers’ needs in order to be successful.

Properly designed developer journeys are extremely valuable to a DevRel team. They can be used to redesign or improve how developers experience your platform. Internally, they also provide a stepping stone to measuring the ROI. They quantify how impactful the activities of the DevRel team are. For bonus points, they are a great way to educate up - the executive team, and even the rest of the company - about what DevRel does!

Thanks

Thanks to Bianca Buzea, Tessa Kriessel, and Michiel Mulders for helping formulate and develop the key ideas of this article.

Thanks to Harry Papacharissiou, Owanate Amachree, and Ömer Talip Akalın for their reviews and feedback on this article.