# Win Loss

> Runs a win/loss analysis across decided deals to find why you actually win and lose, separating stated reasons from real causes. Use when a PM or PMM says "why are we losing deals", "run a win-loss", "analyze these lost deals", "what's killing our close rate", "sales says it's price", or when the same objection keeps surfacing and nobody has checked it against the data.

- Skill: `sidsaladi9/win-loss` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sidsaladi9/win-loss`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sidsaladi9/win-loss/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Sidsaladi9 (https://skillmd.com/u/sidsaladi9)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sidsaladi9/win-loss

---


# Win/Loss Analysis

Turns a pile of decided deals into the two or three things that actually move your close rate — and separates them from the things sales *says* are killing deals. Those are rarely the same list.

**Grounded in:** *The Mom Test* — Rob Fitzpatrick, applied to deals rather than users: a stated reason is an opinion, a behavior is data. Ask what happened, in what order, and what they did instead — never "why didn't you buy?", which reliably returns "price" regardless of the truth. Paired with standard win/loss practice: always analyze wins alongside losses, or you have no control group.

**The load-bearing idea:** "we lost on price" is the most common close reason in every CRM on earth and is usually a proxy for *value not established*. Price is what a buyer says when the answer is no and they'd rather not explain.

## When to use this
- Close rate has moved and nobody can say why with evidence.
- The same objection appears in every deal review and has never been checked against outcomes.
- Before a pricing change, a positioning rewrite, or a roadmap commitment justified by "sales keeps asking for it."
- Quarterly, as a standing input to `positioning`, `pricing`, and `roadmap`.
- When you're about to build a feature because one loud lost deal asked for it.

## Before you start (gather these)
- **At least 10 decided deals** — closed-won and closed-lost both. Under ~10 you have anecdotes; say so rather than producing a confident chart.
- **The stated close reason** for each, from the CRM.
- **Something behavioral per deal** — how far it got, who was in the room, how long it sat, what the last activity was. This is what lets you go past the stated reason.
- **The segment for each deal** — size, industry, inbound vs outbound. Aggregate win/loss across mixed segments hides the answer.
- **Who they went with instead** — including "nothing" and "built it internally", which are competitors and are systematically under-recorded.

If two or more are missing, **ask 2-4 clarifying questions before analyzing.** The one that matters: *"do we have the wins too, or only the losses?"* A loss-only analysis cannot tell you what's different about losing. If the context is already in `workspace/`, open with an Assumptions block instead.

## Process

**Delegate to the `researcher` subagent.** Send the deal notes to `researcher` — wins and losses in **separate** invocations, so neither read is anchored by the other. Ask it to tag every item `stated` or `behavioural`; the whole analysis turns on keeping those apart. If subagents aren't available on this host, run the step yourself and say so — the output is still useful, just less independent.
1. **Segment before you count.** Split by deal size, source, and competitor faced. A 22% overall close rate that's 40% inbound and 9% outbound is two different businesses with one misleading number.
2. **Separate stated reasons from causes.** Tabulate the CRM close reasons, then set them aside. They are the starting hypothesis, not the finding. Note the share that say "price" — you will come back to it.
3. **Find where deals die, not why.** Map each deal to the last stage it reached. Losses cluster at a stage, and the stage tells you more than the reason field: dying at first demo is a positioning problem, dying at security review is a product problem, dying after a verbal yes is a champion problem.
4. **Compare wins to losses on the same variables.** For each candidate cause, check the win side. If 60% of losses had no economic buyer in the room but so did 55% of wins, it isn't the cause. **This step is the whole analysis** — everything before it is description.
5. **Test the price claim explicitly.** Compare discount depth on wins vs losses, and check whether "price" losses clustered in a segment where you're genuinely mispriced or spread evenly (which means it's a value problem wearing a price costume).
6. **Rank by frequency × addressability.** A cause in 40% of losses that you cannot change is context. A cause in 15% that you can fix this quarter is a roadmap item. Say which is which.
7. **Write findings as claims with a confidence level and a sample size.** Every finding gets `n=` attached. Then name the two or three actions, each owned, each with the metric that would show it worked.

## Output template
```markdown
# Win/Loss — [period]

**TL;DR**
- [Finding 1 — the cause, the segment, and the size of the effect] *(n=[x])*
- [Finding 2] *(n=[x])*
- [The thing everyone believed that the data does not support]

**Sample:** [n] decided deals ([w] won / [l] lost), [date range]. **Confidence:** [high/medium/low] — [why].

## Where deals die
| Stage | Wins reaching | Losses dying here | Read |
|---|---|---|---|
| [stage] | [n] | [n] | [what dying here means] |

## Stated reasons vs. what the data shows
| Stated reason | Share of losses | Holds up? | What's actually going on |
|---|---|---|---|
| Price | [x]% | [yes/no/partly] | [evidence from the win side] |

## Wins vs. losses on the same variables
| Variable | Wins | Losses | Difference real? |
|---|---|---|---|
| [economic buyer engaged] | [x]% | [y]% | [yes — n=, or no] |

## Findings
### 1. [Finding stated as a claim]
- **Evidence:** [the comparison, with numbers and n]
- **Segment:** [where it's true — and where it isn't]
- **Addressable?** [yes/no, by whom, roughly how long]
- **Confidence:** [high/medium/low] — [what would raise it]

## What we believed that isn't supported
- **[The belief]** — [what the data actually shows]. [Why the belief persisted.]

## Actions
| # | Action | Owner | Metric that proves it worked | By |
|---|---|---|---|---|

## Limits of this analysis
- [Sample size, self-selection, missing segment, CRM data quality — stated plainly.]
- **Not asked:** [the question this data can't answer, and how you'd get it — usually buyer interviews.]
```

## Avoid (anti-patterns)
- **Analyzing losses without wins.** Without a control you can only describe losers, never explain losing. This is the single most common way win/loss goes wrong.
- **Treating CRM close reasons as causes.** They're picked from a dropdown by someone moving on to the next deal.
- **Accepting "price" at face value.** Check discount depth on both sides before you believe it. For example, if losses averaged a 12% discount request and wins averaged 14%, price was not the deciding variable.
- **Aggregating across segments.** Enterprise and self-serve lose for unrelated reasons; averaged together they produce a finding that's true of neither.
- **Sample sizes under ~10 presented as trends.** Report the number, state that it's directional, and resist the chart.
- **Forgetting "no decision" as a competitor.** Deals lost to inertia are usually the largest single bucket and the most fixable.
- **Ending with findings and no owner.** A win/loss with no action is a document, not an analysis.

## Tips
- 💡 **The most useful column is "last stage reached."** It requires no interviews, exists already in your CRM, and tells you more than the reason field ever will.
- If a finding survives only in one segment, that's not a weakness — that's the precision you were looking for. Say where it holds.
- Feed confirmed findings straight into `positioning` (if you're losing at first demo), `pricing` (if discount depth differs), or `roadmap` (if a capability gap repeats across segments).
- Re-run it every quarter with the same method. The trend across quarters is worth more than any single run's finding.