ICP Scoring for DevTools

Why Defining ICP is Trickier for DevTools

In traditional B2B SaaS, defining an Ideal Customer Profile (ICP) is often straightforward - based on firmographics like geography, company size, and industry.

But for DevTool companies, that’s rarely enough.

DevTools solve deeply technical challenges. And whether a company is a good fit often depends on things like their infrastructure choices, engineering maturity and organisational maturity - not just how big they are or where they’re located.

• A Kubernetes security tool only matters if the company is actually using Kubernetes.
• A data streaming platform is solving a use case which involves processing large volumes of data.
• An MLOps tool makes sense only if the org is actively building and deploying ML models - and doing it at scale.
  

Some DevTools are broad, used by almost any engineering team. But many are highly specific - and if the underlying technical problem doesn't exist in the company, no amount of outbound effort will convert them.

That’s why defining ICP is both critical and complex for DevTool companies.

The most foundational layer of your ICP is the account - the company itself.

Before you look at buyers or practitioners, you need to ask:
Is this the kind of company that should be using our product?

That’s where Account ICP scoring comes in. It helps you move from a broad market map to a prioritized list of companies based on how structurally aligned they are with your product.

Let’s break that down.

Account ICP

For DevTool companies, ICP definition can be quite nuanced and bespoke. It really depends on your product, the problem it solves and the characteristics of companies that benefit the most from your product. While the exact criteria will vary by product, most DevTool teams define account-level ICP using a combination of firmographic and technographic parameters:

• Geography - Are they headquartered in regions you sell to? Most DevTool sales teams prioritize certain geographies due to factors like buyer familiarity, compliance, or support readiness - e.g., North America, Western Europe, or developed parts of APAC.
• Company Size – Does their team size suggest enough scale or complexity to benefit from your product? Many DevTool products are designed for Enterprises, while others are designed for small team to get up and running quickly
• Industry – Are they operating in industry sectors that are likely to face the problems your product solves? For example, e-commerce and fintech companies often need real-time systems like data streaming; traditional manufacturing firms may be more aligned with DevTools that aid digital transformation.
• Technology Stack – Do they already use foundational technologies that your product is built on? Or does the Technical Architecture align with your product? Eg: Are they Cloud native? Do they use Kafka? etc.
• Engineering Team Size and Structure – Does the company have the right engineering team composition to benefit from your product? This is often overlooked but critical. A company with a dedicated DevOps or Platform team will likely have different needs (and evaluation criteria) than one with a small, generalist engineering team. Similarly, an organization with in-house ML talent may approach MLOps tools very differently than one relying on external vendors or consultants.

When scoring ICP Accounts for DevTool companies, it's helpful to think of your market as three concentric rings - each ring representing a different degree of alignment with your product.

Core ICP

Best suited for your product. Meets all or most of the criteria for finding value in your product.

How you define your Core ICP really depends on your product, the problem it solves, and the type of company or engineering team that can benefit from it the most.

Typically, Core ICP is defined using the following parameters:

1. Geographical Location
   This is one of the most common filters. You might choose to focus on specific countries or regions -  depending on where your GTM motion works best or where developer behavior is more aligned.
   
2. Company Size
   While some DevTool companies can sell to 2-person start-ups as well as Fortune 500, company size still plays an important role. Even if your product works across the spectrum, the selling motion will differ. For any specific GTM motion, company size becomes a key dimension to define.
   
3. Industry / Nature of Business
   This is another common filter. While some DevTools are horizontal (e.g., AI Coding assistants like Cursor, Windsurf), many products deliver exponentially more value in certain industries. 

For example:

• Headless e-commerce platforms are most relevant for e-commerce companies
• Self-hosted tools may be more relevant in industries with highly sensitive data or strict compliance (e.g., healthcare, defense)
  

4. Use of Core Technologies
   Many DevTool products are built on or around core technologies. So companies that rely heavily on those technologies are naturally more relevant. 

For example:

