Test a business idea before committing to development
Assess demand, alternatives, distribution, and delivery risks before choosing a small validation experiment. Keep evidence of the problem separate from enthusiasm for a particular solution.
How this works
Assess demand, alternatives, distribution, and delivery risks before choosing a small validation experiment. Keep evidence of the problem separate from enthusiasm for a particular solution. Early evidence should clarify whether a painful, recurring problem exists before a team invests in its preferred solution. Compliments about an idea, broad market forecasts, and willingness to try something free are different signals from an actual purchase or repeated workaround.
Create a decision brief around the buyer's current behavior, alternatives, reachable distribution, and delivery constraints. Research can narrow uncertainty, but the next experiment should produce observable behavior. Keep a record of what would change the team's decision rather than accumulating supportive anecdotes.
Before you start
Decision to make
State the investment or next commitment under consideration.
Target user
Define a specific role and situation instead of a broad demographic.
Experiment boundary
Set available time, budget, and actions the team can actually perform.
Prepare the inputs
- problem_statement
- Required
Role, situation, consequence
Describe a problem without embedding the proposed solution.
- evidence
- Required
Interviews and behavior records
Separate direct observations from assumptions.
- alternatives
- Required
Current workarounds and offers
Include doing nothing.
- distribution_options
- Required
Reachable channels
Record access constraints and expected effort as assumptions.
- delivery_constraints
- Required
Operational limits
Identify the hardest unresolved dependency.
Implementation, step by step
Frame the decision
- Write the commitment being evaluated and the evidence that could reverse it.
- Separate user pain, buyer willingness, and delivery feasibility into different questions.
Checkpoint: A decision-focused research brief.
Examine current behavior
- Collect specific examples of how users handle the problem today.
- Look for frequency, consequence, effort, and existing spending without inventing missing values.
Checkpoint: A behavior evidence table.
Compare alternatives
- Research direct offers, manual workarounds, and the option of accepting the problem.
- Record comparable prices and constraints; public prices are not proof of demand.
Checkpoint: An alternatives map.
Test reach and feasibility
- Identify a realistic way to reach the buyer and the hardest delivery assumption.
- Avoid assuming a channel is available because similar companies advertise there.
Checkpoint: A list of critical uncertainties.
Design a small experiment
- Choose an action such as a paid pilot offer, observed task test, or structured interview.
- Define the signal, denominator, decision rule, and stopping condition before running it.
Checkpoint: A bounded validation plan.
Recommend the next commitment
- Summarize evidence for proceeding, testing further, or stopping.
- Keep unresolved assumptions visible and specify what the next result would change.
Checkpoint: A concise decision memo.
Decisions along the way
Interest exists but no costly action follows
Treat demand as unproven and test a stronger commitment.
Users have a cheap satisfactory workaround
Investigate a narrower underserved situation or stop.
Delivery depends on unavailable data
Test access before building a polished interface.
What you will produce
problem-evidence.csv
CSVKeeps learning traceable.
Include: question · observation · source · assumption · strength · next_test
validation-decision.md
MarkdownSupports a bounded investment choice.
Include: decision · alternatives · critical_risks · experiment · criteria
Check the result
- Verify evidence describes actual behavior where claimed.
- Keep price, demand, and total market estimates separate.
- Confirm the proposed experiment can falsify a key assumption.
- Avoid counting several statements from one interview as independent demand signals.
When something goes wrong
Research only finds supportive examples
Seek contrary cases and current non-buyers.
The experiment measures vanity engagement
Replace it with behavior closer to the decision.
Scope grows into a full product
Return to the smallest test of the critical assumption.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Decide whether to build a proposal-writing service.
Inputs
Synthetic example. Synthetic interviews show five teams rewrite proposals, but only one has paid for outside help. Two already use a satisfactory template.
Expected result
Synthetic expected result. Recommend testing a paid assisted proposal with the unsatisfied segment. Do not claim five paying customers or a validated subscription market.
Run a small pilot
Start small
One buyer situation and one critical assumption.
Record the baseline
Record current workaround time, spending, and consequences where observed.
Agree success criteria
Agree the behavior that would justify the next investment before the experiment.
Stop or revise
Stop or revise when the key access, willingness, or feasibility assumption fails.
Keep the scope clear
- Research does not authorize contacting prospects or charging them.
- Do not replace missing demand evidence with an invented market-size estimate.
Check before using
Check source quality and market calculations. Desk research cannot establish that customers will buy.
Business activities
- Research customers and markets
- Plan products and business changes
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: A specific customer problem · Proposed solution and target audience
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow