How to create actionable developer personas

I was never a fan of that classic user persona profile, especially when thinking about developers. The one with user hobbies, age, city, marital status, and a stock photo. 

Couldn’t connect how is that going to help you sell your open-source geolocation API or an observability platform?  

The developer persona profile needs to be actionable for things like content creation, devrel activities, paid campaigns, product prioritization, sales outreach, and more.  

And if it just looks nice in the slide deck but doesn’t really help you market, or sell your dev tool why bother creating it? 

As a startup marketer, I feel like we cannot afford to build things we won’t use so I have a strong bias for making things actionable. Developer persona profile included.

In this article I’ll share what I found valuable on this, specifically:

• Developer (user) persona vs Buyer persona vs Ideal Customer Profile
• Developer audience segmentation canvas
• Jobs to be done and developer personas
• Developer (user) persona masterclass from GitLab
• Where is your developer audience?
• Framework for building actionable developer personas

Let’s do it. 

Developer (user) persona vs Buyer persona vs Ideal Customer Profile

I see people talk about developer (user) persona, buyer persona, and ideal customer profile interchangeably. In my mind those are different concepts.
Talking is maybe one thing, but if you think about them this way it could be a costly mistake. 

When you consider a typical dev tool go-to-market-motion you have:

• Companies that ultimately buy your product
• Buyers who sign off on that purchase
• Developers who actually use your product. 

And companies, buyers, and users are usually not the same. 

I mean, there are special situations when they are practically the same. Early-stage startups where the technical founder is the company, buyer, and user persona in one. 

Or super engineer-first startups (like Stripe in the early days) where to a large extent if you solve the engineering problem for the user they will buy.

Marketing to an enterprise developer persona is more complex. Should you treat them as just users who only care about technical features, budget holders who only care about benefits and risk management, influencers in the buying commitee,? Or is that developer persona actually a team if you have a team-only product?

The more upmarket and enterprise you go the more those concepts diverge. And the more important it is to treat user persona, buyer persona and ideal customer profile as 3 completely different but related things.

Ideal customer profile (ICP)

This is the company, the “logo” that buys your product. 

You identify the ICP by:

• The size of the company
• The stage of the company (series A, B, C)
• The vertical they are in (banking, healthcare, automotive)
• Whether a particular department exists  
• Whether they have X number of engineers
• Whether they recently merged with another company 
• Whether their org is exclusively on Azure, Google or AWS. 

Things like that. External, high-level things. 

Buyer persona

This is a person that signs off on the purchase. It could be the team leader of a single team or a VP of engineering, CTO, or even a CFO. Sometimes all of them in some shape or form. 

Good to know who that is because you need to be able to craft your messaging to that persona too. 

And it will be heavily value/risk/ROI-focused. Not feature/benefit-focused like I suggest your developer-facing value proposition to be.

User persona (individual contributor software developer)

This is your end user. The person that will actually get value from your product on a daily basis. 

They understand the tech side of things, you don’t need to (or shouldn’t) speak about decreasing developer attrition or reducing enterprise risks. This is not what they (typically) care about.     

When marketing to the developer audience, this is who you typically think about. 

In this article, I will talk about building that end user, software developer persona. 

But first, let’s segment this dev audience. 

Developer audience segmentation canvas

Targeting the right developer is a must. People skip it and go straight to campaigns. But think about it.

Enterprise Java dev is different than a front-end javascript hobbyist or hardcore C++ optimization expert.

But even if you go narrower like a Python developer doing machine learning.

You can have:

• Python ML engineers who put machine learning models in production,
• Data Scientists who develop those models,
• or full-stack Python devs building websites where those models are deployed.

Also are they senior devs, junior devs, or students who are just getting into the field?

Or maybe they are mostly senior Java devs who have just recently started to learn machine learning and Python?

All of those developer segments are different in:

• technologies they use,
• jargon they know,
• the knowledge they bring,
• places they hang out in,
• product expectations they have.

