The pipeline, end to end

The GTM engine turns one product link into paying customers in twelve stages, grouped into four phases, and then it loops. Each phase hands one thing to the next:

What paid flows back into which triggers you watch and which playbooks you run. Remember it as: understand who buys, listen for who's ready, act one play at a time, learn from every number, then loop.

The rule underneath every stage

Every stage is a decision, and every decision is training data, if you record it in the right shape from the first day. Eight rules:

1. Log the decision, not just the result. Every choice, by the system, the founder or the lead, is an append-only event that names who made it.
2. Version whatever decided. Model, prompt, rule, scorer, ICP, detector: each row carries the version strings that produced it.
3. Freeze the inputs. Store the features as they were at decision time. Recomputing them later leaks the future into training data.
4. Keep the negatives. Discarded matches, skipped leads, blocked sends and "no" replies, each with its reason. They are half of every training set.
5. Log the odds. Store the probability of each choice and keep a small random slice, so a new model can be judged on old data before it ships.
6. Every human touch is a label. Edits, corrections, skips and never-contact marks, with the before, the after and the reason when given.
7. One chain of ids. Any payment traces back through the message and the lead to the rule that found the person, and forward again.
8. Keep the raw, with a retention rule. Full text, the url and both timestamps (posted and captured). Public data only, deleted on request.

What each stage records

For every stage: what it tunes, what to record, the label that says whether it worked, what that data can train, and what to test first.

Stage 1 · Link

What it tunes: the intake: how many links become a finished brief, then a signup

Record

• the URL submitted, with the visit's referrer and UTM tags
• each intake step reached, with a timestamp: brief streaming, Google login, dashboard
• where people leave, and after how many seconds
• the hero copy and page version they saw

The label: finished the intake; joined the waitlist or signed up

What it trains: an intake-completion model and copy-test readouts

What to test: hero copy, intake order (login before or after the brief) · A/B by visitor

Start with: one intake_step event per step, carrying the page version, so drop-off is measured per step.

Stage 2 · Brief

What it tunes: the brief extractor: the right fields, at the right evidence level

Record

• every field's value, evidence tier (A to D or site claim), and the quote and URL behind it
• the model, prompt version, pages fetched, tokens and cost of each run
• the founder's correction as a before and after, per field
• how long the founder took to confirm

The label: per field: kept, corrected or rejected

What it trains: an extractor eval set (each corrected field is a test case); calibration, i.e. is tier A really right more often than tier C?

What to test: extractor prompt and model · offline replay on stored sites, scored against founder corrections

Start with: stamp the prompt version on each run and emit one event per corrected field with its diff.

Stage 3 · ICP

What it tunes: the filter: which fit and not-if lines actually predict payment

Record

• the ICP version, each fit and not-if line, and its evidence
• per lead, which lines matched, as one frozen column per line
• the founder's verdict on each lead, and the reason
• the same line vector for every payer and every cancellation

The label: founder accept or never; paid; churned

What it trains: an ICP fit classifier and per-line lift, so weak lines get cut and strong ones get narrower

What to test: which fit and not-if lines are in · offline: rescore past leads against accept and paid labels

Start with: version the ICP and store the matched lines on each lead at score time.

Stage 4 · Trigger

What it tunes: which triggers to run, and how long each one stays fresh

Record

• each trigger's screening decision (start, on, later, off) and why
• trigger_id on every signal
• the source post's own timestamp beside the capture time, i.e. detection lag
• reply and signup rates by signal age, in hours

The label: reply and payment per trigger, by age

What it trains: a ranking of triggers by value, and a fitted freshness window per trigger to replace the guessed one

What to test: which triggers are on; each freshness window · offline from the decay curve, then by lead cohort

Start with: store posted_at next to captured_at on every signal; the decay curve comes free.

Stage 5 · Detector

What it tunes: each watching rule's precision, and its yield per dollar

Record

The label: founder real or not on matches; yield: signals that became leads, replies, payments

What it trains: per-detector precision, rule tuning, and a retire list

What to test: rule, vocabulary, source · shadow: the new version runs beside live on the same items

