M.K. had momentum. At $680K ARR his conversion rates were well above benchmark. He closed one in four discovery calls. His team could move a deal from first contact to signed in fourteen days. By every internal metric his sales motion was working.
The problem revealed itself in the quarter after close. Churn was running at 22% in the first ninety days. Not because the product was failing. Not because onboarding was broken. Because the buyers he was closing were the wrong buyers at the wrong stage of their problem. He had optimized for velocity. What he had not built was a signal filter.
His ICP document qualified by role, company size, and tech stack. None of those criteria indicated whether the buyer was actively experiencing the problem his product solved — only that they matched the profile of buyers who sometimes experience it. The funnel was admitting browsers and buyers at the same rate. The sales motion could not tell the difference.
His conversion category scored 75. His ICP clarity category scored 25. He was not closing badly. He was closing the wrong buyers at speed.
When M.K. completed the diagnostic he scored 62. Builder Stage. His strongest category was Conversion. His weakest was ICP Clarity by a margin of fifty points. The diagnostic named the problem he had not been able to see because his pipeline was always full and his close rate was always healthy. Both were true. Both were masking the real constraint.
High close rates and short sales cycles were generating a false positive signal that the GTM motion was working. The real constraint was upstream — which buyers were entering the pipeline in the first place. A fast funnel that closes wrong-fit buyers faster is not a functioning GTM motion. It is an accelerated churn engine.
M.K.'s qualification criteria identified buyers who fit the profile of someone who might eventually have the problem. None of it detected buyers who were actively experiencing the problem right now. The gap between those two groups explains the entire churn pattern. Buyers in active pain close and stay. Buyers who match a profile but are not yet in pain close, try the product, and leave when the problem does not feel urgent enough to change behavior around.
Post-close analysis of the churned cohort showed a consistent pattern: every churned client had entered the pipeline through a fit-based trigger. Every retained client had entered through referral, content, or a channel that implicitly filtered for active problem state before the sales conversation began. The funnel was not broken. The entry criteria were wrong.
Signal architecture audit against M.K.'s existing ICP definition. The six-database Notion workspace deployed with the Signal Collection Layer configured around ICP Clarity signals — specifically buyer state indicators: active problem language, competitor frustration signals, and status quo dissatisfaction. The workspace was not replacing M.K.'s tools. It was giving them a common output language for the first time.
First signal pipeline run against M.K.'s exact market. Thirty-four classified signals retrieved. The Language Mirror populated with verbatim buyer language around the specific frustrated state his product addressed. Comparison of that language against M.K.'s actual outreach copy revealed a significant gap — his messaging described a problem his buyers had not yet started articulating publicly. He was writing for a problem they would eventually feel, not for the one they were feeling now.
A parallel account list built using signal-flagged accounts only. Twenty-eight accounts selected not by firmographic match but by detected buyer state — accounts where the signal pipeline had surfaced active problem language in the prior 30 days. First outreach sent using language mined directly from the Language Mirror. No mention of product features. No positioning statement. Only a direct reference to the specific frustration his buyers had expressed in their own words.
"I thought I had a sales problem. I had a signal problem. Those are not the same thing and the fix is completely different."
12 CLIENT CAP. ROME REVIEWS EVERY APPLICATION WITHIN 48 HOURS.