# Test plan — B2B SaaS

The test plan with three columns a subscription business needs: which slice of the ideal customer profile the test runs against, where in the funnel it acts, and how long the result takes to become readable.

Everything else is the general test plan, unchanged. One hypothesis with a because in it, one variable, a named control, a minimum run, a read date set in advance and a decision rule for every outcome.

## How to use it

1. Copy this file, or the CSV version if you would rather work in a sheet.
2. Write the hypothesis before the variant, and make sure it contains a because.
3. Name one variable. If there are two, that is two tests.
4. Set the primary metric, the minimum run and the read date before anything is built.
5. Write the decision rule for every outcome, including the one where nothing moves.
6. Leave Result blank until the read date, and then fill it in whatever it says.
7. Keep the finished rows. A year of them is worth more than any single test in it.

## The columns

**Test ID** (Text). A short stable identifier that travels onto the creative file, the ad name and the lead record, so a finding can be traced to a cohort months after the assets have been rotated out.

**Hypothesis** (Text). What you believe and why, with a because in it, and here the reason is usually about the buyer: this hook will raise accepted leads because the champion has to justify the problem internally.

**Variable** (Text). The single thing being changed. With the volumes available in this category, a test with two variables will never produce a difference anybody can attribute to either.

**Control** (Text). What the variant is compared against, named exactly, including which version of the list and which landing page. Both drift during a run long enough to be readable.

**Variant** (Text). What is being tried, described so somebody could build it: the cost-of-problem hook, the ungated summary, the calculator instead of the report.

**Audience** (Text). Who sees the test, identical on both sides, and from the same list version. A list refreshed mid-test changes who one arm reaches without changing anything visible.

**Where it runs** (Text). The platform, the campaign and the placement this test runs inside. A test spanning a professional network and a search surface is two tests, because the intent behind each is different.

**Primary metric** (Text). The one number this test is decided on, chosen before it starts. Where the full outcome lags, name the proxy here and say in the row that it is one.

**Minimum run** (Text). The shortest run before anybody looks, set from the segment's own cycle rather than from patience, and long enough for both arms to have enough accepted leads to compare.

**Read date** (Date (YYYY-MM-DD)). The day the result is read, set from the result lag rather than from convenience, and after both arms have had the same time to mature.

**Decision rule** (Text). What each outcome means, written before the test starts. Inconclusive will be the common result at these volumes, and the rule has to say what happens then.

**Owner** (Text). The person who builds the test, reads it on the read date, and tells sales that both arms are to be handled identically.

**Result** (Text). What happened and what was decided, written on the read date, including the list refresh or quarter-end that made the run unreadable. Blank until then.

**ICP segment** (Text). The slice of the ideal customer profile this test runs against. A message that works on a small company often fails on a large one, so the segment is part of the finding.

**Funnel stage** (Text). Where the test acts: awareness, demand capture, acceleration, expansion. A test run at one stage says very little about another, and mixing them makes the row unreadable.

**Result lag** (Text). How long after the change the outcome becomes readable, from your own pipeline. It sets the read date, and it is the column that stops a test being judged on the fastest half of its cohort.

## The test plan

| Test ID | Hypothesis | Variable | Control | Variant | Audience | Where it runs | Primary metric | Minimum run | Read date | Decision rule | Owner | Result | ICP segment | Funnel stage | Result lag |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |

## Before you commit it

- Every row has a hypothesis with a because in it.
- Every row names one variable, one ICP segment and one funnel stage.
- The result lag is read from your own pipeline and written down.
- The read date is set from the lag, not from convenience.
- Where an early proxy is used, the row says so plainly.
- The decision rule covers the outcome where nothing moves.
- Every finished row has a result written on its read date.