I like this developer segmentation canvas from Caroline Lewko to clear things up. It divides characteristics by:

• Technology (product-focused)
• User (developer-focused)
• Organization (company-focused)
• Market (vertical&geography)

For me, this is not the full solution to developer persona but it is a great start. Those are persona characteristics that are actionable in one way or the other. 

But the thing that is the most actionable for me in the context of developer personas is the jobs to be done framework. 

Jobs to be done and developer personas

Jobs to be done framework (JBTD) in a nutshell is thinking about users/buyers through the lens of what they want to get done than who they are. 

Think about it, you could have a senior Java developer who wants to connect that payments API or a junior Python dev, or a scrappy early-stage founder working mostly with low-code tools. 

The job is to get payments from your users on your website, really. And your user persona is thinking about how to solve that problem. They are thinking who or what product to hire to solve that problem. 

Once you know that job to be done you can action on it right away with:

• content creation: write a blog “How to add payments API to Webflow site” that explains how to do that and use an “Aside CTA” pattern. 
• product positioning and messaging: make the payments part of your value prop 
• enablement and docs: create tutorials showing how to use your payment API to connect to various website builders and frameworks

The nicest way I saw this codified is this:

“When {Situation} I want to {Action} so that {Goal}”

Typically your product will really solve just a few of these. Especially early stage focus on those few (or even one) core jobs to be done. Make sure that the entire journey from first contact with your content to product messaging to docs is aligned around that job to be done.  

But are jobs to be done completely unrelated to personas? Not exactly. 

Jobs to be done vs personas

So while I do believe that personas are secondary to jobs to be done they are not completely unrelated. And they can still be very useful and actionable. 

For example:

• different developer audience segments will encounter different jobs to be done at different frequencies. Scaling resources up/down will be more important to folks working on high-volume B2C products than that weekend, niche B2B project. 
• you can and should communicate (package) jobs to be done differently depending on the context that the developer has. Senior Java dev knows things that Junior Python dev doesn’t.  
• different developer segments will convert to your paid product at different rates so you want to optimize for that too. 
• some verticals may have regulations that you cannot comply with and it just doesn’t make sense to go after these until you are ready

You could just pack those circumstances into the JBTD {Situation} part but that has its downsides too. 

From my experience, it is so much better to just condition that JTBD on persona.

You can either have related JBTD listed for each persona or even add it to the definition.

“As a {Persona} when {Situation} I want to {Action} so that {Goal}”

But there is one more thing that I like about JBTD framework. Search trigger. 

Jobs to be done trigger

When you try to learn what are the jobs to be done your developer audience has you typically combine:

• insights from support emails and GitHub issues
• partial information from registration questions
• sales and customer success calls
• and user research interviews
• thank you page questions
• yearly user surveys

For JBTD those research interviews can be particularly valuable. Through them, you want to understand that trigger moment. You want to know:

“What was happening in their life that made them start looking”

A good tip when digging for this info is to get that user back to the moment when they signed up for your product then jump to the very first thought of “I need to solve this” and then move slowly forwards filling the gaps all the way to today when they have successfully solved it with your product. 

Let’s take that payment API example. There may have been a million ways in which those different personas started searching for a solution:

• They could have been building a fresh new site for their project on Webflow
• They could have struggled with scaling a legacy payments API that was a part of the bigger platform someone build years ago at their Enterprise org
• They could have hit the limits of the popular open-source payments API they chose 2 years ago for their startup

And then when you say “Ok so what did you do after” you get responses like:

• Started looking for an “alternative to that open-source project” on Google
• I actually found you in one o the Stackoverflow answers when still looking for solutions to errors I encounter around “scaling XYZ workloads”
• Yeah just looked for “Webflow payment integrations” and chose the most popular one

All of these answers are easy to act on which imho is the most important thing. 

So let’s see how one of the best developer-facing companies does it. 

Developer (user) persona masterclass from Gitlab

