River
Y CombinatorBacked by Y Combinator

Product & DesignFree

Product Gaps From Lost Deals and Churn

Every loss reason in your CRM was chosen by the rep who lost the deal, so the product list built from it is wrong.

Start here

River's win-loss review starts from the evidence rather than the reason field. Closed-lost opportunities, churned accounts, call transcripts, support tickets and renewal notes go in. Each outcome is re-attributed from what the buyer actually said, then the product-attributable ones are grouped into named capability gaps with revenue attached. In the worked review, a picklist that recorded 68 of 187 losses as missing features supported 40, and 17 of those 40 had been filed under price, competitor or timing.

Unlike a win-loss report built on the reason field, this one treats that field as a claim to check. Corporate Visions, reading feedback from more than 120,000 B2B deals, found that what sellers log in the CRM differs from buyers' actual reasons 50 to 70 percent of the time. A rep filling that field knows the outcome already, so the reasons that survive are the ones outside their control. Price and missing features are both outside their control, which is why both buckets run hot.

Built for the product manager who has to walk into a roadmap review with a gap list engineering will believe. It is also for the leader deciding whether the answer is a feature, a demo script or a price change. Run it before the prioritization pack scores anything, since the revenue figures it produces are the input. Pair it with the voice of customer review, which covers the customers who stayed rather than the ones who left.

A product manager reviewing lost deal records and call notes across a table
Built for the roadmap review where engineering asks which of these gaps actually cost money.

Three different problems get logged as one

A loss reason field holds one value, filled in once, by the person whose quarter it just cost. HubSpot ships it as a single default deal property, described in its own documentation as the reason the deal was lost, singular. Whatever options that field carries become the entire vocabulary available to the analysis downstream, and a buyer who walked for three reasons arrives in the register as one word. Every count built on it inherits both the compression and the choice of who did the compressing.

The split that makes a gap list credible to engineering has three branches, not one. A capability can be genuinely absent, which is a build. It can exist and never have been shown, which is a demo script and a competitive one-pager. Or it can have been seen and rejected on depth, which is a smaller build in a place nobody was looking. In the worked review those came to 40, 25 and 19 deals. Sending all 84 to engineering as feature requests is how a roadmap fills with work that was never product.

Ranking those gaps by lost pipeline alone still gets the order wrong, because it only counts the revenue you failed to win. Join the gap register to the churn reasons and count each account once. In the worked review, audit-log export ranked second on lost deals at $512K and third on combined exposure at $576K. A Workday time import worth $398K in lost deals carried another $198K in churned accounts, which moved it up past that. Same evidence, different order, and the second order is the one that survives a budget conversation.

How it works

  1. Send the outcomes

    The closed-lost export and the churn list, with whatever revenue figures each of them carries.

  2. Add the evidence

    Call transcripts, rep notes, support tickets and renewal conversations, however partial they are.

  3. Re-attribute each loss

    Every outcome tested against what the buyer said, with the picklist reason kept alongside for comparison.

  4. Read the gap list

    Named capability gaps ranked by combined exposure, each one traceable to the deals behind it.

What you get

  • Every closed-lost deal and churned account re-attributed from the evidence, not from the reason field
  • Product losses split three ways: capability absent, capability never shown, capability rejected on depth
  • A crosstab of what the picklist said against what the evidence supports, deal by deal
  • Named capability gaps with lost pipeline and churned revenue attached, each account counted once
  • The gaps worth closing and the ones to accept, with the quotes behind each verdict
  • An unattributable pile, sized rather than deleted, because its size says what your evidence is worth

Common questions

We do not have buyer interviews. Is the reason field all we have?

No, and it is usually the weakest thing you have. Call recordings, the rep's own notes, the security questionnaire that went unanswered, the ticket a churned account filed twice, and the renewal conversation all carry more detail than a picklist value. Requests that arrive from customers who stayed belong in the feature request triage instead.

How do you tell a real gap from a feature the rep never demoed?

By checking the capability against your own product before writing it down. If the thing exists and the buyer described wanting it, that loss moves to the enablement bucket with the deal named, so somebody can go and look at the recording. In the worked review 25 of 187 losses landed there, worth $1.39 million.

Will this just tell me our reps are lying?

No, and the finding is not about honesty. A rep completes the field after the outcome is known, under time pressure, in a system their manager reads, so the reasons that survive are the defensible ones. That is a property of retrospective self-reporting rather than a property of your team, and the fix is a second source rather than a stricter picklist.

Why bring churn into a lost-deal review?

Because a capability gap that costs new business and existing business is a different investment case from one that only costs new business, and only the join shows it. Counting each account once across both sides reordered the worked review's top four. The feature adoption review covers what happens to a gap after you close it.

What about deals we lost to no decision?

They are kept and reported separately, because they are rarely product. Corporate Visions' buyer feedback puts status quo bias at 32 percent of no-decision outcomes, solution misalignment at 20 percent and sales process gaps at 19 percent. Filing all of those under a missing feature is how a roadmap answers a question nobody asked.

What if half our lost deals have no evidence at all?

Then half the register says so. Anything that cannot be attributed from something a buyer actually said goes into an explicit unattributable bucket with its revenue attached, rather than being assigned to the nearest plausible reason. In the worked review that was 7 deals and $290K, which is small enough to make the rest believable.

How often is this worth running?

Once or twice a year, and always before a planning cycle that will set a roadmap. The register accumulates, so the second run can show which gaps you closed and whether the losses attributed to them stopped. Feed the output into the roadmap pack rather than into a request board, where a revenue-weighted gap loses to whoever votes most.

Product Gaps From Lost Deals and Churn

Fill in the form and your workspace opens with the work already underway.