DevRel Adoption Funnel

I often use a marketing funnel when deciding on DevRel activities. If you’re not familiar with it, this is what a simple, pretty traditional marketing funnel looks like:

The concept of this funnel is that you want people to take action (buy your product), but in order to do that they must first want your product. And they can’t desire the product without first having an interest in it. And to gain an interest in something they must first be aware of it.

The theory goes that you help people progress towards the desired action, one step at a time. At each step you’ll see both conversions (people who advance) and drop-off (people who don’t) - and the value of a user increases at every step.

The funnel is a great tool because it visualizes the progress, and helps you to think of what specific action you can take at each step.

When I ran the Firebase events program at Google, we added some additional phases and flipped the funnel to be horizontal, so it was easier to use in docs and presentations.

The exact number of steps in the funnel and their labels don’t matter all that much in my experience. What does matter is that you understand the journey your (potential) users take, and how you can best help them at each step (and get them to convert to the next step in the funnel).

For example, when considering having a presence at a specific event, what do you want to accomplish there? When I started working on Firebase it was pretty well-known already in the Angular community, thanks to some successful demos at ng-conf. But Firebase was hardly known in the Android and iOS communities at the time. So with the funnel in mind, we set different goals for these events:

• ng-conf: primarily reconnect with existing users (Support) and fans (Love), while also trying to convince more non-users to become active (Desire→Activate)
• AnDevCon¹: primarily raise awareness of Firebase among Android developers (Awareness), hopefully also growing excitement (Interest), and maybe get some to try it out (Desire→Activate).

These different goals led us to choose different activities at each event.

• To raise awareness it really helped to have our name on the signage of the event.
• To create interest, we’d try to make quick connections with folks, e.g. a booth with simple, joyful swag (or unusual swag: like Firebase hot sauce) or a coffee machine.
• To raise people’s interest further, it was great to have a (non-sponsored) talk on the schedule, where someone from our team would show a demo of building something with Firebase.
• Activating folks can be done at the conference in a workshop. That was always somewhat limited in capacity though (and very expensive), so we’d also bring discount coupons for folks as a reminder to take home and try it out there.
• To support our existing users, we’d want a booth where we’d have enough space to open a few laptops and troubleshoot things.

Over time this process turned into our so-called events activity map:

This was a handy table we’d consult for every event we were considering to map our goals to activities we could put on there.

Later we started expanding this activity map/matrix to also include non-event related activities.

An activity map is equally suited for non-event activities, but we ran out of steam quickly; it turns out there’s an almost infinite number of useful activities you can do. For us it was more important to use the model than to have an exhaustive list of activities and a complete map.

For another way of looking at DevRel’s work and how an (even incomplete) visual model can be useful to share with stakeholders, I recommend Timothy Jordan’s DevRel Lifecycle.