Mapping how developers choose our software

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.

A traditional 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:

• Awareness and discovery: Maude knows she has a problem and that our product exists.
• Consideration: she evaluates our product as a solution to her problem.
• Conversion: she buys our product.
• Retention and upselling: she becomes a repeat customer, perhaps an advocate for our product and we try to sell her more plastic and other things from our product range.

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.

A software developer’s customer journey

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:

• Initial awareness: the developer knows they have a need and they’re superficially aware of our product.
• Deep awareness: the developer knows the reputation of our product, its broad use cases and some arguments for/against.
• Belief/readiness to try: the developer believes our product might help them solve a problem, plays with it to confirm.
• Commitment: our product is now part of the stack for at least one project that our developer is working on.
• Standardisation: our product becomes the go-to choice for that type of problem, either for a single team or throughout the developer’s organisation.
• Community: the developer, and their organisation, become part of our product’s developer community: advocating for it, contributing back to it and so on.

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.

What to do next

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.

A version of this post originally appeared on the Hoopy blog.