Best practices

Before you start

Read the four steps first. These practices sharpen them; they don't replace them.

Steps

1. Pick the assumption that scares you

   Test the belief that would sink the idea, not the one you're surest of. If you'd be relieved to skip it, that's the one. Write it with a number in it: "pay $79 a month", not "pay for it".

2. Agree the success criteria before anything runs

   Settle the success criteria with whoever makes the decision, before the first result. Ask: "if we hit only half of this, would we still build it?" If yes, the criteria are too high or too vague. Never move them afterwards; run a new experiment instead.

3. Measure commitment, not compliments

   Payment beats a pre-order, a pre-order beats a sign-up, and a sign-up beats "I'd use it". Choose the strongest signal you can afford to collect within weeks, not months.

4. Size the sample so one row can't flip it

   If one more or one fewer result would change the call, treat the result as a first read, not a final answer. Give the experiment an end date and an owner.

5. Keep every row, including the awkward ones

   Log non-replies separately from "no". Record late results with a note rather than dropping them. Add the one column the hypothesis depends on (in the example: how many teammates were invited). Use real data, logged as it arrives.

6. Make your own call first

   Call the result and choose the decision on your own judgment before you ask anyone, including your AI tool, what they think. That's why no result is chosen for you and the decision form shows no recommendation. Read SwiftCNS's assessment and insights as input, then compare notes.

7. Write down why, and what happens next

   A decision without reasons can't be reviewed or built on. Name the next step and how you'll know it worked.

What you get

In the running example, these habits paid off:

• The team chose the paid offer over a cheaper fake-door button, so the result measured payment, not interest.
• They kept the late payer (day 10) and the two non-replies in the tracker, which surfaced that approval slows some teams down.
• The teammate column showed that every paying team had invited 3 or more people, which shaped the decision: build for teams, test a lower price for pairs.

Done when

• Your criteria were agreed before the first result.
• A single result couldn't flip your call, or you said so in the Learning.
• Your decision says what happens next.

Common mistakes

• One question, many experiments in one conversation. Keep one question per conversation so the record stays readable.
• Treating earlier Learnings as proof. Reuse them as context for the next test, not as evidence of demand.
• Optimising the experiment instead of the decision. The goal is a better decision, not a perfect test.

For agents: MCP tools and gotchas

• Never pre-select a Learning result or pass a recommendation to prepare_decision_review unless the user explicitly asks.
• Prior Learnings are context: attach them with attach_sources_to_conversation; don't present them as proof.

Next

Working with your AI tool: how to run these steps from Claude, ChatGPT, Cursor or Codex.