Ideal Customer Profile | Startup GTM Bible

Once you’ve carved out a promising segment of the market, the next step is to put a face (or rather, a detailed description) to the kind of customer you believe will benefit most from your product and provide the most value to your business. This is your Ideal Customer Profile (ICP) – essentially, a hypothesis of the “perfect fit” customer. An ICP typically describes a company (since in B2B your customer is an organization), but it also includes the key traits of the buyer or user within that company. Think of it as the composite sketch of your dream customer: the kind of company, the people in it, and the circumstances that make them exactly right for what you offer.
According to one definition, an ICP is “a detailed description of the organization that would get the most value from what you’re selling and actually has the budget and authority to buy it.” In other words, it’s not just who needs your solution, but who can buy your solution. Many startups make the mistake of defining the ideal user but not checking if that user’s organization has money or willingness to spend – your ICP must encompass both the need and the viability of a sale.
Your Ideal Customer Profile (ICP) is a concise definition of the companies (or users) that are the best fit for your product and most likely to derive and deliver value (including revenue). In a COSS startup, defining the ICP must take into account both bottom-up adoption and top-down characteristics. Essentially, you’re asking: which organizations and which people in those organizations should we focus on, given our community-led traction?
Start by examining where your project has organically gained traction. Are there clusters in certain industries, company sizes, or use-cases? Often, an open-source tool resonates strongly with a particular tech stack or problem set that is prevalent in a type of company. For instance, an open-source analytics platform like PostHog realized their strongest uptake was among product engineers at high-growth tech companies. They honed in on an ICP: “ambitious, skilled product engineers working on high-craft products at high-growth, engineering-led startups (Series B to IPO, 15-500 employees)”. That is incredibly specific – and that’s a good thing. PostHog identified that these companies had teams that build fast, depend heavily on data, and have money to spend. This ICP definition allowed them to focus their GTM efforts like a laser. By building for the needs of high-performance engineering teams, they attracted more of them, creating a feedback loop that sharpened the product and kept it ahead of more generalist-focused competitors. The lesson: use real community data to zero in on who loves your product most and also stands to benefit enough to pay for it.
An ICP in COSS often combines two axes:

Company Attributes – industry, size, stage, tech stack, compliance needs, etc. e.g., “Tech-forward mid-market companies in fintech with 100-1000 employees that run on cloud-native infrastructure.” These factors relate to whether the company can buy and is likely to have the problem you solve.
User/Team Attributes – which team or role within those companies is your champion. In open source, it’s typically a technical team: developers, DevOps/SRE, data science, etc. E.g., “DevOps teams managing Kubernetes clusters” or “Data platform team at a SaaS company.” This identifies who in the org will adopt the free product and eventually advocate for the purchase.

