How to identify your Ideal Customer Profile (ICP), and why that's not good enough

How to identify your Ideal Customer Profile (ICP), and why that's not good enough

Many of the Founders I work with spend day and night obsessing over their Ideal Customer Profile (ICP). The ICP is a deep understanding of who your best current customers are, and, as the logic goes, trying to replicate your success by finding more of those types of customers seems like a great way to grow your business.

But it's also entirely insufficient.

Don't get me wrong. It is very important to identify who your current buyers are and the traits that they all have in common. That is still good insight. But using it as your sole methodology for building a go-to-market strategy will lead you to make many short-term decisions that will be difficult to recover from.

Instead, I like to focus on customer behavior, not customer profiles. Kathy Sierra once famously wrote, "Upgrade your user, not your product. Don’t build better cameras — build better photographers."

The key is understanding what your customers are trying to do and getting insight into why they are doing so. This, more than company size, geography, technology stack, and other quantifiable traits, is the single most important thing you need to uncover about your customers, product, and company.

Bridging understanding between marketing and product

It is critical that companies align their outbound marketing and their product development at nearly every stage of the release cycle. This is something I especially ask Product Marketing to focus on. It's the discipline that needs to get people on the same page and keep them there.

Product Marketing's core artifact is the Market Requirements Doc, within which the vision of the company and the target customer are carefully described. One component of the MRD is the Customer Behavior Map.

Building an effective Customer Behavior Map and socializing it broadly within the product and marketing organizations builds a shared vocabulary and knowledge base to guide most business decisions you will need to make.

The customer behavior map

We seek to understand the specific customer behaviors that drive a need for our product. If we were only to look at customer demographics, we would miss insight into why certain developers are better suited for our product than others, regardless of where they sit in our demographic profile. By looking into customer behaviors, we can get a better understanding of both where to find those customers as well as what product gaps we need to fill in order to delight those customers.

When I look at my initial customer base, I start to divide people into groupings based on the following easily discernible customer traits:

  • Problem. What problem are they trying to solve with our product? Are they looking to address scale issues? Are they finding it too difficult to maintain existing solutions and looking for something easier to use? This is often the easiest thing for your customers to describe to you.
  • Constraints. Developer product selection is often marked by constraints. For example, does it have to be compatible with an existing language, framework, or database?
  • Current approach. What are developers doing today to work around this problem?
  • Alternatives. What are the other products they are considering alongside yours?
  • Competitive analysis. This component isn't strictly part of the Customer Behavior Map, but one aspect of your Market Requirements Document is a side-by-side analysis of you and each of the alternatives to your product.

Now, so far we have addressed topics that are fairly easy to ascertain through rudimentary customer feedback interviews. You should be able to stratify your customers across these dimensions fairly quickly.

This information will also guide pre-selection criteria in your marketing. For example, if your product only works with PostgreSQL, then you can make that clear on your website and enable developers to drop out before wasting their time. You also have some built-in audiences to focus on: PostgreSQL communities and events, developer-focused activities that are friendly to the PostgreSQL community, and so on.

But we still don't have an idea of the behaviors that are driving decision-making. For that, we need to probe deeper:

  • Frequency and severity. How often does this problem occur? When it does occur, is it a show-stopper or an inconvenience? What is the impact to the business of the problem?
  • Evaluation and decision. How is a product to address this problem going to be evaluated? What process will be employed? Will you need to go through a full proof-of-concept phase? If so, what does it look like? Who is the ultimate decision maker, and how difficult is it to convince them to make a product selection?

Now you're beginning to understand some of the core behaviors that will drive a product selection. For example, if the problem isn't really that severe, but occurs frequently, your marketing will likely be at the individual developer, with a message centered around convenience or productivity. Your pricing needs to reflect the fact that a developer is going to make the decision on her own, and either expense it or just pay for it herself in order to get an additional measure of convenience.

On the other hand, if you have a high-severity problem that occurs periodically and threatens to bring down the entire business, you will likely be able to command a high price point, but brace yourself for a longer-lead proof-of-concept phase and the need to sway a decision maker who could be different from the evaluator.

Using the customer behavior map for SKU design

You may find that you have significant overlap between customer segments, but they somehow seem the same. This is where you can begin to stratify your product into different versions, for example a "Freemium" product and a "Professional" product.

For example, you may have a Javascript framework for building visual dashboard components. One segment you've analyzed is developers who are trying to put together a dashboard for their team (the frequency would be "often" and severity would be "pretty low, I'm just trying to make my team more efficient.")

Meanwhile, another segment is also trying to build dashboards, but the problem they're solving is to put a visual veneer on top of their site-wide observability data. In this case, the frequency would also be "often", but the severity would be high since they're expecting to run the entire business off this dashboard.

In this situation, you have a clearcut delineation between developers who are trying to solve a simple, local problem and similar developers who are trying to solve a mission-critical problem. Further, the developers trying to solve the local problem could easily grow into an opportunity to solve a mission-critical problem in a number of ways (the developer could be promoted into a role with higher scope, the developer could network within their company and recommend your product to a different team, the developer could leave for a bigger role at another company, and so on).

The decision to package and position a version of your product as "Freemium" or low cost as well as a different version that is "Professional" may be obvious from the start. However, through building a comprehensive Customer Behavior Map, you will have gained a very good understanding of who the different developers are and how to approach them through your go-to-market plans.

Using the customer behavior map to inform your GTM

Your Customer Behavior Map gives you a really good idea of the following information:

  • Where are your customers most likely to congregate in order to get information about solving their problem?
  • How do your customers describe their problem in their own words?
  • What alternatives do customers seek?
  • How important is the problem, and how frequently does it occur?

This data gives you a wealth of knowledge to inform your Go to Market Plan. You can begin to set realistic OKRs based on the frequency of the problem, how impactful it is, and how widespread it is among developers. You can define an organic growth plan, including the content you need to build in order to drive organic awareness and growth. You can decide on both the message and budget for any paid campaigns you'd like to execute.

Having a good understanding of your customer and the problem they're trying to solve is an essential first step towards realizing the full spectrum of your marketing program.