Prepare a demand test for a new offer
Bring market evidence, an initial program concept, and an existing design system together into a landing-page experiment.
How this works
Bring market evidence, an initial program concept, and an existing design system together into a landing-page experiment. A demand-test page should make a truthful offer and collect an interpretable signal about interest. A polished landing page cannot validate demand if the audience is wrong, the offer is vague, or a signup is mistaken for willingness to pay.
Use research to frame one testable offer, build a focused page with the existing design system, and verify the lead path. Define the experiment before traffic arrives. Clearly describe availability when the offer is a concept, waitlist, or pilot rather than an existing service.
Before you start
Offer hypothesis
State audience, problem, proposed result, and unresolved assumptions.
Research evidence
Collect concrete demand signals and current alternatives.
Test authorization
Define traffic source, exposure limits, and what may be published.
Prepare the inputs
- offer_outline
- Required
Scope and availability
Avoid presenting a planned service as already delivered.
- audience
- Required
Specific buyer situation
Identify how test visitors will be reached.
- evidence
- Required
Observed needs and alternatives
Keep enthusiasm separate from behavior.
- page_requirements
- Required
Copy, design, and form
Use the maintained brand and integration rules.
- experiment_plan
- Required
Metrics and decision criteria
Define denominators and follow-up window.
Implementation, step by step
Frame the demand question
- Identify the behavior that would reduce uncertainty about the offer.
- Choose a signal stronger than page views when the decision concerns buying intent.
Checkpoint: A testable hypothesis.
Draft a truthful proposition
- Explain the audience problem, proposed scope, and current availability.
- Keep unbuilt features and unmeasured outcomes clearly labeled.
Checkpoint: An approved offer brief.
Design the focused page
- Create one clear narrative and primary action using the existing design system.
- Include enough detail for an informed response without manufacturing urgency.
Checkpoint: A page prototype.
Implement and verify capture
- Connect the approved lead destination or prepare a local test implementation.
- Test valid, invalid, duplicate, and failed submissions and inspect actual receipts.
Checkpoint: A verified visitor-to-lead path.
Prepare the experiment
- Set traffic allocation, observation period, and the interpretation of each event.
- Keep signup, qualified interest, and payment commitments separate.
Checkpoint: A bounded launch plan.
Read results against the hypothesis
- Compare observed behavior with the pre-agreed criteria and sample limits.
- Use objections and drop-off evidence to refine the offer rather than declaring success from a few clicks.
Checkpoint: A demand-test decision note.
Decisions along the way
The offer is not yet available
Use an honest pilot or waitlist description.
Traffic differs from the intended buyer
Treat results as a targeting problem or limited sample.
Visitors sign up but reject the actual scope
Revise the proposition instead of counting all signups as validated demand.
What you will produce
demand-test-page
Project or page draftA truthful test asset.
Include: offer_version · availability · form_contract · event_plan
demand-test-readout.md
MarkdownSupports the next commitment.
Include: hypothesis · traffic · events · qualified_signal · limits · next_decision
Check the result
- Verify availability and claims match reality.
- Test complete lead delivery and error states.
- Check analytics distinguish funnel stages.
- Confirm the result is compared with criteria set before the test.
When something goes wrong
Form success has no lead receipt
Repair the integration before traffic.
The page implies guaranteed outcomes
Replace them with supported scope and conditions.
Several offers change during the test
Separate versions and avoid pooling incompatible observations.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Test interest in a new operations workshop.
Inputs
Synthetic example. Synthetic page offers a planned pilot with a waitlist; 40 visitors produce 8 signups, but only 2 confirm the proposed date.
Expected result
Synthetic expected result. Report 8 signups and 2 date-compatible prospects separately. Do not call all 8 paying customers or claim the workshop already exists.
Run a small pilot
Start small
One offer, one audience, and a capped traffic window.
Record the baseline
Record current alternatives and the effort required to assess interest manually.
Agree success criteria
Agree the qualified behavior needed for the next investment.
Stop or revise
Stop traffic for misleading availability, broken capture, or unapproved spending.
Keep the scope clear
- A prototype does not authorize publication or buying traffic.
- Do not collect payment or send follow-ups outside the approved experiment.
Check before using
Make availability and offer terms clear. Interest or lead volume is not proof of willingness to pay or successful delivery.
Business activities
- Handle inbound enquiries
- 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: Market or vacancy research · Proposed offer and target audience · Design system and test plan
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow