Storytelling seems to be hardwired into the human brain. Thanks to Joseph Campbell and others, we know that a handful of story shapes appear repeatedly across time and cultures.
The story of how a developer comes to choose our software is one of the most important things we can know. From first awareness through to building something with our product, we can structure our developer outreach and marketing according to what a developer needs at each stage.
Customer journey mapping is a core part of traditional marketing and it’s something that we in developer relations can learn from.
When our customers are software developers, the journey differs significantly from that of a disinterested procurement manager or a non-expert consumer.
In fact, the customer journey differs from product to product. However, just as we package events and learning as stories, we can also generalise the developer customer journey.
Let’s say we’re marketing a new plastic for the manufacture of widgets. Our target customer is the procurement manager at a widget factory; we’ll call her Maude.
Maude’s customer journey would have four broad stages:
At each stage, we need to help Maude in different ways. While the details change, the stages are similar when we’re marketing a developer-targeted product.
What’s different is that Maude is responsible for getting the best trade-off between quality and price on a broad-range of products. She isn’t an expert in any one of them.
The balance of information is different when we’re working with developers. Our audience might know more than we do about the type of software we’re promoting and, even if they don’t, they might believe they do.
This is great for us: our audience is smart, engaged and ready to test our claims. It also means that traditional marketing approaches don’t work.
If we’re to map the developer’s journey, it looks something like this:
Now, it might be an architect or a devops professional rather than a developer. The point is, once we understand how people come to choose our product we can then tune our developer relations, developer experience and marketing activity so that it helps answer the needs they have at each stage of that journey.
While we need to provide general support – e.g. we need to build that initial product awareness – we should focus our efforts on potential inflection points. If we know where we’re most likely to lose people, we can provide the right support. So, if we find that we lose people during on-boarding then we can investigate what about the developer experience we need to fix.
The developer’s journey, and your developer relations plan to handle it, is unique to your product and team. So, in a future post we’ll look at how to map your own product’s developer journey and then what you might do at each stage.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?