• API gateways or lifecycle management tools are only valuable if the company exposes, consumes, or manages public/internal APIs
• Agentic workflow orchestration tools are only relevant if the company is building multi-agent AI systems or experimenting with agent-based LLM workflows in production or advanced prototyping environments.
  

5. Size and Mix of Engineering Team
   This affects how useful or valuable your product is. 

For example:

• Tools that improve engineering collaboration are most relevant in large or distributed teams
• Tools focused on platform or internal tooling work better when there are dedicated DevEx, SRE, or Platform teams in place

Core ICP - This is the segment you need to “own”. These are your most promising accounts -  the ones where product fit is strongest and value is obvious. Your goal should be to win a lion’s share of this group through focused outbound, strong content, and high-quality engagement.

Broader ICP

Outside your Core ICP but still meets some of the criteria for finding value in your product

As the name suggests, this cohort relaxes some of the criteria used to define the Core ICP

The fundamental principle is this:

These companies still find your product valuable - just that they might not check every box as compared to the Core ICP segment.

You might decide to relax certain criteria like:

1. Company Size: Maybe your product is best suited for large enterprises with complex workflows - but if a mid-market company came along with the right setup, you wouldn’t mind taking that deal.

2. Industry:  Perhaps you win 50% of your proposals in Fintech, but you’ve also seen decent traction in sectors like E-commerce or Logistics. Those verticals aren’t your strongest suit - but the product still adds value, and you can sell there with some effort.

Eventually, it’s a business decision - how far outside your sweet spot are you willing to go?

Broader ICP is your “watch and warm” zone - still relevant, but not the bullseye. You’re not optimizing your GTM motion around them - but you don’t want to ignore them either. Because these companies still find value in your product. They may grow into core accounts, validate new GTM experiments, or come through referrals and word of mouth.

How much you invest in this segment depends on your overall GTM strategy and available resources.

Relevant Universe

This is the outer boundary of your ICP - companies that are structurally eligible for your product. Any company outside this is simply not a fit.

Think of it as your maximum addressable market - the widest set of companies you could reasonably serve, even if they’re not ideal customers today.

What gets a company into your universe?

At a minimum, they must meet baseline criteria like:

• Geography (Go-to-Market Alignment): Your product may technically work anywhere, but GTM realities matter. But your focus may be on regions where you can sell, support, and scale effectively today. That typically means areas where you have sales coverage, compliance readiness, or brand awareness. Companies outside this may still be part of your future plans - but are not in your current universe.
  
• Technical Adjacency: If your product is built on top of a foundational technology (e.g., Kubernetes, Kafka), you may think that companies not using that technology are unlikely to benefit and can be excluded. But your universe should also include companies using complementary or competing tools - like Pulsar, Redpanda, or Flink. These may indicate similar problems and openness to switch or expand.
• Org Maturity Trajectory - They may not need your product today - but if the kind of use cases they’re solving (e.g., real-time data processing, AI workloads, multi-cloud infra) suggest they'll grow into it, they still belong in your universe. You’re tracking them for future potential,

Don’t confuse “Relevant Universe” with “sales-ready.” These companies may not be ready to buy - but they’re possible future customers. Anyone outside this group is just not relevant.

Your Account ICP is the foundation of your GTM strategy. Nail this, and everything else - from who you outbound to, to what events you attend - becomes sharper. In the next section, we’ll layer on the buyer and practitioner lenses to complete the full picture.

Example: How Confluent Might Define Its Account ICP

Let’s take Confluent - a company that offers a cloud-native data streaming platform built on Apache Kafka. 

Their product is designed for companies that already use Kafka or manage real-time data at scale, and want better performance, reliability, or operational efficiency.

Here’s how they might define ICP tiers based on that context:

Core ICP

Best suited for Confluent’s product. Meets all or most criteria for finding value.

• Are headquartered in Confluent’s core markets - places where the company already has sales teams, support infrastructure, and can deliver reliably. These are regions where it’s easier to sell, serve, and succeed because Confluent has a strong presence.
  