From those, you craft a narrative: “Our ICP is X type of company, with Y type of technical team, facing Z problem that our open-source solves. They adopt us via the dev community and then convert to paid because they need enterprise capabilities.” If we take the example of an open-core monitoring tool, you might find your ICP is “large fintech companies (500+ employees) with modern cloud infrastructure, where Site Reliability Engineering (SRE) teams need better visibility. They initially use our open-source monitoring, and as they scale, they require multi-cluster federation and enterprise security features (which we sell).”
Crucially, defining the ICP also means defining who is not your ICP, effectively, the negative persona at the account level. In PostHog’s case, they made a deliberate decision not to target “less technical users or non-core teams like marketing”, even though theoretically a product analytics tool could be used by marketers. Why? Because chasing that broader audience would dilute their focus and compromise the product’s appeal to their core engineers. This kind of discipline is vital in a community-led model: just because your free tool can be used by everyone doesn’t mean you should build for or sell to everyone. As Kellogg might put it, strategy is as much about what you won’t do as what you will. Having a crystal-clear picture of your ideal customer prevents the shiny object syndrome of pursuing every user or deal that comes along. It guides product development (which features to prioritize for enterprise version), content and messaging (speak the language of your ICP), and early sales efforts (which inbound users to devote high-touch attention to).
To identify ICP from your community, it can help to map out a few of what we’ll call “exemplar users”. Look at a handful of users who have shown strong interest – maybe they’ve emailed asking for a feature or support contract. What do their companies look like? - Who has been trialing or self-hosting your software in depth? If someone set up a 5-node cluster of your open-source offering, that’s a serious user – find out what their context is. - Use your community forums or Slack to run polls or discussions: e.g., ask “Which best describes your organization?” You might discover 30% of respondents are data engineers at startups, which is gold for ICP insight.
Also leverage external signals. For example, if your GitHub repo has hundreds of stars from users at known companies (you can sometimes tell from email domains or LinkedIn profiles of contributors), make a list of those companies. Use tools like Scarf to track package downloads and IP addresses hitting their docs to see what companies are evaluatin The point is to figure out which companies in your user base are the ones you’d love to have as paying customers down the line.
At first, your ICP may be a hypothesis that evolves, and that’s fine. Early on, you might have a broad ICP that narrows as you get more data. But you should at least start with a hypothesis. For instance, “We suspect our best customers will be mid-size SaaS companies who have outgrown Google Analytics, where the product team wants self-hosted analytics for privacy reasons.” That hypothesis can be validated against your community (do you see such companies using the OSS? Do inbound inquiries match that profile?).
One more thing: COSS startups often have a dual-engagement model—community users vs. enterprise buyers—within the same org. Your ICP definition must capture the link between the two. You are essentially targeting organizations that have the kind of technical users who adopt your tool freely and the willingness to pay for enhanced capabilities. A classic example is HashiCorp’s Terraform: it spread like wildfire among ops engineers (community users) at many companies, but HashiCorp’s paying customers are those companies that needed collaboration, governance, and security features (enterprise value). In HashiCorp’s IPO filings, they even flag the risk of not being able to “convert open source users to paying customers” as a key concern, underscoring how critical that conversion is to the business model.
Thus, your ICP description might be two-tier: the user persona (developer) and the company persona (business). E.g., “Our ICP is enterprise IT organizations (with 1K+ employees, in regulated industries) that have a DevOps platform team actively using Terraform open-source; these are companies likely to pay for collaboration, security and compliance features.” That encapsulates the who (enterprise org), the what (DevOps team using OSS), and the why (need for enterprise features due to regulation/scale). We’ll cover personas in the next chapter, but ensure your ICP definition doesn’t ignore the role of the community champion within the ICP companies. Without an internal champion, no enterprise sale happens in bottom-up models.

What goes into an ICP?

A strong ICP includes firmographic details and more nuanced factors. Here’s a rundown of typical ICP components:

