Prototype Decision Tree

Begin With the Decision, Not the Artifact

A clickable mockup, a landing page, and a technical spike can all look like progress while answering different questions. Choose among them only after discovery has produced one belief that could change what you do next.

Write five lines before entering the tree:

Decision I need to make:
Assumption that could make it wrong:
Audience whose behavior or constraints count:
Result that would support, change, or stop the direction:
What this test cannot prove:

If the audience is still “potential users,” the assumption is “people will like it,” or no plausible result would alter the plan, stop. Return to discovery. A prototype cannot rescue a question that has no consequence.

Choose the Evidence the Decision Requires

Start with the first branch that could expose the risky belief. Do not combine branches merely to make the prototype feel complete.

Do You Need Evidence of Interest or Commitment?

If the uncertainty is whether a specific audience notices the problem, understands the promise, or will take a costly next step, keep the product mostly out of the test.

Use a conversation or offer when you need to hear how the person describes the problem and whether they will share data, introduce a buyer, schedule a working session, or discuss a pilot. Use a sample output or static sketch when the promise is too abstract without something concrete to react to. Use a landing page when channel, message, and qualified response are the question.

Ask for the commitment that matches the belief. An email address can support a message test; it cannot establish repeat use or willingness to pay. If a paid pilot is the decision, make a paid-pilot ask rather than treating praise as a proxy.

Must the Person Understand or Complete an Interaction?

If sequence, labels, input, or the first value moment could defeat the idea, the participant must encounter the workflow rather than discuss it.

Begin with a paper flow, static screens, or sample input and output. Move to a clickable prototype only when clicking, choosing, correcting, or recovering is part of the evidence. Give the participant a task and withhold coaching long enough to see where the design depends on explanation.

This branch can show that a person understands and can operate the proposed interaction. It does not show that the problem is urgent, that the buyer will pay, or that the person will return.

Must the Idea Survive Real Work or Repeat Use?

If the risky belief concerns workflow fit, trust, recurring value, founder effort, or behavior over time, place a narrow version of the outcome inside the real cadence of the work.

Use a manual service or concierge prototype when the founder can deliver the result honestly and needs to observe inputs, exceptions, corrections, handoffs, and requests for another run. Add a spreadsheet, no-code flow, or small script only when repeated state or a fragile handoff is preventing the test. Use a Wizard-of-Oz experience only when concealing some manual operation is necessary for realistic interaction and does not mislead anyone about human review, privacy, safety, compliance, or capability.

Move to a narrow coded prototype when self-service behavior, a real integration, production data, payment, permissions, or reliability is itself part of the question. Build only the behavior required to make that evidence credible. Authentication, recovery, and support are not optional polish when the test creates real trust or harm exposure.

Is the Uncertainty Technical Rather Than Behavioral?

If no customer action can answer whether the essential mechanism works, isolate the mechanism.

Use an API mock to test a contract and its failure cases, a script or technical spike to measure one integration or algorithmic constraint, or a representative test set to examine an AI-assisted step under normal, ambiguous, and poor-quality inputs. State the threshold and the product decision it controls before running the work. Give the prototype throwaway boundaries so a successful experiment does not drift into production by inertia.

A feasibility result proves only the bounded mechanism. It does not prove customer pull, workflow fit, trust, margins, or operability unless those were separately observed.

Apply Two Fidelity Tests

Before building, test the chosen shape in both directions.

It is too thin if the participant must imagine the behavior that decides the question. A static dashboard cannot reveal whether an account manager will trust a digest enough to send it. A toy input cannot reveal whether a parser survives the records customers actually have.

It is too thick if a component cannot change the decision. Billing, a design system, general-purpose data models, and production infrastructure do not belong in a test of whether one manually prepared digest is worth repeating.

The right prototype contains enough reality for honest behavior and no completeness for its own sake.

Declare the Reading Before the Run

Turn the five opening lines into an interpretation rule:

Prototype shape:
Real behavior or technical result I will observe:
Support signal — if this happens, I will:
Change signal — if this happens, I will:
Stop signal — if this happens, I will:
Safety, privacy, and trust boundaries:
Founder interventions I will record:
Parts deliberately left manual or absent:

For a weekly client-update idea, the founder might choose one manually prepared digest from real notes. Sending it with limited correction and asking for another run could support a paid manual pilot. Rewriting most of it could change the promised output. Refusing the inputs or not using the digest could stop the direction. A dashboard, automated ingestion, and durable architecture would remain absent because none is needed to read that result.

Run the test, record behavior as well as comments, and finish one sentence: Because of this evidence, I will… If the sentence does not change the next action, the prototype was detached from a decision.

Choose the lightest prototype that makes the decisive behavior or mechanism real. Spend more engineering only when the missing realism prevents an honest answer.