• Handle high volumes of real-time data - Confluent is designed for companies where data streaming is a core part of how they operate. These are usually mid-to-large organizations dealing with complex systems, fast-moving data, or large teams. It’s not a plug-and-play tool - setup takes time, and the pricing fits companies with the budget and need for a reliable, enterprise-grade solution.
  
• Belong to industries that rely heavily on real-time pipelines - including fintech (fraud detection, transactions), e-commerce (inventory, personalization), telecom (network optimization), and logistics (tracking, ETA prediction). These sectors often face data movement challenges that Confluent directly solves.‍
• Already use Kafka in production at meaningful scale  -  or are actively scaling Kafka usage. These companies are more likely to face growing pains around performance, cost, manageability, and reliability - and are therefore more open to managed or enterprise-grade Kafka solutions.
  

Broader ICP

These companies use Kafka, but don’t match Confluent’s Core ICP on every other dimension - such as scale, team structure, or industry. They might relax parameters like:

• Company Size: These orgs use Kafka in production, but at a smaller scale.
  
• Industry: They operate in sectors where streaming data isn’t yet mission-critical - such as traditional SaaS, e-learning, or smaller e-commerce players - but they still benefit from Confluent’s capabilities.
  
• Geography: While markets with strong cloud adoption would definitely be the Core ICP for Confluent, it is possible that there are companies outside that region which have good cloud adoption and budget

What stays constant is the use of Kafka. These companies are still streaming-first - just not operating at the scale or complexity of Core ICP accounts.

Relevant Universe

This is the outer boundary - companies that are not irrelevant for Confluent’s product.

Confluent's Universe is defined by one minimum criteria:

Use of Kafka or adjacent technologies: Since Confluent is built around Apache Kafka, companies actively using Kafka are obvious fits.

But the universe should also include companies using adjacent or competitive technologies like Redpanda, Apache Pulsar, or Apache Flink.

These tools often indicate similar real-time data needs - and such companies may be open to switching, expanding, or complementing their current stack.

Companies outside this universe - i.e., those with no streaming infrastructure and no relevant data movement problems - are not part of Confluent’s addressable market today.

Buyer ICP

Once you’ve identified the right companies to go after, the next layer is the Buyer ICP - the decision-makers who can approve or influence the purchase of your product. In DevTool sales, this typically means senior engineering leaders responsible for software development, infrastructure, data engineering, AI/ML, security, developer experience and productivity, or technical strategy.

These are the people who hold budgets, prioritize tooling investments, and evaluate long-term fit with company goals.

​​Start with Job Title

Seniority is often inversely proportional to company size.

At smaller companies, the CTO might directly act as the buyer. But as companies grow, the CTO usually steps back from individual tool decisions. Instead, VPs, Directors, or specialized leaders like a Head of DevOps or Head of Platform Engineering often become the key decision-makers.

Also, job titles can be misleading.

Sometimes you'll find very specific titles like “VP of Platform Engineering” - and that’s great. But in many cases, the title might just say “VP Engineering,” even if the person actually owns platform engineering too. If you rely only on titles, you might miss these nuances.

That’s why it’s important to dig deeper - check what this person has worked on, what teams they manage, and whether they align with your product’s area.

Layer on Technical Background

Titles alone don’t guarantee fit. “VP Engineering” is a broad title and could refer to Frontend, Backend, Devops, AI leaders. Consequently they might have little context for your product. That’s why layering in technical background improves precision. You want buyers who are not just senior enough to make the call - but close enough to the problem to care.

Align your filters with your product category. For example:

• If your product is built for Kubernetes-native environments, look for buyers who have led platform or infra teams managing Kubernetes clusters.
• If your product solves for ML infra or MLOps, target leaders who have run data or ML engineering teams - not just generalist VPs.
• If you’re offering a CI/CD or internal tooling solution, prioritize buyers who have experience overseeing developer productivity or DevEx platforms.
  

