Before you invest months in a new feature or product, you need to know which beliefs it depends on and what evidence would change your mind. A product validation workshop helps a cross-functional team turn a proposed solution into a focused learning plan.
The crucial distinction: The workshop does not validate an idea. It surfaces assumptions and designs tests. Validation is the process of gathering real evidence and assessing what the evidence supports, with all its limitations. A passing test does not prove that a whole product will succeed.
This guide stands on its own. The linked exercises come from Learning Loop's public Workshop Patterns and Validation Patterns libraries. You do not need to purchase cards to run it.
Take a complete experiment brief into the room
Use a printable worksheet to record the proposed solution, critical assumptions, falsifiable hypothesis, experiment design, evidence threshold and learning decision. Its ruled writing areas remain visible in print.
Open the validation workshop worksheet βWhat does it mean to validate a product idea?
Product discovery is about learning which customer problems matter. Product validation investigates whether a particular proposed solution could address a meaningful problem under realistic conditions. If the customer problem itself is unclear, start with the Product Discovery Workshop guide instead.
| Uncertainty | Question | Potential evidence |
|---|---|---|
| Desirability | Will customers care enough to take meaningful action? | Observed behavior, credible commitment, demand tests |
| Usability | Can people understand and use the solution? | Realistic task observations on a prototype |
| Feasibility | Can the team make the solution work within constraints? | Technical spike, integration proof, operational trial |
| Viability | Can the organization sustain the value delivered? | Costs, commercial commitments, operational economics |
These dimensions help you ask sharper questions, but they are not boxes to tick once. A quick prototype might support usability without answering whether enough people want the product. A fake-door test might indicate interest without showing that people would succeed using the finished service.
When is a validation workshop the right tool?
Run one when the team has a real customer opportunity and a solution idea but is about to invest in building based mainly on untested beliefs. It is useful when different functions assume different things must be true, when a roadmap feature has never been tested, or when the team needs to decide what evidence would justify a larger investment.
Skip or postpone it if you have no evidence that the customer problem matters. Talk to customers first. Also skip the workshop when a small existing test can already answer the question. Collaboration is valuable when it changes the quality of the decision, not as a ritual.
Prepare the workshop
Ask a product manager, designer and engineer to participate, together with relevant research, data or commercial colleagues. Name a facilitator, an experiment owner and a decision owner. A small cross-functional group often works better than a large approval meeting.
- Send a one-page pre-read. Include the customer group, observed problem, proposed solution, desired outcome and evidence collected so far. Separate research observations from interpretations.
- Set the investment boundary. Specify what would be built if the hypothesis holds and what spending or commitments should wait for evidence.
- Gather existing constraints. Note security, accessibility, participant recruitment, technical and operational limitations.
- Prepare an experiment board. Set up spaces for assumptions, evidence, importance, hypotheses, test ideas, success criteria, safeguards and next actions.
- Avoid an implicit success vote. Make clear that the workshop is allowed to recommend revising or stopping an idea. The purpose is learning, not selling the proposal.
How to facilitate a validation workshop, step by step
These are lightweight activities for one workshop, not a claim that all four full-length plays can fit into 90 minutes. Use the detailed exercises from the Workshop Patterns collection when the team needs a deeper session.
Step 1: Frame the idea and intended outcome (15 min)
Name the customer, the problem, the outcome and a possible solution. Explain what existing evidence supports the customer problem. If that evidence is absent, return to discovery before treating solution validation as the next step.
Step 2: Surface solution assumptions (20 min)
List the critical conditions that must hold for this proposed solution to succeed. Think about desirability, usability, feasibility and viability, but keep the conversation in the solution space. Assumptions Mapping is more useful upstream for discovery of customer problems, so do not make it a required step here.
Step 3: Pick the riskiest assumption (15 min)
Discuss both importance and evidence strength. Favor an assumption that could invalidate or substantially change the proposed direction and for which reliable evidence is missing. Do not choose something trivial simply because it is easy to confirm.
Step 4: Design a test that could change your mind (25 min)
Write the hypothesis with Hypothesis Statement, then explore tests through Experiment Ideation or How Might We Experiment. Specify participants, procedure, measure, alternatives and how the test could fail.
Step 5: Agree on the evidence and decision plan (15 min)
Predefine a reasonable evidence threshold, the limits of the sample, safeguards and the owner. Record when results will be reviewed and what would lead to continuing, revising or abandoning the idea. A workshop creates a plan, not proof.
Example agendas for different situations
90-minute decision workshop
| Time | Activity | Expected output |
|---|---|---|
| 0 to 15 min | Frame proposed solution and desired outcome. | A shared hypothesis context. |
| 15 to 35 min | Identify assumptions about the solution. | Visible assumption list. |
| 35 to 50 min | Select the riskiest assumption. | Chosen focus assumption. |
| 50 to 75 min | Define a hypothesis and shortlist suitable tests. | A practical experiment design. |
| 75 to 90 min | Set evidence threshold, owner, safeguards and review. | Decision-ready learning plan. |
This short session assumes the customer problem is already supported by research. If participants disagree about the underlying opportunity, stop and return to discovery before engineering a solution test.
Half-day experiment design workshop
| Time | Activity | Expected output |
|---|---|---|
| 0 to 30 min | Review problem evidence, solution idea and intended outcome. | Shared decision frame. |
| 30 to 80 min | List the assumptions behind the proposed solution and organize them by desirability, usability, feasibility and viability. | Assumption map. |
| 80 to 110 min | Discuss importance and evidence; choose a focus. | Selected critical unknown. |
| 110 to 125 min | Break. | Time to reflect. |
| 125 to 165 min | Write a testable hypothesis and generate experiment options. | Hypothesis and possible methods. |
| 165 to 210 min | Evaluate feasibility, signal strength, ethics and confounders. | Detailed experiment design. |
| 210 to 240 min | Agree on measurement, decision criteria, owner and review date. | Runnable test brief. |
The complete duration of a play may exceed its slot in either sample agenda. Adapt the depth or split work into multiple sessions rather than pretending that time estimates don't matter.
Workshop exercises for designing validation tests
These exercises are available in Learning Loop's Workshop Patterns library. They help teams create a better experiment plan; the actual user-facing tests are described in the separate Validation Patterns library.
Hypothesis Statement
Convert an assumption into a statement that can be challenged with evidence.
Full play: 30 to 45 minutes
How Might We Experiment
Turn a validation challenge into several possible test approaches.
Full play: 30 to 45 minutes
Experiment Ideation
Explore experiment patterns and choose an informative, proportionate test.
Full play: 15 to 30 minutes
How to select the right validation experiment
Test a solution hypothesis, not just explore a customer problem. Here, favor evaluative experiments that expose a proposed solution to customer behavior. The Validation Patterns playbook contains many more experiment methods, helping teams choose a proportionate test for the riskiest assumption: the one that, if false, makes the rest of the plan irrelevant.
| Solution hypothesis | Evaluative experiment | What the signal cannot establish alone |
|---|---|---|
| Customers will show real interest in a proposed feature | Fake Door Testing, with a clear follow-up explanation | Sustained usage or delivered customer value |
| The proposed offer appeals strongly enough to prompt action | Spoof Landing Pages, tracking meaningful intent or commitment | Actual product satisfaction or retention |
| The proposed value proposition resonates with a target audience | Run Test Ads, with appropriate audience targeting and tracking | Willingness to pay or product usability |
| Users can successfully achieve their goal with the design | Clickable Prototype with realistic task testing | Long-term engagement or business viability |
| A proposed service can deliver value before automation | Concierge or Wizard of Oz trial, with clear safeguards | Technical scalability or sustainable unit economics |
Some tests, especially fake-door or concierge approaches, can disappoint or mislead users if done carelessly. Avoid undisclosed charges, deceptive promises or inaccessible flows. Clearly explain the status of a concept when appropriate, obtain meaningful consent where necessary, and make sure any test is proportionate to the possible harm.
Worked example: should we build a guided onboarding assistant?
Starting point: The discovery team has observed that some new users cannot complete their first project because they do not know which information is required. The proposed solution is a guided assistant that explains each setup step. This is an illustrative scenario, not a reported customer result.
- Separate problem from solution. The problem may be real, but the team has not demonstrated that an assistant is the best remedy. Simpler labels or a clearer setup sequence might be better.
- Map assumptions. The team believes users would understand the assistant, trust its guidance, and complete setup with fewer errors. It also assumes the assistant can provide accurate instructions under realistic constraints.
- Choose the critical assumption. If users cannot complete a task with a guided experience, the concept's main promise is weak. The team selects that usability and value assumption rather than starting with engagement metrics.
- Write a falsifiable hypothesis. βAmong new users attempting setup with realistic account information, the guided prototype will improve completion compared with the current flow without increasing substantive errors.β Define what meaningful improvement would be before testing.
- Design the experiment. Recruit participants resembling the intended users. Have them attempt the same realistic task in a prototype and comparison flow, counterbalancing order where feasible. Record successful completion, errors, confusion and follow-up explanation.
- Make the decision. If guided instructions improve completion and do not add harmful errors, the team may invest in a limited build. If both approaches fail or users need different information, revisit the problem and try a new direction.
Example experiment card
We believe: New users fail setup mainly because instructions are unclear, and guided instructions can reduce that friction.
To test it: Observe representative users attempting the same task with an interactive guided prototype and the current flow.
We will measure: Task completion, meaningful errors, user confusion and time needed, interpreted together.
Before running: Define participant criteria, a minimally useful change, acceptable error bounds and how results will be reviewed.
Afterward: Continue, change the concept or seek more evidence, based on the observed pattern and sample limitations.
How to interpret the evidence after the workshop
Record the result without retrofitting the success criteria to make a disappointing test look positive. A small, poorly recruited sample cannot justify a sweeping conclusion. Equally, a weak signal can still save the team money by revealing questions for a better next experiment.
Continue
Important evidence supports the tested assumption, within known limits. Invest cautiously in the next increment.
Revise
Evidence suggests a different user, need, design or mechanism. Change the hypothesis or solution and test again.
Stop or revisit
A critical assumption fails or the problem is less important than expected. Return to opportunity discovery or abandon the direction.
The team's learning log should include the original hypothesis, exposure and participant details, actual observations, confounding factors, decision and next review. Learning Loop already provides a Experiment Sheet resource (available after submitting the form) alongside the new workshop worksheet.
Common validation mistakes and what to do instead
| Mistake | Better practice |
|---|---|
| Testing whether people say they like an idea. | Observe realistic behavior or credible commitments where possible. |
| Calling prototype usability tests proof of market demand. | State exactly which assumption the test addresses and what it leaves unanswered. |
| Choosing success criteria after seeing results. | Agree on measures and decision thresholds before running the test. |
| Testing a convenient assumption instead of a critical one. | Prioritize beliefs that could invalidate a meaningful investment. |
| Running an experiment without ethical review. | Consider consent, deception, privacy, accessibility and potential harm. |
| Declaring an entire idea validated after one positive test. | Use calibrated language such as βthis result supports the tested assumption for this group.β |
| Leaving the workshop with no owner. | Record responsibility, schedule, recruiting plan and decision review. |
Frequently asked questions
How many assumptions should we test at once?
For a short workshop, pick one consequential assumption and design one informative next test. Multiple studies can run in parallel when the team has capacity, but each should have a clear question and interpretation plan.
How much evidence is enough to validate an idea?
There is no universal sample size or score. It depends on the consequence of being wrong, the type of evidence, the variability of behavior and what investment you're about to make. Use more rigorous methods when the stakes are higher.
Can we validate an idea without building software?
Often, yes. Interviews, prototypes, operational simulations, technical spikes and carefully designed demand tests can reduce important uncertainties before a full implementation.
What is the difference between discovery and validation?
Discovery investigates customer problems and opportunities. Validation challenges assumptions about particular solutions, experiences or business approaches. Teams move between both as they learn.
Do we need a card deck?
No. The linked plays and worksheet are enough to get started. A deck can make a wider set of experiment methods and collaborative exercises easier to browse during recurring team work.
Further reading and sources
- David J Bland on Assumptions Mapping, for identifying what to test.
- How to Run a Product Discovery Workshop, for the preceding problem-discovery stage.
- Validation Patterns playbook, for experiments and validation techniques.
Make experimentation more repeatable
The Validation Patterns card deck brings together different experiment methods and tailored workshop exercise cards, supporting teams as they choose and run the right tests. It is an optional toolkit rather than a requirement to follow this guide.
Explore Validation Patterns β