Write the assumption and its possible refutation
A card should name one behavior in one setting. Teams want better reporting cannot guide a test because almost any click can look like support. Specify a role, trigger, action, and practical reason. Then write a falsifier: an existing tool that solves the task, a qualified person who declines, or a response from the wrong decision maker.
The refutation field changes promotion into learning. It prevents every interaction from becoming a win and makes room for inconclusive results when relevant exposure is low or the instrument fails.
Copyable SaaS test card
Complete before launch. State what may challenge the hypothesis and prevent misleading totals from mixed audiences, repeated actions, and late changes.
SAAS TEST CARD Decision [decision this test informs] Assumption We believe [role] in [situation] will [observable action] because [reason]. Falsifier This is challenged if [observation, objection, alternative, or non-use]. Artifact and disclosure [test artifact] [what exists and what does not] Signal and denominator Count [one action] only from [qualified participant]. Record all [qualified exposure, invitation, or participant] from [source]. Do not combine Keep [other channel, role, version, repeat action, or later test] separate. Threshold and window If [local threshold and context] by [date or limit], [next action]. This is not an industry benchmark. Start: [date] End: [date] Inconclusive and stop rules Inconclusive if [missing exposure, ambiguity, implementation issue, or conflict]. Stop, pause, or revise if [condition]. Evidence log Source: [source] Observation: [fact] Limit: [what it cannot prove] Decision snapshot Supports: [statement] Challenges: [statement] Unknown: [statement] Next action: [statement]
Define the signal, denominator, threshold, and window
State the numerator and denominator. For a concept page, the denominator might be qualified visitors from a named channel, while the signal is a completed form plus a matching situation. A repeated click is not several people. Other roles, page versions, and outreach rounds belong in separate records.
Choose a local threshold from this test cost and purpose, not a borrowed pass rate. Add the window, stop rule, and inconclusive rule. The card is complete when it says what happens for support, counterevidence, insufficient exposure, and ambiguity.
Fictional illustrative example
Fictional example: an eight-of-one-hundred result
A fictional founder tests whether independent compliance consultants request a manual review of policy-change notes. A permissioned specialist newsletter delivers 100 invitations to version A. Those deliveries are the outreach denominator, not measured page visitors; role fit is checked in replies rather than assumed for every recipient. Eight people submit: three describe active work in the target role, two are outside the specialty, two are students, and one has no recent change. Before sending, the founder sets a local threshold of five qualified requests from this outreach, explicitly not an industry benchmark.
Eight submissions are not eight qualified signals. Only three match the role and situation, so the threshold is not met. This fictional result is inconclusive or challenging depending on acquisition and mismatch. Inspect the audience definition and active workflow before declaring product-market fit.
Preserve evidence limits in the decision
Review source records before totals. A number can hide role mismatch, copy-driven curiosity, consent issues, or a sufficient alternative. Put each result beside its limit. A form response may support investigation but not retention; a manual action may show task interest but not pricing acceptance.
Keep support, challenge, unknown, and next action separate. Do not rerun the same ambiguous test without changing the question, audience, artifact, or acquisition condition. The aim is a better decision, not a positive score.
Failures that make a card look precise without being useful
Do not write the card after results, omit the falsifier, or set a threshold with no denominator. Do not pool email replies, clicks, interviews, and later versions. Do not treat every response as qualified, hide a poor channel, or present a local target as a benchmark. Numbers alone do not make a card valid.
Is this the same as a Strategyzer test card?
No. Strategyzer's Test Card is a separate method and resource linked below. This independent EviDemand worksheet adds explicit counterevidence, denominator boundaries, and inconclusive rules for a small SaaS test; it is not an official Strategyzer template.
What should count as inconclusive?
Examples include too little qualified exposure, an ambiguous response, a broken measurement path, or conflicting evidence that the card did not distinguish. Inconclusive is a result, not a result to hide.
Can a percentage be a universal pass rate?
No. A threshold belongs to the audience, channel, test cost, and decision at hand. It should direct one next action, not claim a general SaaS benchmark.
Background method, separate from this original EviDemand worksheet: Strategyzer: Validate your ideas with The Test Card
Keep the public test and the private decision connected
Turn the card into an individual project's private test plan, then edit and publish a public page on a system subdomain. Two templates, three styles, built-in forms, immutable published versions, and decision snapshots are available. Visit, CTA, and section measurement require analytics consent; the form does not. Do not divide all saved submissions by only consented visitors: their coverage differs. Qualification and external outreach records require your own review. You obtain traffic and execute the experiment; operations handles research separately. Where configured, an AI draft may be available; generated text requires human review and availability can vary by environment, language, and configuration. There is no automatic card import, ad delivery, randomized A/B allocation, or guaranteed outcome.