These context-driven filters help you identify buyers with both decision-making power and technical alignment - the ones most likely to appreciate and champion your product.

Prioritize Based on Company Context

Even if someone fits your Buyer ICP (right title, right background), they only become a priority if they work at the right kind of company. 

Here’s how to think about it:

Buyer ICP + Core ICP Company → Ideal Prospects
These are your bullseye prospects. They have the right seniority, technical background, and sit within companies that are best suited for your product. This is where you double down on outbound, sales-led engagement, and executive conversations. You should aim to build strong relationships, run personalized plays, and move fast when intent appears.

If you don’t already have a list of these people in your pocket… what are you waiting for? 😉

Buyer ICP + Broader ICP Company → Next-best Cohort
These buyers are structurally aligned, but sit in companies that fall just outside your Core ICP. They can still yield valuable conversations. Engage through high-leverage, low-effort channels like webinars, newsletters, community events, or light-touch ABM. They might mature into core accounts, refer you to others, or validate new GTM motions.

Buyer ICP + Relevant Universe → Future Opportunity
These buyers match your persona, but their companies only meet the bare minimum structural criteria. They’re technically eligible, but far from ideal. You won’t prioritize them in your GTM motion today — but might want to build awareness in this cohort. Who knows one of them could switch jobs and join one of your hot accounts :)

Practitioner ICP

After identifying the right companies and buyers, the next step is to define your Practitioner ICP - the developers or engineers who will evaluate or use your product.

This layer is especially critical in DevTool GTM, where developers often do the initial discovery of solutions, lead the evaluation, shape product opinions, and influence buyer decisions.

Here are the criteria for defining Practitioner ICP:

Titles Alone Are Misleading

Job titles don’t always tell the full story. Two developers might both be called “Software Engineer,” but one could be working on core infrastructure while the other focuses on frontend features. Similarly, roles like Architect, Staff Engineer, or Engineering Manager may or may not be involved in evaluating new tools - it depends on how the team is structured.

That’s why it's important to go beyond the title and understand what technologies they actually work with.

Stack Context Is Key

To truly define your Practitioner ICP, layer in what technologies they work with.

It's not just who they are, but what they work on.

Examples:

• If your tool plugs into Kubernetes, look for engineers working with Kubernetes-native tools like Helm, ArgoCD, or Istio.
• If your product integrates with Kafka, prioritize backend or infra engineers building streaming pipelines.
• If you’re solving for MLOps, target practitioners managing model deployment with Airflow, MLflow, or similar tools.

This stack-level filtering becomes especially important when your product solves a very specific technical problem.

How Specific Should You Be?

• Narrow Products → Focused tools (e.g., deployment automation, observability) usually map to specific roles like DevOps Engineers, SREs, or Platform Engineers.
• Broad Products → General-purpose tools (e.g., coding assistants, internal platforms) may appeal to most engineers, and require broader definitions.

Prioritize Based on Company Context

Just like with buyers, practitioners should be prioritized based on the kind of company they’re in.

Even if someone fits your Practitioner ICP - with the right role and tech stack - their importance in your GTM motion depends on how closely their company aligns with your Account ICP.

Here’s how to think about it:

• Practitioner ICP + Core ICP Company →These are your best-fit technical users inside your best-fit companies.They’re the ones most likely to evaluate, use, and champion your product. Your play here should be to build awareness and advocacy, so that when the company has a need, this person can be a champion and bring your tool into the company.
  
• Practitioner ICP + Broader ICP Company → These developers match your persona - but their companies don’t fully align with your core criteria.Still, they’re close enough to find value. Engage them through content, community, or PLG - channels that allow low-effort, scalable discovery and relationship building.‍
• Practitioner ICP + Relevant Universe → These developers match your target persona — but their companies are only marginally relevant. They meet the basic criteria to be in your ICP universe, but don’t align with your product deeply enough to warrant prioritisation today.
  Still, they can play a long-term role in awareness, word-of-mouth, and community traction - especially if you're investing in DevRel or content. You don’t need to engage deeply, but lightweight awareness can be worthwhile depending on your GTM bandwidth.

