The power of storytelling in developer marketing

The power of storytelling in developer marketing

Gather 'round, and let's tell some stories. I've written posts about what the various functions in developer relations do. I've also written some practical posts about the mechanics of running events, writing go to market plans, writing market requirements documents, and driving sales enablement. And these are all essential components of a strong developer relations program.

But the topic that is most near and dear to my heart is storytelling. The essence of any company or product is the story of why people should care. Stories engage our emotions and grab our attention. They help us remember information and make it more meaningful.

You're not just an integrated development environment, you're a tool for greater communication and collaboration in a world where we've become increasingly isolated from one another. You're not just a super-fast database, you're the foundation of a world made better when access to and understanding of all data is available to everyone. You're not just a new JavaScript framework, you're a way for everyone, from beginner to expert, to make their ideas come to life.

As marketing professionals, we become profoundly more effective when we package our work into stories:

  • Stories help build trust and credibility with developers.
  • They help us differentiate our product from competitors and legacy tools and processes (i.e., the "old way of doing things").
  • And perhaps most importantly, stories help create a sense of community and connection with developers; the notion that when you use a product you're part of something new, something big, something profound.

How storytelling manifests itself in our work

Developer-focused companies, and technical founders, especially, love to lead with product. It's no secret why...it's what is intimately familiar to us. But we live in a very crowded landscape of tools, services, databases, and so on. What is the difference between your product and someone else's? Why should your product matter to me?

Going down the path of solution marketing is a great first step. You start to whittle away at the problem and get to the essence of "so what?" What benefit will customers see?

When my team launched Visual Studio 2005 back in, well, 2005, we weren't just launching a new version of the old tool. We were launching a new way of developing software. The core new functionality of the product was an "Application Lifecycle Management" tool, a term made up by Gartner (probably) that was, basically, "work item tracking and functionality to manage the workflow of a project."

The easy thing to do would have been to launch the product with a new feature. But we wanted to do more and raise the price point, drive rapid upgrades, and 3X already substantial revenue from the product line. Ambitious goals required up-leveling our story.

After traveling the world and visiting with customers, a common theme kept emerging. 2005 was the height of the "offshoring and outsourcing" boom and the start of what we refer to today as "distributed teams." People found it really difficult to stay on top of all the work across timezones, geographies, languages, and cultures.

Thus, when we launched the product, we launched not as a new version of a developer tool, but as a communication and collaboration platform to make creating software easier. "Communicate. Collaborate. Create." was the tagline I came up with, and I rebranded our new higher-end SKU as "Visual Studio Team" (instead of a typically boring Microsoft name, such as, "Visual Studio Enterprise").

In typical Microsoft fashion, some random corporate drone then screwed up my product name and turned it into "Visual Studio Team System" to match what was, at the time, a proliferation of Microsoft "systems": Office System, Windows System, etc. Microsoft, man.

The key to any story is to center it on the customer, not on yourself. Customers don't care about your story. They care about their own: their dreams, their pains, their goals, their desires.

Your story is that you've built a serverless database. Or a JavaScript framework. Or a developer tool.

Their story is that they want to build something quickly. Or be able to embed AI into their products in seconds. Or be faster at their job. Or defend their code from state-sponsored cyberattacks. And so on.

The creation myth: the backstory

Every good story has a backstory. This is the story that isn't necessarily told, but whose presence can be felt everywhere. I like to think of it as the texture of the story and its characters. In branding, this is "the creation myth."

In his phenomenal book, "Primal Branding", Patrick Hanlon describes the creation myth as:

All belief systems come with a story attached. In fact, a brand is often compared to a narrative. How we originated is the foundation of myth; it fulfills an innate human desire to understand how we came to be.

Hanlon, Patrick. Primal Branding. Free Press, 2006.

For startups, this creation myth looks a lot like your early stage pitch deck.

  • What is the problem you're solving and how has it developed over time?
  • Who are you and why are you uniquely suited to solve this problem?
  • Why do you yearn every day for the bulk of your life to solve THIS problem? Why you and why not a different nerd down the street?

These aren't questions customers will ask of you when they go to click "Sign up for free" on your website.

Rather, the answers to these questions are present throughout your company. People who join your company aren't just there for a paycheck, they're there to go on this mission with you. Partners that elect to work with you want to be a part of solving this problem also. And customers innately feel the problem alongside you and believe you are the ones to solve it for them.

Some companies like to write their creation myth in their "About Us" page, and I won't disabuse you of that notion. Go for it. But also make sure that your creation myth is imbued in everyone in your company and even though you won't ever use the exact words in marketing copy, they will still be present in tone and tenor of your entire marketing apparatus.

How to come up with a story for your product

My first rule of thumb is that my product is not the star of the show. The star of the show is the customer and the customer's problems. The product, to borrow a phrase from Hollywood, is the MacGuffin, the object or plot device that is necessary to further the story.

So, the first step in your story is to solicit as much customer feedback as possible. We've all seen television shows or movies that involve a software developer either as a main or supporting character. We are used to scoffing at nearly all on-screen representations of our profession. This is because writers haven't taken the time to immerse themselves in what it means to be a developer, and, as a consequence, their screenplays turn out to be cliches...overwrought representations of what they've read (not what they've seen first-hand) it's like to be a software developer.

However, when you set out to define your story, you will have obtained several interviews worth of customer feedback and defined your ideal customer profile (ICP). This gives you a strong foundation to now lay out the story of your customers:

  • What do your customers want? What does success look like to them? What is the point where they will have a profound sense of accomplishment? (this is your protagonist)

  • What is preventing them from achieving this? What products are failing them? What processes, tools, or culture is keeping them from success? What specific obstacles are in their way? (this is your antagonist and conflict)

    • Is there an industry-wide or global phenomenon that is causing your customer's problem to be even more acute? For example, the push towards remote work and distributed teams means we need better tools for communication and collaboration.

    • Is there a specific problem with their existing tools, processes, or culture that is keeping them from solving the global problem?

  • How does your product specifically address the obstacles? Is there a common theme for what your product does (e.g., "better communication and collaboration")? (the MacGuffin)

    • The language you use should be rooted in the language of your customers. What specific words do your customers use to describe their ideal end state?

    • Use data, statistics, and other information to offer proof that your product does what it says it does.

  • Lastly, the Call to Action: what should customers who exhibit this problem do next to obtain the product?

These questions give you the bones of your story. From here, you need to rely on your own art and creativity.

Tips for using storytelling in your developer marketing

Here are several tips for refining your story and making sure it is told in the most effective way possible:

  • Use data and statistics to support your story and make it more credible and persuasive. Customers don't just "need a scalable database," they need to "store millions of time-stamped records per second for consecutive days, weeks, sometimes even months."
  • Keep your story concise and focused, and avoid overwhelming your audience with too much information.
  • When it comes time to publish your material, consider engaging your audience with interactive elements, such as polls, quizzes, or Q&A sessions.
  • Use visuals, such as images, infographics, or animations, to enhance your story and make it even more appealing.
  • Measure the impact of your storytelling efforts and track key metrics, such as engagement, conversion rates, and customer satisfaction, to improve your strategy over time.

Summary

Great storytelling will help your product cut through the noise. You will immediately root yourself in a sufficiently large customer segment that you understand deeply, and whose problems you solve with a well-designed, well-intentioned product.

Let me know if you need help finding your own developer story. I've done this a thousand times and get tremendous joy out of helping people do it for themselves.