You may not know but Gitlab has a public handbook that describes what they do. I like to look in there for inspiration. 

Obviously, they are bigger, better, and more mature than most of our dev tool startups. But they show you what good looks like. Your job is to take what is valuable and actionable for you right now. 

Anyhow, Gitlab persona creation handbook is great.

They explain how they build and validate what they think personas are:

They list out things that you want to find for each persona:

• Job Summary - Should include major focus areas and a general description of skills and responsibilities
• Alternative Titles
• Motivations - It's suggested to keep to this format: When [situation], I want [feature] so that I can [task] 
• Frustrations - Frustration should focus on a common blocker to their responsibilities 
• Jobs to be Done (your products can solve)
• (Optional)  Personal Skills & Traits - Positive attributes that give life and empathy to your user persona
• (Optional) Key Tools - Important software that helps the user complete their tasks
• (Optional) Workflows- A series of steps the user will normally take to complete their tasks
• (Optional) Collaborative Teams - Teams in their organization that they may have overlap in responsibilities with or are dependent on in their workflow

And finally, you can look at full examples of such personas:

So is this perfect? 

I don’t think so. It likely works for their GTM motion, their audience, their needs. 

You need to make your own schema that is the most actionable for you. I know I am getting boring with this “actionable” but I mean it. Make it work for you, refine it, use it. 

But there is something that GitLab doesn’t focus on for their personas that I think is super important (especially early stage). 

Where is your developer audience?

Things I mentioned before explain who your developer personas are or what problem they want solving. 

But they don’t talk about where to find them. And I think this is super important as well. 

So I like to add information about 

• where do people hang out online 
• how they research tools
• how do they stay up to date with the tech

But very rarely do people just tell you. You need to combine signals you can get over time to build this picture for each persona. 

How? These are the options I saw work for us or other dev startups:

• Registration question: “How did you find out about us?”
• Last question during user/customer/audience interviews: “By the way where do you hang out online?” “Twitter. Ok, who do you follow?”
• Last question in your yearly user survey: “Where do you hang out online?” If you know something already ask which {Twitter/Linkedin/Youtube/Newsletters} profiles do they follow.
• Google keyword research: “How to do {problem}”, “{alternative product} alternatives”, “Tools for {problem category}”
• Reddit keyword research: “{alternative} reviews”, “how to do {problem}”
• Algolia HN search: “{problem}”, “{alternative}” 

Ok, so let’s put it all together. 

Framework for building actionable developer personas

So this will be a superset of the things you’ll need. I combined those different dimensions and concepts I talked about into a list.

Now it is on you to go from top to button and choose which ones will be actually useful to your:

• sales team outbound motion
• your paid campaigns
• your content strategy
• your devrels community strategy
• your pricing and packaging 
• etc

The earlier stage your dev tool startup is the less of them you’ll need and use. 

So choose the ones that trigger action, drop others. Or make them optional and fill them over time. Remember it is the impact that matters not a slide presentation.  

Ok so here is my list:

• Persona (name it somehow, choose the most common job titles for example)
• Job summary (what do they do, responsibilities, how they measure success)
• Alternative job titles
• Examples (links to LinkedIn profiles etc). You can also add negative personas, people you don’t want to attract, for clarity.
• Jobs to be done
• Skills they have
• Key tools they use
• Triggers to start looking for your product
• Company profile (Size, Vertical, Geography) 
• Team/organization structure
• Pain points and frustrations (with current setup / short term)
• Goals and motivations (think of the long-term things)
• Challenges and roadblocks (think of the long-term things)
• Where do they hang out online (Information sources/channels)

Again, don’t fill all of these. Figure out what you need and start from there. 

What is next

Now go through your customer insights and build your developer persona profile. 

And once you do start acting on it right away. And refine the profile over time as you gain more insights. 

I know what you are going to say: “How do you actually get all that information?” I am working on another post on developer audience research, so hopefully it will help out a little bit.