This ensures your GTM effort stays focused, while still allowing room for long-term brand building.

While your core focus should be practitioners inside target accounts, there’s a case to be made for engaging developers outside your ICP as well. Developers often influence peers, contribute to community discussions, and switch jobs into ICP companies. If you have the bandwidth - through marketing, DevRel, or community efforts - it may be worth seeding awareness more broadly. Just be mindful that this is a long-term investment, and how much you engage should depend on your GTM strategy and available resources.

Summary - ICP Scoring for DevTools

ICP isn’t just about firmographics. For DevTool companies, fit depends on deep technical alignment - the stack they use, the problems they face, and how their teams are structured.

Start with Account ICP – The Foundation

Before thinking about buyers or users, ask: Is this even the kind of company that should be using our product?

Use firmographic + technographic filters:

• Geography – Are they in regions where you sell and support effectively?
• Company Size – Is there enough complexity, scale, and budget?
  Industry – Are they likely to face the problem you solve
• Stack – Do they use the foundational technologies your product builds on (e.g., Kubernetes, Kafka, Terraform)?
• Team Structure – Do they have the right engineering team composition to benefit from your product?

Think in 3 tiers:

• Core ICP: Best suited for your product. Meets all or most of the criteria for finding value in your product. This is the segment you need to “own” through focused outbound, strong content, and high-quality engagement.
• Broader ICP: Outside your Core ICP but still meets some of the criteria for finding value in your product. How much you invest in this segment depends on your overall GTM strategy and available resources.
• Relevant Universe: This is the outer boundary of your ICP - companies that are relevant for your product. You’re not actively pursuing them today.

Then Add the Buyer ICP Layer

These are the decision-makers who influence or approve a purchase.

Start with Job Titles:

Based on company size, identify if the buyer is most likely the  CTO, VPs, Directors or specialized leaders like a Head of DevOps or Head of Platform Engineering.

Then Filter by Technical Background:

• Not all VPs are equal, look for a background that matches your problem space.
  
  • Kubernetes platform? Look for infra/platform experience.
  • MLOps tool? Look for experience leading data/ML engineering teams.
    

Prioritize Based on Company Fit:

• Buyer ICP + Core ICP Company → Ideal Prospects. Prioritize for high-touch GTM plays like personalised outbound, sales led engagement and executive conversations.
• Buyer ICP + Broader ICP Company → Next-best Cohort. Engage through high-leverage, low-effort channels like webinars, newsletters, community events, or light-touch ABM
• Buyer ICP + Relevant Universe → Future Opportunity. You won’t prioritize them in your GTM motion today - but might want to build awareness in this cohort.

Add the Practitioner ICP Layer

These are the engineers who trial, evaluate, and champion your product.

Job Titles Are Misleading
Two developers might both be called “Software Engineer,” but one could be working on core infrastructure while the other focuses on frontend features. 

Stack Context Is Key
Filter for what they actually work on:

• Kubernetes-native? Look for Helm, ArgoCD, Istio usage.
• Kafka pipelines? Target engineers building on Kafka and Confluent.
• ML infra? Look for experience with MLflow, Airflow, etc.
  

Prioritize Based on Company Fit:

• Practitioner ICP + Core ICP Company → Best fit technical users. Build awareness and advocacy, so that when the company has a need, this person can be a champion and bring your tool into the company.
• Practitioner ICP + Broader ICP Company → Next best fit technical users. Engage them through content, community, or PLG - channels that allow low-effort, scalable discovery and relationship building.
• Practitioner ICP + Relevant Universe → Long term opportunity.lightweight awareness depending on your GTM bandwidth.

ICP isn’t a binary -  it’s a spectrum. Use Core, Broader, and Universe tiers to focus effort without leaving out long-term plays.