Pipeline management

# Pipeline management

## Goal

Build a qualification and pipeline system that tells the truth about demand: which inbound people are beachhead buyers, which outbound accounts are worth pursuit, what stage an opportunity is actually in, and what evidence would have to appear before it moves.

This is system design. Do not contact leads, invent opportunities, or update a live CRM. A stage name is not progress.

Complete the analysis autonomously. Do not stop to ask clarifying questions. When evidence is missing, make the narrowest assumption that permits a usable system or `HOLD`, label it, and state what changes if it is false.

Do not modify application code.

## Prerequisites

Read the latest ICP, market, positioning, pricing, campaign, nurture, and channel files; any CRM exports, pipeline notes, win/loss records, or spreadsheets in the repository; and any existing `docs/gtm/pipeline.md`, `docs/gtm/pipeline.yaml`, and `docs/gtm/pipeline-changelog.md`.

If the ICP has no observable qualification signals, return `HOLD`. A pipeline cannot be more precise than the customer definition.

## Evidence standard

Use the shared GTM labels.

A meeting is not a qualified opportunity. A verbal maybe is not next-step commitment. A date in a CRM is not a close date unless a buyer-owned next step exists.

Count purchasing units, not contacts. Multiple people at one account are one opportunity unless they buy separately.

## Step 1: Define entry

State how a purchasing unit enters the pipeline:

* inbound, with source
* outbound, from a named and sourced account
* referral
* expansion of an existing customer, kept on a separate board

Every entry must have: organization, purchasing unit, source, date, beachhead fit hypothesis, and missing evidence.

Do not allow “someone downloaded a thing” as entry without a fit hypothesis.

## Step 2: Write qualification that can fail

Translate ICP predicates into a score or gate the founder can apply in ten minutes:

* structural fit
* operating state
* active trigger
* current alternative
* economic buyer identified
* prerequisites the product needs
* disqualifiers

Each gate: required or favorable, how it is observed, false positives, false negatives.

Outcome classes:

* `DISQUALIFIED`
* `WATCH` (YELLOW, time-boxed)
* `QUALIFIED`
* `COMMITMENT-READY`

If historical deals exist, test the gates against them, including losses. If the gates would have passed the losses and failed the wins, rewrite the gates.

## Step 3: Define stages by evidence, not hope

Use the fewest stages that change what the founder does next. For each stage:

* name
* evidence required to enter
* evidence required to stay
* buyer-owned next step
* default exit if the next step does not occur by a dated time
* what must not be counted yet (revenue, close probability)

Suggested skeleton, to be adapted, not copied blindly:

1. suspected fit
2. conversation with a relevant role
3. trigger and alternative confirmed
4. economic buyer engaged
5. commitment in motion (access, pilot, paper)
6. closed won or lost, with reason

Do not use percentage-to-close theater. If you must forecast, use evidence class and historical conversion only when history exists; otherwise mark forecast `UNKNOWN`.

## Step 4: Inbound versus outbound rules

Inbound: respond, qualify, disqualify fast. Do not let polite curiosity clog the board.

Outbound: only named accounts that survive the market-audit or sprint list logic. No purchased lists of unverified titles.

Proactive prospecting volume is capped by follow-up capacity, not by how many names can be typed.

## Step 5: Hygiene

Define:

* stale rules
* required fields
* one opportunity per purchasing unit
* loss reasons from the objection map
* when a recycled account may return
* what is never deleted, only closed

A pipeline that cannot show losses is a diary.

## Step 6: Desk-test

1. Qualification can fail.
2. Stages require evidence.
3. Contacts cannot inflate account counts.
4. Inbound curiosity does not become pipeline by default.
5. Outbound cannot exceed capacity.
6. Historical deals, if any, do not silently contradict the gates.

## Decision

* `INSTALL`: the system may be used
* `INSTALL NARROWLY`: stages and gates only, no forecasting
* `HOLD`
* `REVISIT ICP` if gates cannot be observed

Lead with:

“As of [date], pipeline entry requires [gates], stages move only on [evidence], forecasting is [allowed / unknown], with decision [INSTALL / INSTALL NARROWLY / HOLD / REVISIT ICP].”

## Deliverables

### 1. `docs/gtm/pipeline.md`

Entry rules, gates, stages, inbound/outbound policy, hygiene, desk tests, open questions.

### 2. `docs/gtm/pipeline.yaml`

`version`, `status`, `decision`, `entry`, `qualification_gates`, `stages`, `inbound_rules`, `outbound_rules`, `hygiene`, `loss_reasons`, `forecast_policy`, `assumptions`, `unknowns`, `sources`.

Do not invent opportunities. If illustrating the schema, use clearly labeled examples.

### 3. `docs/gtm/pipeline-changelog.md`

Append only.

## Boundaries

* Do not contact anyone or write to a production CRM.
* Do not invent deals, close dates, or probabilities.
* Do not treat meetings as qualification.
* Do not keep YELLOW accounts in the live board without a time box.
* Do not forecast from empty history.
* Preserve uncertainty.

## Done when

* Gates, stages, and hygiene are explicit and can fail.
* Purchasing units are the counting unit.
* Desk tests passed or forced `HOLD`.
* The three files agree and contain no fake pipeline.