A/B Test Design and Readout

Design an experiment with a decision rule fixed in advance, then read the result honestly, including when the answer is inconclusive.

Help me with an A/B test. I am at stage: [DESIGN / READOUT].

**If DESIGN, give me these:**

What I want to change and why I think it will work: [THE CHANGE + THE MECHANISM]
Primary metric: [THE ONE METRIC THAT DECIDES THIS]
Guardrail metrics that must not get worse: [e.g. refunds, support tickets, load time]
Traffic or users available per week: [NUMBER]
Current baseline rate of the primary metric: [NUMBER]
Smallest improvement worth shipping for: [NUMBER, AND WHY THAT SIZE]

Produce: the hypothesis stated so it can be wrong; the unit of randomization and why; the required sample size and runtime for the effect I care about, with the arithmetic shown; the decision rule written before any data exists (ship if X, kill if Y, extend if Z); what would invalidate the test (contamination, novelty effects, seasonality, a release mid-test); and whether this test is worth running at all given my traffic. If my traffic cannot detect the effect I care about in a reasonable time, say so plainly and suggest what to do instead.

**If READOUT, give me these:**

The design, including what was decided in advance: [PASTE IT]
Results:
"""
[PASTE: VARIANT, USERS, CONVERSIONS, AND ANY SEGMENT BREAKDOWN]
"""

Produce: the observed effect with a confidence interval and what that interval means in plain language; whether the pre-registered decision rule is met; guardrail metrics checked explicitly; and a verdict of ship, kill, or inconclusive. Treat inconclusive as a real and common outcome rather than a failure to find the story. Then: which segment cuts were planned versus which are being looked at now, flagging the latter as exploratory and not conclusive; the practical significance in business terms, not just statistical significance; and what to test next.

Rules: never call a result significant without the interval. Never present a post-hoc segment finding as a result. If the test ran differently than designed, that changes what can be concluded, so say how.

How to use

The decision rule written before data exists is what makes an experiment an experiment. Without it, a flat result becomes 'let it run a bit longer' and a segment with a good number becomes the headline, and both are ways of guaranteeing you find something. The readout side deliberately makes inconclusive a first-class verdict: most tests of most changes do not move a metric detectably, and pretending otherwise is how teams accumulate a backlog of wins that never show up in the totals.

More business prompts

Build me a monthly budget and a debt payoff plan from these numbers.

Take-home income per month: [AMOUNT, and note if it varies]
Fixed costs: [RENT/MORTGAGE, UTILITIES, INSURANCE, SUBSCRIPTIONS, TRANSPORT, CHILDCARE, with amounts]
Variable spending, last 3 months if known: [GROCERIES, DINING, SHOPPING, ETC.]
Debts: [FOR EACH: name, balan

Budget and Debt Payoff Plan

Turn your real income, bills, and debts into a monthly budget and a payoff schedule with the math shown and the tradeoffs named.

Businessbeginner

Build a 13-week cash flow forecast.

Cash on hand today: [AMOUNT, and which accounts]
Any restricted or committed cash: [AMOUNT AND WHAT IT IS FOR]

Expected inflows:
- Receivables outstanding: [CUSTOMER, AMOUNT, INVOICE DATE, TERMS, and how reliably each pays]
- Recurring revenue: [AMOUNT, BILLING DATE, CHURN ASSUMPTION]
- New sales expe

13-Week Cash Flow Forecast

Build the rolling weekly cash forecast operators actually run on: opening balance, timed inflows and outflows, and the week you run short.

Businessadvanced

Help me set pricing for [PRODUCT/SERVICE].

What it does and who buys it: [PRODUCT + BUYER]
The alternative if they do not buy: [COMPETITOR, IN-HOUSE, SPREADSHEET, DOING NOTHING]
What that alternative costs them: [MONEY, TIME, RISK. Estimate if needed and say so.]
Value we create, quantified if possible: [TIME SAVED, REVENUE GAINED, COST

Pricing Strategy

Work out what to charge and how to package it: value basis, tier structure, the metric you meter on, and how to test before committing.