---
name: hashgraph-online/traction-test-planner
source: https://app.decimal.ai/s/hashgraph-online-traction-test-planner@1/SKILL.md
source_sha256: 1522be2c62f9
---

# Traction Test Planner

Use this skill to design traction tests that create decision-quality evidence.
It turns a candidate channel strategy into a scoped experiment with assumptions,
metrics, budget, duration, and next-step rules.

## Source Traceability

Primary source: Traction, chapters 3 and 4, plus the appendix.

- Chapter 3 defines the three core test questions for middle-ring channels.
  Authoring notes: converted lines 585-606.
- Chapter 4 distinguishes cheap channel tests from optimization and explains
  inner-ring testing. Authoring notes: converted lines 675-786.
- The appendix lists phase I test prompts for the 19 traction channels.
  Authoring notes: converted lines 3323-3372.

See [middle-ring-test-prompts.md](references/middle-ring-test-prompts.md) for
paraphrased starter tests by channel.

## Test Types

### Middle-Ring Test

Use when validating whether a channel strategy could become the core channel.
Keep it cheap, fast, and strategy-level.

Answer:

1. Acquisition cost: what would it cost to acquire a customer?
2. Reach: how many relevant customers may be available?
3. Fit: are these customers desirable right now?

### Inner-Ring Test

Use after a core channel is chosen. Inner-ring tests optimize the winning
strategy or search for a better strategy inside the same channel.

Examples:

- Test a new audience, keyword group, offer, landing page, creative angle, or
  partner segment.
- Run A/B tests where traffic and measurement are already in place.
- Use other channels only as support for the core channel, not as competing
  strategies.

## Workflow

### 1. State The Decision

Write the decision the test must enable. Good tests decide something specific:

- Continue, kill, or revise this channel strategy.
- Promote this channel into the inner ring.
- Scale spend, hold spend, or change audience.
- Choose between two channel strategies.

### 2. Write Assumptions

List the assumptions that must be true for the strategy to work.

Use this structure:

| Assumption | How Test Measures It | Kill Threshold |
|------------|----------------------|----------------|

### 3. Set Metrics

At minimum, include:

- Reach available.
- Conversion rate.
- Cost to acquire a customer.
- Customer quality or intent.
- Lifetime value estimate, if available.

If the user lacks analytics, include a setup step before the test. A test
without tracking creates anecdotes, not evidence.

### 4. Bound Budget And Time

For early-stage tests, prefer less than one month and a small budget. If the
user proposes a large test before there is evidence, reduce scope.

### 5. Define Outcomes Before Running

Every test needs decision rules:

- **Double down** when results beat the success threshold and customer quality is
  acceptable.
- **Iterate** when one metric fails but the channel shows a fixable signal.
- **Kill** when reach, cost, or customer fit cannot plausibly move the traction
  goal.

## Output Format

```markdown
# Traction Test Plan

## Decision
[What this test will decide.]

## Channel Strategy
- Channel:
- Strategy:
- Target customer:
- Stage:

## Assumptions
| Assumption | Measurement | Threshold |
|------------|-------------|-----------|

## Experiment Design
- Setup:
- Audience/source:
- Offer/message:
- Landing or conversion path:
- Budget:
- Duration:

## Metrics
| Metric | Target | Tracking Method |
|--------|--------|-----------------|

## Decision Rules
- Double down if:
- Iterate if:
- Kill if:

## Next Step After Test
[What to do for each likely outcome.]
```

## Quality Bar

- Do not design tests that only measure vanity traffic.
- Do not optimize multiple variables before validating strategy-level promise.
- Make tracking explicit before the test starts.
- Prefer comparable metrics across channels.
- Call out when the test cannot plausibly move the user's traction goal.