How DevRel Can Help Define an Ideal Customer Profile (ICP) and User and Buyer Personas
How DevRel Can Help Define an Ideal Customer Profile (ICP) and User and Buyer Personas
The key to a successful DevRel (and business!) strategy is knowing what users you should be engaging with and for what goals
I’ve been advising several developer tooling companies over the summer, and a common challenge has emerged in the opening conversation: they aren’t sure of their ideal customer profile (ICP) or buyer persona.
This is often compounded if the company is attempting to move away from a product-led growth (PLG) motion, or augment their go-to-market motion with product-led sales (PLS), as their user becomes different from the economic buyer. I frequently saw that a change in go-to-market often results in an unhappy compromise on defining a single mashup of the ICP and user and buyer personas (“one persona to rule them all!”)
This lack of clarity benefits no one. However, the DevRel team is in a prime position to help!
Who is responsible for defining the ICP and buyer persona?
In a startup, it would be easy to argue that everyone is responsible for helping to define the ICP alongside establishing overall product market fit (PMF). It’s tempting to think that in later-stage companies, the ICP and buyer persona are defined in isolation by product marketing managers (PMM), marketing/growth teams, or the sales team. However, in my experience, the most successful companies get buy-in for their ICP and personas across the organisation.
It’s also worth mentioning that PMF isn’t a binary thing. Product capabilities change, the underlying ecosystems evolve, and companies often attempt to go up-market (enterprise) or down-market (SMB). When the product and the market change, so do the associated ICP and buyer personas.
The good news in a developer-focused company is that you have often underutilised experts—the DevRel team—that can bridge users and products and keep an eye on the surrounding ecosystem.
I believe that not only should you have an ICP and buyer personas defined and regularly reviewed, but also that the DevRel team should be heavily involved.
What is an Ideal Customer Profile (ICP)?
I like the Hubspot definition of an ideal customer profile:
An ideal customer profile (ICP), commonly referred to as an ideal buyer profile, defines the perfect customer for what your organization solves for. This is a fictitious company that has all of the qualities that would make them the best fit for the solutions you provide.
If implemented correctly, an ICP can help define the problems your company is attempting to solve, align your product capabilities with customers’ needs, and help create a road map.
The key thing with an ICP is that it is defined at the company level.
I was lucky that just before publishing this post, I read the latest edition of Lenny’s newsletter (you are subscribed to Lenny, right?), which contained a fantastic guide to defining initial ICPs.
Lenny observed, “Everyone landed on at least three attributes to describe their ICP”, which anecdotally resonates with my experience (and who am I to argue with Lenny!) However, several companies I’ve recently been chatting with didn’t go into this much detail when I asked about their ICP. They often said things like: “a company that is a Java shop”, “organisations using Kubernetes”, or “anyone trying to be cloud native”.
It’s highly beneficial to spend more time refining these definitions, as this helps with goal setting, general alignment, and prioritization. I’ll share more thoughts on this later.
DevRel and the ICP
As a typical DevRel, understanding the ICP allows me to prioritize and guide both the help I provide to the community and the feedback I provide to the product team.
For example, suppose a user in the community asks for help in a use case that the product hadn’t initially been designed for (quite common when I worked with Ambassador Labs' Telepresence tool), and I figure out that they don’t work for an ICP. In this case, I can take appropriate action and set related priorities with my team. For example:
I can ask the sales team if they have encountered this or a similar use case recently, and if so, trigger a (company-wide) conversation about updating our ICP. Several times at Ambassador Labs, we saw new use cases and potential customer profiles emerge earlier and with more clarity from the community, but we could often validate these with the sales team when we shared and elaborated on the observations.
I can help the user reframe or redefine their problem to something our tools help with and let the marketing team know. The DevRel team can work with marketing to update use case definitions, create more relevant content, or optimize SEO to see if we can capture additional leads using either the original use case or the reframing (which might also trigger an ICP update conversation).
I can also prioritize which users would benefit the most from connecting with our product or product marketing (PMM) team so they can learn from them and help solve their use case.
I also can point the user to a more appropriate tool or solution.
What is a buyer persona?
Quoting the Developer Marketing Alliance (which, I think, borrows from the Hubspot article mentioned above):
Buyer personas are also semi-fictional representations of your ideal customer. But, while ICPs refer to companies, buyer personas are about individuals – they’re also usually more in-depth than ideal customer profiles, as they include elements like motivations, demographics, fears, job title, and more.
Like with ICPs, this approach helps you find and group characteristics and patterns in potential buyers. You can, of course, have multiple buyers (particularly if you have multiple products).
The critical thing with a buyer persona is that it is defined at the individual (person) level.
It should be noted that if you’re not implementing a PLG go-to-market motion—i.e. your company is sales-led or product-led sales-focused—the buyer persona will often differ from your user persona.
DevRel and buyer personas
As a typical DevRel, most of my focus would primarily be working with the user persona, i.e. the developers using our product. I want to know their pain points, background, skills, interests, community interests, etc., as I want to meet them where they are.
However, I would also benefit from understanding the buyer persona, particularly if I want to help my sales colleagues establish their sales pipeline and create content for closing deals.
Knowing which buyers we are targeting also helps prioritise the work in general and the communities we engage with.
How DevRel can help define the ICP and buyer persona
In my opinion, the biggest superpower that DevRel teams have is user empathy. This is the ability to authentically connect with the community, prospects, and customers. You can’t help users unless you understand their context and problems, and you won’t be able to contribute to your organization’s goals effectively if you can’t identify whether a potential buyer falls into your definition of an ICP.
Some of the most significant contributions my teams have made to organizations in the past have been related to defining the user and buyer personas. I’ve done this primarily in two ways.
The first is organizing workshops where we work with managers and leadership across the company to define user and buyer personas.
Running ICP and buyer persona workshops
I like to divide folks into cross-functional teams, seed them each with a different potential user or buyer persona (or our current hypotheses of these), and then use empathy maps to generate what a user says, thinks, does, and feels. The conversations that emerge are typically fascinating!
You can keep it simple by drawing quadrants on a series of whiteboards, brainstorming, and attaching sticky notes:
You can also use the richer Empathy Map Canvas with teams gathered around a printout on a table. My advice is to start simple and then evolve in subsequent iterations.
When the allotted time runs out, each team presents their learning to the whole group. The DevRel team is cross-functional, so they are typically in a great place to facilitate and steer these discussions. If you have members of leadership who are new to the company or don’t appear to understand customers, this is a very useful exercise.
Changing gears, if you already have an ICP and buyer personas defined, a DevRel team can help keep this updated by regularly capturing and sharing the pulse of users and folks in the community and the surrounding ecosystem.
Updating the ICP and buyer persona through listening to the community
In the past, I’ve run regular surveys to see who and what is changing within our community and then shared this with the leadership and broader company. This is a great way to keep your finger on the pulse, and you can incentivize participation with a competition or prizes if needed.
I’ve also set up company-wide Slack channels where my team and I share important ecosystem news, technology shifts, and competitors’ moves.
This can act as a catalyst for triggering conversations about the evolution of the domain in which we're all working.
Developer tooling ICP and buyer persona antipatterns
Here are a couple of antipatterns I have seen when defining ICPs or buyer and user personas within developer tooling companies:
You rely too heavily on your engineers for input into the product.
Don’t get me wrong, I’m all for “drinking your own champagne” (see below—and no one willingly eats dog food, right?). However, many times, the engineers building the tools won’t be representative of the users of the tool. Accordingly, they have very different goals and behaviours.
Oftentimes, your company consists of “1%” system engineer types, but you’re building for the “99%” application developer masses. (This isn’t meant as a derogatory thing for either group. Jean Yang shared how the 1% are the innovators and specialists, and the 99% folks are the ones that get sh*t done.)
If you don’t listen enough to the (99%) community, you often build (1%) power features or configuration options that no one wants or is willing to pay for (or worse, features that confuse and distract the target user).
The ICP, buyer, and user persona are mixed (frequently mashed up into a single ICP definition).
This is particularly common when a company moves away from a PLG motion and isn’t sure how its buyer will change. Lumping all the characteristics of a potential buyer and company into an ICP appears like a good compromise.
However, this leads to incorrect content being created (e.g. architect/solution briefs instead of developer-getting-started guides) or confusion as to why the marketing/sales pipeline is full of folks who will never buy.
The market or ecosystem shifts beneath the company, and the ICP and buyer personas are not updated.
For example, with Hoverfly at SpectoLabs, I witnessed the testing “shift left” phenomena gain momentum. As the year progressed, I noticed that I was chatting more with engineers using our tool, compared with earlier community work focusing on tech leads and CTOs. This forced a rethink of how we engaged with the community and what content we created.
Want to know more about ICPs, buyer personas, and DevRel?
I hope this post has helped to shed some light on how DevRel teams can assist with defining ICPs and buyer personas.
Please comment below and let me know if you want more content on learning in the role of developer relations.
And don’t forget to subscribe! I’m aiming to share a post every two weeks or so.