Start with the decision, not the artifact
Write down the decision the team expects to make after the test. It could be whether to continue exploring a customer problem, narrow the product wedge, change a workflow, investigate a technical dependency, or stop investing in an assumption. If the decision is vague, teams tend to build a polished artifact that is interesting but does not settle anything.
Then write the uncertainty in one sentence. Separate market questions from product questions and technical questions. “Will this help?” is broad. “Can a first-time operator understand which record needs attention from this screen?” is testable through an interaction. “Can the system produce a useful draft from the available source material?” may require a technical proof with representative inputs. A venture can contain several uncertainties, but a single prototype should have a primary job.
Name the person who can answer the question and the context in which they would use the product. A demo shown to an internal team can reveal confusion in the story or workflow. It does not by itself establish what a target user will do in their own environment. Make the boundary of the evidence explicit so a demonstration is not mistaken for broader validation.
Choose the prototype form
A clickable prototype is useful when the team needs to inspect a sequence of screens, labels, choices, or handoffs. It can make an abstract concept discussable before implementation. It cannot demonstrate the reliability of an integration or prove that an underlying system can perform work that is only simulated. State which elements are illustrative and which are functional.
A technical prototype is useful when an important feasibility question depends on data access, model behavior, system integration, latency, permissions, or another engineering constraint. Keep it narrow. The aim is to learn about the named constraint, not to quietly turn a feasibility check into a production system. Use representative inputs and record where they differ from real operating conditions.
A working product slice gives a person the ability to attempt a bounded task. It can expose workflow friction that a storyboard cannot, but it also requires decisions about data, error handling, access, and support. Build only the slice needed to inspect the target behavior. Avoid adding breadth merely because the team has started implementation.
Some questions require a combination. A clickable flow can show the intended experience while a technical proof checks whether a critical action can happen. Keep the connection between the pieces visible: which part is simulated, which part was exercised, and what remains unresolved.
Build a test around observable behavior
Before showing the artifact, write a short test plan. Include the participant or internal role, the scenario, the task, what the team will observe, and the evidence that would change the decision. Avoid leading questions that invite agreement with the concept. Ask the person to explain what they think is happening, attempt the task, and describe what they would do next.
For a product demo, start with the user's situation and the task rather than a tour of features. Show the path from trigger to result. Pause where a meaningful choice occurs. If the product makes a recommendation, show the information that supports it and what a user can do if they disagree. A demo that only displays a polished outcome can conceal the difficult steps needed to produce it.
Record observations separately from interpretation. “The participant asked what this label meant” is an observation. “The user does not understand the market” is an interpretation. Keep the exact interaction, the team's explanation, and any follow-up question distinct. This makes it easier to revise the product hypothesis without overstating what one session establishes.
Turn the result into a next move
After the test, compare what happened with the decision criteria written in advance. Identify which assumption gained support, which remained open, and which was contradicted. If the test did not distinguish between explanations, improve the test rather than presenting an ambiguous result as confirmation.
The next step may be another targeted test, a narrower product wedge, a technical investigation, or a decision to stop. Tie each proposed step to a specific uncertainty. Keep a short record of the artifact, the scenario, the observations, the limits of the evidence, and the owner of the next decision. That record can help product, design, and engineering work from the same understanding.
A compact venture-prototype brief
Use a one-page brief with these fields: opportunity thesis; intended user and context; decision to make; primary uncertainty; prototype form; functional and simulated elements; test scenario; observable behavior; decision criteria; known evidence limits; and next-step owner. This is a working aid, not a substitute for customer research, technical review, or operating judgment.
A useful brief also says what the test will not establish. A prototype may help a team inspect a workflow or technical assumption while leaving adoption, repeat use, implementation effort, and business viability unresolved. Naming those limits protects the team from turning a useful learning artifact into a claim that it proved the whole venture.
When to bring in a partner
An external product partner can help when a team needs to translate a thesis into a product expression, make technical and product decisions together, or connect a prototype to a practical proof roadmap. GCG's Venture Prototyping service describes work for founders, operators, and investors exploring a company idea, product wedge, or market opportunity. Its Technical Product Strategy service describes the connection between product direction and technical decisions. The engagement should begin with the decision the team needs to make and the evidence it can realistically gather.
Questions founders ask
What is a venture prototype?
A venture prototype is the smallest credible product expression that can help a team make a decision about an opportunity. It may be a clickable flow, a technical proof, a working slice, or a combination.
When is a clickable prototype enough?
A clickable prototype is useful when the team needs to inspect a sequence of screens, labels, choices, or handoffs. It cannot demonstrate the reliability of an integration or prove that an underlying system can perform work that is only simulated.
Claim sources
| Claim | Source |
|---|---|
| GCG frames venture prototyping as moving from thesis to a product people can react to; listed scope includes opportunity mapping and a proof roadmap. | Live Venture Prototyping page, fetched 2026-11-10. |
| GCG's technical strategy work connects product direction and technical decisions. | Live Technical Product Strategy page, fetched 2026-11-10. |
| The distinction and test methods in this article are editorial recommendations, not claims of measured performance. | Editorial guidance; no outcome or performance claim. |