How to read a pipeline number

A playbook went around LinkedIn this week. It is a good one — a detailed diagram of a signal-driven account-based marketing engine, the kind of thing that usually sits behind a consulting invoice. It is free if you comment on the post.

It also opens with this:

We just helped a B2B SaaS generate $1.3M in pipeline in just 4 months with ABM.

We spend our working lives asking people questions and then deciding how much weight their answers can carry. That habit does not switch off when the claim arrives in a feed instead of a transcript. So here is the same read we would give a client who forwarded it to us — not to attack the author, whose framework is genuinely useful, but because the way the number is written is a lesson in itself.

Pipeline is not revenue

This is the whole game, and almost everything else is a footnote to it.

Revenue is money that arrived. It is audited, it is in a bank account, and there is exactly one number.

Pipeline is the total value of deals a company believes it might close. It is self-reported, self-defined, and it lives in a CRM field that anyone with a login can edit. A rep who has a promising call can create an opportunity, type $80,000 into the value box, and pipeline goes up by $80,000. Nothing happened.

So "$1.3M in pipeline" is compatible with an enormous range of outcomes. If a quarter of it closed, that is $325,000 of real money and a genuinely good result. If the normal thing happened and most of it aged out, it is a number in a slide.

The claim does not include a close rate, a realised revenue figure, or how much pipeline that team generated in the four months before the engine. Without a baseline you cannot tell growth from ordinary activity relabelled.

None of this means the result was not real. It means the number as stated is not checkable, and unfalsifiable claims should move your beliefs less than checkable ones. Notice how much more it would cost the author to write "$310,000 in closed revenue." That sentence can be wrong. The pipeline sentence cannot.

One team is an anecdote

The post says: one team ran this engine.

One is a sample size of one. It carries survivorship bias twice over — the case study you see is the one that worked, and the playbook was written after the outcome was known, which lets every decision be narrated as though it were the plan.

We would not publish a finding off a single interview, and we tell clients so when they want to build a roadmap on one enthusiastic customer call. The rule does not change because the subject is a marketing engine rather than a user.

Again: not evidence of failure. Evidence of nothing much, which is a different thing and easy to confuse with a positive result when the number attached is large.

Read the qualification criteria — usually the most honest line in the document

This is the part worth stealing. Buried in the contents list is:

TAM and stakeholder mapping, qualified on ACV above $50K and a TAM under 20,000 companies

That single line is more informative than the headline number, and it is almost certainly true, because it is the kind of detail people include when they are describing how something actually works rather than selling it.

It says: this engine is built for businesses where one customer pays more than $50,000, and where fewer than 20,000 companies on earth could ever buy. Those two conditions are what make the economics work. When a customer is worth $50,000 you can afford to spend hours researching one company. When your total market is 20,000 companies you can afford to map it.

Change either number and the method inverts. At a $5,000 deal size, the research costs more than the customer returns.

So the document tells you who it is for. Most readers will not match, and the headline number gives them no way to notice. When you read a case study, find the conditions under which it held. They are usually stated plainly, in a section nobody reads, because the author is not hiding them — they simply are not the part that sells.

Cost moved is not cost removed

The post opens by objecting that traditional ABM "burns thousands of dollars," and that a full market map starts at $2,000.

It then recommends a stack: Apollo, Sales Navigator, ZoomInfo, Clay, Claygent, RB2B, Warmly, HubSpot, LinkedIn ads, and several more. Priced out, that is comfortably a few thousand dollars a month, before anyone's time.

That is a fair trade for the right company. It is not a saving. The cost moved from an agency invoice to a software subscription plus the hours of whoever wires eleven tools together and keeps them working. Whenever a pitch contrasts an expensive old way with an efficient new way, add up what the new way costs. Sometimes the honest summary is "the same money, spent differently, with more control" — which is a real benefit and does not need the framing.

What is true in it

Worth saying clearly, because a critique that finds nothing good is usually motivated reasoning.

The core thesis is sound. A signal is any data point suggesting someone is moving toward a purchase, and contacting people who show signals beats contacting people who do not. That is not a fad; it is the same reason a warm introduction outperforms a cold email.

The awareness ladder in the diagram — Identified, Aware, Interested, Considering, Selecting — is a legitimate model, and more useful than the binary "lead or not a lead" most teams operate with. The split between first-, second- and third-party signals is a genuinely good way to organise scattered data.

You can adopt every one of those ideas without buying anything. Funding announcements, new product launches, job postings for a first product hire, founders saying out loud that they do not know what their customers want — all public, all free, all signals. The expensive part of that playbook is the automation, and automation is what you need when the list is 20,000 companies. If your list is forty, you are the automation.

The five questions

The general version, which works on any claim in a feed:

1. Is this money that arrived, or money someone hopes will arrive? Revenue or pipeline, closed or forecast, actual or annualised.
2. Compared to what? A number with no baseline cannot show improvement.
3. How many cases? One is a story. Ask what happened to the teams that ran it and are not in the post.
4. Under what conditions did it hold? Find the qualification criteria. Check yourself against them honestly.
5. Who benefits from me believing this? Not disqualifying — everything is published by someone — but it tells you which direction the errors will lean.

None of these require expertise. They require reading the whole document rather than the first line, which is the part most people skip.

Why we bother

We get hired because the same problem shows up inside companies. Someone has a number — a survey result, a competitor's claim, a slide from a vendor, three enthusiastic customer calls — and a decision worth a quarter of engineering time riding on it. The number is rarely wrong on purpose. It is just softer than the weight being put on it.

Our job is to go and find out what is actually true, and to hand back the evidence alongside the conclusion so you can check our reasoning rather than trust it. Which is the same standard we would want applied to us: if we ever publish a number about our own results, hold it to the five questions above.

Take the playbook. It is free and the frameworks are good. Just read past the first line.