ICP playbook · Operator diary · 2026

ICP at pre-revenue: building your first B2B SaaS ICP with zero customer data

Every ICP framework on the open web assumes you already have customers. Pull your closed-won list. Cluster on firmographics. Find the pattern. Write it up. That works once you have ten or twenty deals. It does not work when you have zero. This is the hypothesis-driven methodology I run for StackSwap — written, dated, designed to be wrong on the first pass and rewritten after ten conversations.

Why standard ICP frameworks fail at pre-revenue

Every popular ICP framework — Apollo's, Bessemer's, the SaaS Academy templates — assumes you can pull a closed-won list and cluster it. That is a real method when you have one. At zero customers, the same advice tells you to do market research, talk to potential customers, hypothesize. Which is correct, but skips the hard part: how do you turn "hypothesize" into a specific written artifact an SDR could actually run outbound against? That gap is where most pre-revenue ICPs collapse into "B2B SaaS, 50-500 employees, mid-market" — a market label pretending to be an ICP.

The fix is to treat the ICP as a research instrument. Pre-revenue, you are not documenting who buys — you are documenting who you think buys, with enough specificity that the 10 conversations after can teach you whether you are right. Vague ICPs cannot be tested. Specific ICPs can. The whole point of the pre-revenue version is to be specific enough to be wrong.

Hypothesis-driven vs data-driven ICPs

The two methodologies are not in opposition — they are sequential phases of the same artifact. At zero customers, you run a hypothesis ICP. As customers land, the hypothesis updates. By the time you have 30 paying customers clustered around the same profile, your ICP has graduated to data-driven and the hypothesis label comes off.

The 5-step framework for a pre-revenue ICP

Step 1 — Define the problem before the persona

Standard ICP advice starts with a person ("VP Sales at Series B SaaS"). At pre-revenue that is backwards. You do not yet know which persona buys; you only know what problem you solve. Start there. Write one sentence in this exact format: "We help [specific role] do [specific action] so they can [specific outcome]." If you cannot fill in any of those three blanks with a concrete noun, you are not ready to define an ICP — you are still defining the product. Fix that first.

Operator tip: A good problem statement disqualifies on the first read. "We help GTM engineers consolidate their stack so they can cut $50K of waste" excludes consumer, agencies, and enterprises with procurement. "We help SaaS companies grow" excludes nobody — that is the test you want to fail.

Step 2 — Find public proof the problem is acute right now

Without customer data, your proof has to come from the open web. Look for three signals: job postings that explicitly mention your problem (companies hiring to solve it), founder LinkedIn posts complaining about the pain (acute, recent), and funding announcements adjacent to the problem space (cash + permission to act). Each signal is a hypothesis: "this company has the problem right now, and would be willing to talk." Aim for 30-50 companies showing at least one signal each. This is your ICP raw material — not a list to spam, a list to study.

Operator tip: Public signals beat firmographic guesses every time. "Series B B2B SaaS with 50-200 employees" is a guess. "Hired a head of revenue 90 days ago and is hiring two more SDRs while running Outreach and Apollo" is a signal. Build the signal version.

Step 3 — Prototype Tier 1 from the most acute version

From your 30-50 signal companies, pick the 5-8 with the most acute version of the problem. These are not your average customers — they are the extreme case. Prototype Tier 1 around them: what stage, what tooling, what trigger, what role is feeling the pain hardest. The reason to prototype from the extreme is that early in product life, you sell to people who are bleeding. Average customers can wait; bleeding customers cannot. Average customers will close in 9 months; bleeding customers close in 9 days. Build for the bleed.

Operator tip: The "most acute" cut is a strategic choice, not an averaging one. If your prototype is the median of your 30-50 list, you have built a market segment, not an ICP. Push the cut further than feels comfortable — pre-revenue ICPs win by being too narrow, not too broad.

Step 4 — Run 10 conversations against the hypothesis

The ICP is a hypothesis until 10 people validate it. Reach out to people who fit the Tier 1 prototype. Ask, do not pitch. The 5 most useful questions: (a) "When was the last time this problem cost you real money or time?" (b) "What did you try to solve it?" (c) "What stopped working about that solution?" (d) "If we built [your product], who internally would have to approve the purchase?" (e) "What would have to be true for you to switch to a new tool for this?" Notes from these 10 conversations are worth more than any analyst report. The pattern across the 10 is the real ICP.

Operator tip: Do not skip the conversations. Founders convince themselves they "already know" the answer and skip to building. The conversations cost 5 hours over a week and routinely overturn 30% of the prototype ICP — saving months of wrong-target outbound.

Step 5 — Rewrite the ICP based on what you heard (not what you sold)

After 10 conversations, you have signal. Rewrite the ICP. Three things almost always change: (a) the persona narrows — you discover the buyer is not the title you guessed but an adjacent role, (b) the disqualifiers grow — you hear stories that teach you who NOT to chase, and (c) the trigger sharpens — the abstract "they have the problem" becomes "they have the problem within 30 days of [specific event]." Date the doc. Set a re-review date 90 days out, or after every 5 conversations or closed deals, whichever comes first.

Operator tip: The most common rewrite is a tier shift. The customer you thought was Tier 1 turns out to be Tier 2 (good fit but slow to buy), and someone you had not considered becomes Tier 1. That tier shift is the whole point of the 10 conversations — it is the moment the hypothesis stops being a hypothesis.

Three approaches to pre-revenue ICP (and why problem-first wins)

Before settling on the problem-first hypothesis method, three approaches are worth considering. Each has a real case for it. Each has a specific way it fails at pre-revenue:

ApproachStructurePro caseWhy it fails at pre-revenue
Problem-first hypothesis
Chose this
Start from the problem you solve; find 30-50 companies showing public proof of acute pain; validate via 10 conversations.Works without customer data. Forces specificity. The "most acute version" cut filters the addressable market down to the buyers you can actually close in the first 90 days. Every conversation refines the hypothesis instead of confirming a guess.Requires the discipline to run the 10 conversations before scaling outbound. Founders frequently skip them and end up with a confident-sounding ICP that does not survive contact with real prospects.
Title-first persona ("VP Sales at Series B SaaS")Define a persona by title and firmographic; build outbound off that persona; iterate on reply rate.Easy to operationalize. SDR can build a list in Apollo in 20 minutes. Standard B2B SaaS pattern that most ICP templates teach.At pre-revenue, the title-first guess is almost always wrong — the role on the org chart is not always the role with the pain. You spend 90 days outbound-ing the wrong title and learn nothing about who actually buys, because the people who could buy never opened the email.
Vertical-first sweep ("Healthcare SaaS")Define a vertical, get list of all companies in that vertical above N employees, broadcast outbound to the whole list.Maximum addressable market. Easy to message ("we sell to healthcare"). Good if your product has a real regulatory or domain wedge.Vertical alone is too broad to qualify. A 50-person healthcare SaaS startup and a 5,000-person hospital network are both "healthcare" — same vertical, opposite buyers. Vertical works as a layer ON TOP of problem-first; alone it is a market, not an ICP.

Disqualifier discipline — even (especially) at pre-revenue

The single most underrated move in pre-revenue ICP work is the disqualifier list. Most founders skip it because "I cannot afford to refuse customers yet." The opposite is true: at pre-revenue, you cannot afford to chase the wrong ones. Every hour spent on a misfit prospect is an hour not spent finding a fit prospect, and you have a finite number of those hours before runway runs out.

Write 5-10 specific disqualifiers on day one. Make them concrete enough that a sales rep could apply them without thinking. Update them as you learn. A few categories to force yourself to write:

The economic-reality filter at zero customers

Most pre-revenue ICPs skip the economic-reality filter on the assumption that you need customer data to write it. You do not. At pre-revenue, the filter is aspirational — documented as a target, not a fact — but writing it down protects you from closing the wrong deals on the way to Tier 1. Document the targets your Tier 1 customer must hit for the unit economics to work:

Common mistakes at pre-revenue

When to refresh — the data trigger

The pre-revenue ICP is not permanent. Plan the next two refreshes before you ship outbound off the first version:

Related operator reading

FAQ

A guess is a one-time bet on who buys. A hypothesis is a written, specific, testable claim — designed to be wrong, designed to be rewritten. The hypothesis includes the disqualifiers (who we refuse to chase), the trigger (what just changed that made the pain acute), and the persona detail (KPIs, pain points, trigger language). After 10 conversations, the hypothesis either survives, narrows, or pivots. A guess just sits there and rots while your outbound underperforms.

More specific than feels comfortable. The single most common pre-revenue mistake is hedging — "B2B SaaS companies, 50-500 employees" — to avoid excluding a buyer who might exist. That hedge is the problem. The first ICP should disqualify 90% of the market on the first read. If reading your ICP back, anyone could be your customer, the ICP is wrong. Force the cut: stage, employee band, technographic signal, behavioral trigger, role.

Ten gives signal. Twenty gives confidence. The 10 conversations should be with people who actually match your Tier 1 prototype — not friends, not investors, not "anyone who would take a call." If after 10 conversations the same 3 things keep surfacing (same buyer role, same trigger event, same disqualifier story), the hypothesis is validated and you can scale outbound. If 10 conversations produce 10 different answers, your prototype is too broad. Narrow the cut and run another 10.

Yes — as a target, not a fact. Document what your Tier 1 economic profile should look like: CAC payback target, sales cycle target, support burden target, implementation complexity target, expansion potential target. These are hypotheses too, but they cut deals you would otherwise pursue. A "perfect-fit" prospect that requires 9 months of procurement is not Tier 1, even if they look like Tier 1 on paper. Writing the target in advance protects you from closing the wrong deals.

When 10+ paying customers cluster around the same firmographic + technographic + behavioral profile. At that point, you stop running hypothesis-driven ICP and start running cluster-driven ICP — pull your closed-won deals, find what they have in common, and let the data narrow the cut. The transition is gradual: hypothesis-driven through customers 1-10, hybrid through 10-30, cluster-driven from 30 onward. Most early-stage SaaS gets this wrong by switching too early (clustering 4 deals as if they are 40) or too late (running hypothesis ICP at 50 customers when the data is screaming).

Calling it "TBD" or "we will figure it out as we go." That is not an ICP — that is an absence of one. Every outbound email, every demo, every piece of marketing copy gets diluted because nobody knows who it is for. Force the hypothesis. Write the first version. Make it specific enough to be wrong. The seventh version is good — but you have to write the first six to get there.

Yes, and it usually is — but writing it down is what matters. Disqualifiers force the team to make their assumptions explicit. "We do not sell to consumer products companies" is testable. "We focus on B2B" is not. When a disqualifier turns out to be wrong (a great customer comes from a segment you disqualified), the right move is to update the doc with the new evidence, not pretend the original disqualifier never existed. The disqualifier list is a live artifact, not a permanent decree.

ICP is account-level (which companies). Persona is human-level (which people inside those companies). Both are required. A common pre-revenue failure is collapsing them — "VP Sales at Series B SaaS" tries to be both at once and is neither. The right structure: ICP picks the company (firmographic + technographic + behavioral + economic), then persona maps the humans inside (economic buyer, champion, end user, blocker). Outbound copy talks to the persona; account scoring talks to the ICP.

Canonical URL: https://stackswap.ai/icp-pre-revenue-saas