Industry/Vertical: What sector does the company operate in? (e.g., FinTech, manufacturing, higher education). Your product may be built with certain industries in mind.
Company Size: Usually in terms of number of employees, revenue, or customer base. Perhaps your solution is ideal for mid-sized companies (say 100–1000 employees) but not a great fit for tiny startups or giant enterprises – note that in your ICP. Also consider growth stage: “fast-growing tech startups Series A to C” could be an ICP descriptor.
Geography/Location: If relevant, include regions. Maybe your ideal customers are in countries with certain regulations or in urban areas or in English-speaking markets – whatever matters to product adoption (or even go-to-market practicalities like time zones and language).
Budget and Willingness to Pay: This one is crucial but sometimes overlooked. Does the target company typically have budget for a solution like yours? For example, an ICP might specify “companies with at least $X million in annual revenue or that spend $Y on .” One SaaS team discovered that companies under ~$2M annual revenue rarely could afford their $50k enterprise software, “no matter how much they needed it,” so they set a firm ICP criterion around revenue/budget. Including a size or budget threshold in your ICP prevents chasing organizations that will love your demo and then ghost you because the CFO said “no way we can afford this.”
Key Problem/Pain Point: This is the “why” behind the purchase. What burning problem does your ideal customer have that your product uniquely solves? E.g., “struggling with manual data entry between siloed systems,” or “high volume of customer inquiries overwhelming a small support team.” As Kellogg emphasizes, your ICP should include the problem you’re looking to solve for them, not just demographic info. After all, even if two companies look alike on paper, if one doesn’t feel the pain you solve, they’re not truly ideal. Be as specific as possible: “The ideal customer is experiencing and urgently needs a solution.”
Current Solutions/Tech Stack: It can help to define what the ICP is using today instead of your solution. Are they using a clunky legacy system? A patchwork of spreadsheets? Or nothing at all? Including this paints a clearer picture of context. For instance, your ICP might be “companies using Salesforce for CRM but lacking a good data visualization tool” – which implies a smooth entry point for your integration. Deciding at the outset if you focus on customers using specific adjacent systems can be critical; otherwise you risk drowning in integration work for every random platform out there. Some startups explicitly include in ICP: “uses X or Y system” or conversely “not using any modern tool in this category” depending on their strategy.
Decision Maker Role: Who is the primary buyer or champion for your product? Is it the VP of Sales? The Head of IT? The Operations Manager? Kellogg notes an ICP “should include firmographic as well as role (persona) info. Example: VPs of Sales at tech companies between $500M and $2B in revenues.” In other words, define the target company and the target buyer within that company. Many products have a typical buyer job title – call it out in your ICP. It ensures your marketing and sales efforts zero in on the right person.
Other Attributes: Depending on your business, there could be more. For example: regulatory environment (maybe your ideal customers are those in heavily regulated industries, or conversely those with fewer regulations), culture or openness to innovation (e.g., early cloud adopters), specific workflows (e.g., “teams that follow ITIL process”), number of offices (maybe relevant for a communication tool), etc. Essentially, any trait that correlates with a customer being successful with your product should go in the ICP if you can identify it upfront.

Let’s illustrate an ICP with a real example for clarity. In the HubSpot example, the ICP for Zapier was described as “fast-growing companies with 50–500 employees that use 5+ disconnected software tools, have dedicated operations teams, and lose 10+ hours weekly to manual data entry between systems.” Look how specific that is: it’s not just “any business that uses apps.” It’s companies of a certain size (50–500), that are growing (thus likely to encounter scaling pain), with a certain tech complexity (5+ tools that don’t talk to each other), a certain organizational maturity (they have ops teams), and a quantified pain (10+ hours/week wasted). That precision matters because it prevents the team from chasing leads that will never convert or never get full value. If a 5-person startup approaches Zapier, they might use the free plan, but they’re not the ideal customer for the business model – so Zapier’s sales/marketing would deprioritize them in favor of those ICP-fit 200-employee companies drowning in manual tasks.

Crafting Your ICP – Practical Steps

