# Marketing channel test brief

Copy this file into your preferred editor. Fill unknowns explicitly instead of inventing evidence. Set your resource cap and decision rules before starting. A pilot supplies directional evidence; it is not automatically a controlled experiment.

## Blank brief

- Product and stage:
- Customer, user, and buyer:
- Problem and current workaround:
- Supplied evidence and source:
- Assumptions to check:
- Where and how we will reach people:
- Offer and next action:
- Path to a meaningful product result:
- Required assets:
- Tasks and owner:
- Time available:
- Spending cap, including what it covers:
- Outcome measures, units and observation windows:
- Customer-quality and reliability checks:
- Early execution check:
- Later outcome review:
- Stop condition:
- Revise condition:
- Continue condition:
- Unanswered questions:

## Results log

| Date | Work attempted | Observation / count | Evidence source | Quality or measurement concerns | Decision and owner |
|---|---|---|---|---|---|
| | | | | | |

## Completed fictional example

- Product/stage: API monitoring tool; initial users, no repeatable channel established.
- Customer: Small platform teams investigating failed webhook deliveries. Buyer and purchase approval route need research.
- Problem: Connecting a failed delivery with the downstream support request.
- Evidence: Two fictional interview notes describe manual log matching. This is illustrative evidence, not actual customer research.
- Approach: Produce a reproducible debugging example; share through one relevant community after verifying its rules and audience discussions.
- Offer: Useful example without purchase; monitoring quickstart for readers who want to explore further.
- Assets/owner: Founder validates sample code, writes guide, checks quickstart, participates in discussion and records feedback.
- Capacity: Four hours per week; $300 maximum total pilot spend. These are example constraints, not recommended minima.
- Measurement: Relevant conversations, setup completions, useful investigations and return use. Record denominators, dates, identity limitations and fit.
- Early check: After the example is ready, verify links, tracking, technical correctness and participation eligibility before distribution.
- Outcome review: Select a date after estimating the distribution and product-use cycle. Extend only with a written reason and a new cap.
- Stop: Unable to contribute within the rules, technical example fails, or cap reached without interpretable evidence.
- Revise: Relevant people engage but the example or setup prevents a useful result.
- Continue: Repeated fit-relevant conversations and completed useful workflows justify another bounded test; do not infer precise long-term CAC from a small sample.

## Review checklist

- Can a reader identify the audience, offer and mechanism?
- Are important assumptions separate from observed facts?
- Is the next action something the product can support now?
- Does the owner have enough time for the full workflow?
- Are outcome definitions and review rules clear?
- Is customer quality considered beyond visits or signups?

## Candidate comparison before the pilot

| Candidate approach | Audience evidence | Existing asset | Missing prerequisite | Full-workflow owner and effort | Investigate, test, or defer |
|---|---|---|---|---|---|
| | | | | | |

Select one feasible next step and record why the alternatives are deferred. A convenient channel is not automatically a relevant one.


---
Original resource by Jon Bishop. CC BY 4.0. Illustrative examples are not customer results.