Your notes say the search trend looks promising, two founders liked the idea, and a landing page collected a few emails. You still cannot answer the expensive question: what, exactly, are you now allowed to build?
Begin with the claim that could kill the idea
“Bookkeepers need better document chasing” is a theme. It gives you nothing to test. A working claim names the trigger, the person, the job, the current alternative, the proposed result, and the commitment you are asking for.
When the weekly missing-document review begins, a practice administrator cannot tell which client files are ready without reconciling a spreadsheet and inbox. A reviewed status report would be useful enough for that administrator to bring a redacted template to a workflow session.
This is still a hypothesis. That is fine. The point is to make disagreement possible before code makes the idea feel more real than the evidence.
Five evidence families, five different limits
| Signal | What it can help you learn | What it does not prove |
|---|---|---|
| Search context | How interest in a term varies across the sampled searches, places, and periods available to the tool. | Market size, purchase intent, or a buyer’s workflow. |
| Conversation | How a person describes a recent incident, current workaround, authority, and consequence. | That the incident is common or that the person will buy. |
| Manual result | Whether you can produce a bounded output from permitted inputs and whether someone can review it. | Repeatability, acceptable economics, or product adoption. |
| Commitment | Whether the next step survives a request for scarce time, data, approval, or money. | That one form of commitment is universally stronger than another. |
| Payment | Whether a clearly described offer under disclosed terms receives an actual payment attempt or purchase. | That creating a checkout page validates demand. |
Google’s own Trends documentation describes the data as a normalized sample. The 0–100 index is not absolute search volume. Keyword Planner provides advertising estimates affected by settings and rounded historical volumes, according to Google Ads Help. Use both for context, not as a substitute for a buyer decision.
Stripe documents Payment Links as a way to create and share a payment page without code. The useful event is not the link’s existence. It is what happens after a clear offer reaches an appropriate person, with honest availability, pricing, refund terms, and data handling.
Write the test before you run it
Strategyzer’s Test Card separates the hypothesis, test, measurement, and threshold. Borrow that discipline without pretending it is the only valid method.
One-test card
Pick the earliest unsupported assumption, not the most impressive experiment. If you do not know whether the workflow exists, a polished presale page is premature. If the workflow is clear but data access is blocked, another interview about pain will not remove that block.
Keep observation, interpretation, and action apart
The companion Learning Card makes this separation explicit. It matters because founders are very good at turning a polite comment into a story about demand.
Use three fields:
- What happened: the reply, action, artifact, refusal, payment event, or absence of a result.
- What you infer: your interpretation, with uncertainty left visible.
- What changes next: continue, revise, stop, refund, or rerun because the test itself failed.
“No result” can be informative when the intended people saw a clear offer through an appropriate route. “Inconclusive” is more honest when recruitment missed the intended role, the offer was ambiguous, or the test could not be run safely.
An illustrative dossier, with the blanks left blank
Illustrative scenario; no customer, result, or market claim. A fictional founder is considering a status-report service for bookkeeping practices. Nothing below happened to Pink Banana Tools or to a real buyer.
| Field | Illustrative entry |
|---|---|
| Claim | A practice administrator reviews missing documents weekly and can assess a report built from a redacted template. |
| Known | The proposed output can be described: a draft status report with unresolved items visible. |
| Unknown | Whether the review creates a meaningful consequence, whether usable inputs can be shared, and whether the output changes a decision. |
| Next test | Ask an appropriately recruited administrator to reconstruct one recent review and, if permitted, assess a synthetic report shaped like their process. |
| Continue rule | The participant can identify where the report fits, what decision it supports, and what input or approval would be required next. |
| Stop rule | The existing method is adequate, the proposed output changes no decision, or the necessary access cannot be obtained appropriately. |
| Current decision | Do not build. The first unsupported dependency is workflow fit. |
Ignore logo options, dashboard architecture, automated reminders, broad SEO volume, and the number of people who say the idea sounds useful. None of those resolves the first unsupported dependency in the dossier. Also ignore fake checkout tactics, hidden pricing, invented scarcity, and offers you cannot deliver. Confusion is not evidence.
Bottom line: authorize one test, not a build
Open the dossier. Circle the first assumption that is still unknown or contradicted. If you can run one honest, bounded test against it, write the continue, revise, and stop rules first. If you cannot run that test without deception, unsafe access, or an unavailable offer, stop here. Code is not the next step.