Start with what you know (or strongly hypothesize). For zero-to-one startups, your ICP often starts as an educated guess in the founder’s head. “I imagine our perfect customer is a mid-sized bank, say 200-500 employees, who’s struggling with antiquated data systems and has a compliance officer desperate for improvement.” This hypothesis usually comes from the founder’s prior industry experience or from preliminary customer development interviews. Write down this aspiration clearly – it’s your starting ICP. As Kellogg puts it, in the beginning the ICP is “born in the founder’s head as a hypothesis… an aspiration about who you want to sell to and the problem you’ll solve”. Make sure it includes the elements above (industry, size, problem, etc.). Sharpen it by adding any criteria that you think might matter. Don’t worry if you lack data – use logical reasoning. For example, you might guess that companies under 50 employees won’t buy because they DIY, or that companies over 5000 employees are too bureaucratic to sell to as a startup – whatever your logic, bake it in.
Validate with early data and research. Once you have a hypothesis, pressure-test it. If you have even a handful of early customers or beta users, examine them: do they fit your ICP profile or did you attract a different type? Often, you’ll find some surprises. Say your hypothesis ICP was “mid-sized banks,” but your first 5 customers ended up being credit unions, all smaller than expected. This is a signal – maybe your true ICP is slightly different (or your initial marketing only reached that sub-segment). Use external data too: LinkedIn, Crunchbase, industry reports. If your ICP is “fast-growing tech companies,” go find lists of such companies and see if they indeed have the pain point you assume. Segment by quantifiable criteria: for instance, break down a list of potential customers by revenue, region, etc., and see where interest in your type of solution seems to cluster. If you’re further along and have sales data, analyze your best customers – which attributes correlate with higher deal win rates, larger deal sizes, or better retention? Perhaps you discover that companies using a competitor’s legacy product switch to you more easily, so “using CompetitorX” could be added to ICP.
Define the ideal use case and scenario. Flesh out the “why do they need us” part of ICP. Talk to potential customers in your target segment about their challenges (this doubles as early product validation too). Direct interviews are gold. Ask questions like: What’s your biggest pain in ? How are you handling it today? What would a solution be worth to you? Their answers can confirm if the problem you think is urgent, really is, and whether those companies know it. Sometimes you find your assumed pain point isn’t top-of-mind for them – better to learn that now and adjust your ICP/problem statement or product accordingly. Qualitative research helps refine your ICP beyond stats and into motivations. For example, you might learn that for your target CTO, the issue isn’t lack of analytics, it’s lack of integration – and that nuance becomes part of your ideal scenario (so maybe you shift to target those with integration headaches).
Identify the buying committee. In B2B, rarely does one person unilaterally purchase a solution; there are often multiple stakeholders (the “buying center”). While we’ll delve into individual personas soon, at the ICP level you should note which roles at the company will be involved. An example from NXT Horizon: “In B2B, identify internal decision-makers — e.g., the CFO who prioritizes ROI, the CTO who cares about scalability, the Marketing Lead who wants better conversion”. If your ICP is mid-sized banks, you might list: Head of IT (primary buyer), Compliance Manager (key influencer who feels the pain), CIO (approver). This ensures when you go to market, you know whose radar you need to be on. It also tests your ICP: if you can’t clearly state who would champion and who would sign the check, you might be aiming at the wrong target.
Iterate and refine continuously. Treat the ICP as a living document. After you go to market and start selling, revisit your ICP every quarter or so. Ask: Are our best customers the ones we expected? Do they have common traits we didn’t foresee? Do some of our initial criteria seem less relevant than others? Over time, you should shift from intuition-driven ICP to data-driven ICP. As Kellogg advises, once you have dozens of customers and real metrics, you should analyze which variables correlate with success – maybe smaller customers actually expand faster, or maybe those in a certain sub-industry retain better. Eventually, your ICP can evolve “from an aspiration to a regression,” meaning you statistically determine what makes a customer “ideal”. For example, perhaps you learn via analysis that companies with >500 employees have a 2x higher churn rate in your product; that’s a sign your sweet spot is below 500 for now, so you adjust the ICP to cap size at 500 employees. Or vice versa. The point is, keep ICP updated with reality so it remains a useful guide. One practical tip: reflect ICP criteria in your CRM and track pipeline and revenue by ICP fit tiers (like ring 0,1,2 described earlier). If you find 70% of revenue is coming from outside your defined ICP, something’s off – either your focus is not enforced, or your definition needs updating (or worst case, your sales are chasing anything, which is another problem we cover in pitfalls).

ICP vs. Persona

Before moving on, it’s worth ensuring we differentiate these two, as they are related. The ICP defines the company characteristics of your ideal customer (plus a bit about the key problem and key buyer role). Buyer personas define the individual people and their motivations within those target companies. As one strategist neatly put it, “ICPs tell you which companies to pursue. Buyer personas tell you how to sell to the people inside those companies.” You need both for a focused GTM. A company could fit your ICP perfectly, but you’ll still lose the deal if you target the wrong persona or use messaging that doesn’t resonate with the real buyer. Conversely, you might hook a person’s interest, but if their company is a poor fit (no budget, no need), it’s wasted effort. In fact, the earlier anecdote showed a company with great personas targeted wrong companies, and another with a great ICP but wrong persona messaging. The sweet spot is aligning the right company profile with the right personas.