Start with: keep shadow verdicts as rows and log run cost. Reddit RSS ends Nov 13: keep the replacement's rows in the same shape.

Stage 6 · Signal

What it tunes: the match judge and the router

Record

• the full raw text and an author snapshot, frozen at capture (posts get deleted)
• the rule that fired, and its score
• the judge's verdict, reason, confidence, model and prompt version
• every discard with its reason (stale, excluded, judge said no, no person)
• the queue it went to: pain, engage, listen or launch

The label: founder real or not; the cases where judge and founder disagree

What it trains: the match judge, distilled into a small, cheap model, and the routing classifier

What to test: judge prompt and model · offline replay against founder labels

Start with: keep discarded matches as rows. Without negatives, the judge can't be trained.

Stage 7 · Lead

What it tunes: who goes to the top of today's list

Record

• identity links with method and confidence, and every split the founder makes
• the score, with scorer version and the exact features used, frozen as JSON
• tier changes (Hot, Warm, Watch) with the time and the cause
• enrichment fields with their source and date

The label: accepted, skipped or never; replied within 7 days; paid

What it trains: entity resolution, reply propensity (lead score v2) and calibrated tiers

What to test: scorer weights, tier cutoffs · offline against reply labels, then a randomized slice of the daily top 10

Start with: freeze the feature snapshot at score time.

Stage 8 · Playbook

What it tunes: which play to run, for this lead, right now

Record

• the plays this lead was eligible for, each with its score
• the play chosen, and the probability it had of being chosen
• plays the contact policy blocked, and the rule that blocked them
• playbook id and version on every move

The label: what the move produced: reply, click, signup

What it trains: a playbook recommender (contextual bandit), evaluated offline from the logged odds

What to test: which play to run · off-policy estimate from logged odds, then a live exploration slice

Start with: log the candidate set and propensity on every move, and keep a 10% exploration slice.

Stage 9 · Campaign

What it tunes: true lift: what the campaign caused, not what would have happened anyway

Record

The label: conversion per arm; lift against the holdout

What it trains: offer and stop-rule choice, and an uplift model (who is persuadable versus who converts anyway)

What to test: offer, stop rule, holdout share · randomized arms with a holdout

Start with: a 10% outreach holdout. Without one, every result is a correlation.

Stage 10 · Sequence

What it tunes: the drafts and their timing

Record

• every draft: prompt version, randomized slot, variant type, register, full text
• the decision: shipped, shipped edited or discarded, with edit distance, edit locus (hook, body, ending) and seconds to decide
• a touch_id on each sent message, with sent time against suggested time
• the founder's exact words when he logs what he sent

The label: kept, edited or discarded; draft-versus-posted pairs; reply

What it trains: a draft reward model from preference pairs, opener choice, and a send-time model

What to test: opener, hook, length, proof, send time, number of steps · randomized per draft (prompt version and slot)

Start with: the same row for lead replies and DMs, with a touch_id that follows the link and the answer.

Stage 11 · Funnel

What it tunes: the weakest rung

Record

• replies with full text and a class (positive, question, not now, stop)
• clicks per link id, and visits carrying the touch_id
• signup with first and last touch, and how they heard
• activation; Stripe paid, failed and canceled
• each post's metrics at 10 minutes, 30 minutes, 1 hour, 1 day and 7 days

The label: each rung reached, with its timestamp (time-to-event)

What it trains: conversion and churn models, attribution, and an early forecast (does a post's 30-minute number predict its 7-day number?)

What to test: landing and waitlist copy, the call to action · A/B by visitor

Start with: carry the touch_id through short links into signup.

Stage 12 · Loop

What it tunes: the process itself: which kinds of change move the number

Record

• a daily snapshot: counts per rung, per trigger, per detector
• each review: the constraint chosen, the hypothesis, the sample sizes
• each change: what, where, the new version, the judge-by date and the win rule, set before
• the readout and the learning it produced

The label: did the change move the constraint, by the rule set beforehand

What it trains: a learnings base that sets priors for the next test, and later an agent that proposes the next change

What to test: review cadence, which constraint goes first · not randomized; tracked as learnings

Start with: one experiment row and one row per unit, each linked to the change it tested.