---
name: win-loss-icp-update
description: Run the win/loss Recipe across Granola Folders of won and lost deals, compute which patterns show up more in wins than losses (lift, with counts), check how well reps' live confidence predicted outcomes, and propose evidence-backed changes to the ICP and MOMENT signal list in gtm-context.md. Use when someone asks "why do we win", "why do we lose", "win/loss analysis from calls", "update our ICP from evidence", "which signals actually matter", or "re-weight our signal list".
---

# Win/Loss to ICP Update

Most ICPs are written in a planning meeting and never tested. Your closed deals already hold the test. This skill compares what was true in deals you won against deals you lost, using what buyers said on calls, and proposes changes to the ICP and the signal list with the evidence attached.

It proposes. A human approves. Then it writes.

## Inputs

| Input | Source | If missing |
|---|---|---|
| Won calls | a Granola Folder (for example `Closed Won`) | stop and ask |
| Lost calls | a Granola Folder (for example `Closed Lost`) | stop; wins alone cannot show what separates a win |
| Outcome per account | the Folder name, or a CRM export the user supplies | ask; never infer outcome from the call |
| `gtm-context.md` | setup | run `gtm-context-setup` first |
| Optional: deal size, cycle length | CRM export | those columns stay `not supplied` |

Sample size rules, said to the user before running:
- Fewer than 5 won or 5 lost **accounts**: run it, label every finding "directional, not evidence".
- 5 to 14 per side: findings are "early evidence".
- 15 or more per side: findings are "evidence".

## Step 1: Run the win/loss Recipe per account

Use `folder-recipe-run` with the `win-loss` Recipe (Granola text in `folder-recipe-run/recipes/win-loss.md`). Group calls by account: a deal is one row, built from all its calls in date order.

Row schema:

| Field | Values | Rule |
|---|---|---|
| account | name | |
| outcome | won, lost | from the Folder or CRM, never the call |
| employee band, industry, region | as observed | `not discussed` if absent |
| stack or incumbent | tool names | |
| first-call pain theme | short label + verbatim quote | quote required |
| impact quantified | Y/N + number | |
| moment present at first call | signal type from the signal library + quote | |
| champion identified | Y/N + name | Y needs evidence of internal selling |
| economic buyer met | Y/N | |
| competitor in deal | name or none or do-nothing | |
| decision criteria stated | Y/N | |
| next step dated after first call | Y/N | |
| stated reason (won or lost) | verbatim if a buyer said it | `not stated on a call` if not |
| rep C at first call | 1 to 5 from Granola typed notes | `not captured` if absent |

Save as `folders/win-loss/table.csv` with these exact headers (the script reads them):

```
account,outcome,employee_band,industry,region,stack,pain_theme,first_call_pain_quote,impact_quantified,moment_signal,champion,economic_buyer_met,competitor,decision_criteria,dated_next_step,stated_reason,rep_c
```

Y/N fields hold `Y` or `N`. Multiple values in one cell are separated by `;`.

## Step 2: Compute patterns (deterministic)

Run `scripts/lift.py folders/win-loss/table.csv` (bundled with this skill). Do the math in code, never in prose. For every Y/N field and every categorical value:

```
won_rate  = accounts won with the feature / total won accounts
lost_rate = accounts lost with the feature / total lost accounts
lift      = won_rate / lost_rate   (if lost_rate is 0, report "only in wins" with the count)
```

A pattern qualifies when:
- it appears in 3 or more won accounts, and
- lift is 1.5 or more (win pattern) or 0.67 or less (loss pattern).

Report every qualifying pattern with counts, for example: "Moment present at first call: 9 of 12 won (75%), 3 of 11 lost (27%), lift 2.75."

## Step 3: Rep calibration

Average rep C at first call for won vs lost, and the share of deals where C was 4 or 5 that were won. One paragraph. This is the test of the human layer: if C predicts outcomes, reps' typed judgment deserves weight in prioritization. If it does not, say so plainly and suggest the team re-read the C scale.

## Step 4: Propose the ICP diff

Compare patterns to the ICP table in `gtm-context.md`:

| ICP dimension | Current | Proposed | Evidence (counts, lift) | Strength (directional, early, evidence) |

Propose a change only with a qualifying pattern. Examples: narrow the employee band, add an industry, make a dimension a gate, add a disqualifier from a loss pattern.

## Step 5: Propose the signal list diff

Map qualifying patterns to signals. Suggested points by lift:

| Lift | Points |
|---|---|
| 3.0 or more, or only in wins with 5+ accounts | 10 |
| 2.0 to 2.9 | 8 |
| 1.5 to 1.9 | 6 |
| under 1.5 | keep current or 3 |
| 0.67 or less | 0, and propose as a disqualifier or risk flag |

| Signal | Current points | Proposed | Evidence | Strength |

Add new signals the calls revealed that the library does not have (for example "buyer names a board deadline").

## Step 6: Stop and ask

Show the report, the two diffs, and ask: "Approve all, approve some (list which), or none?"

Only after approval: update `gtm-context.md`, keep the old values in the change log with the date, the folders used, and the counts. Never change the file without approval.

## Output: `folders/win-loss/report.md`

```markdown
# Win/Loss Evidence Report
Won accounts: <n> | Lost accounts: <n> | Calls read: <n> | Strength: directional, early, or evidence
## What separates wins from losses
| Pattern | Won | Lost | Lift |
## Buyer-stated reasons
Won: quotes. Lost: quotes.
## Rep calibration
## Proposed ICP changes
## Proposed signal list changes
## What this cannot tell you
Sample limits, missing fields, calls without transcripts, deals with no first call recorded.
```

## Rules

- Outcome comes from the Folder or CRM, never from reading the call.
- Count accounts, not calls.
- Lift without counts is not allowed in the output.
- Correlation only. Say it once in "What this cannot tell you".
- Never write to `gtm-context.md` without approval.
