01
Start with a hypothesis
Write what you believe, who it is for, and what evidence would change your mind.
Validation pages / 01
Make the idea testable before the build is expensive.
Turn a product idea into real signal.
A small, honest page for the people who might actually want the thing.
Attach a public page to an experiment, explain the job clearly, collect qualified responses, and keep the evidence connected to the decision that follows.
- Fake door, waitlist, prototype, and concierge tests
- No account required for respondents
- Responses flow back into the Product Graph
A validation experiment page turning audience responses into product evidence
The moment it is for
When the roadmap is full of maybes, test one clearly.
A feature request is not a demand signal, and a click is not proof. Validation Pages give the idea a surface where people can understand it, respond in their own words, and show whether the job matters enough to pursue.
Start with a question
“Would product teams ask for a calm answer to why signups changed?”
HypothesisAudiencePublic pageResponses
Input can be a metric question, a customer complaint, a pasted note, or a pattern you cannot explain yet.
Specky returns
A decision-ready experiment signal
- Qualified intent, not just page traffic
- The language people use to describe the job
- A clear continue, change, investigate, or stop decision
01
Frame
State the belief and the decision it should unlock.
02
Publish
Give the right audience one clear next action.
03
Listen
Capture context with the click, not just the click.
04
Learn
Attach the response to the experiment and decide.
What goes in / what comes out
A page is useful when the decision is clear.
Specky keeps the test small enough to run and structured enough to learn from. You decide what counts as evidence; the page makes it easier to collect.
You give Specky
- An experiment hypothesis and method
- The audience and problem you want to test
- Success or kill criteria, if you have them
- The decision this test should unlock
Specky gives back
- A structured, editable page and shareable URL
- A focused CTA with no account required
- Views, visitors, clicks, starts, responses, and conversion
- Variant rates, 95% confidence intervals, sample readiness, segments, and guardrails
- Response language linked back to the experiment
- An optional GitHub branch with a working fake-door artifact
A four-step learning loop
From a belief to a better next move.
The page is the front door. The experiment and Product Graph keep the learning from disappearing after the campaign ends.
02
Make it concrete
Specky drafts a page with a clear job, honest benefits, a small visual, and one next action.
03
Invite a response
Share the page with the people who actually experience the problem. Ask for context, not applause.
04
Decide with the signal
Read the numbers alongside the words, then continue, change, investigate, or stop.
A concrete example
“Signups are down.”
Is this worth solving?
A growth team can test the job before building another dashboard, workflow, or integration.
- 1Create a fake-door experiment around an evidence brief for signup drops.
- 2Edit the page so the audience, promise, and CTA match the real buyer.
- 3Share it with product leaders who have recently investigated a funnel change.
- 4Compare qualified requests with the words people use to explain the pain.
- 5Decide whether to build, interview more, narrow the job, or stop.
Early access experimentLive
1 experiment · 1 clear next stepresponses become evidence
Two ways to run the test
Keep it hosted. Or let your repo carry the first version.
The fastest path is a shareable Specky URL. When the idea needs to feel real inside your product, deliver the same test into a reviewable GitHub branch without losing the response trail.
Hosted validation page
Publish one honest URL, share it with qualified people, and collect the click plus the reason behind it. No engineering handoff is needed to learn.
Best for: a fast signal, a waitlist, or a focused audience test.
Repo-native fake door
Create a specky/validation/… branch with a polished static page, manifest, and README. Review it internally or open a draft PR before wiring it into your product.
Best for: testing the idea in the real product context without pretending it is built.
The page is not the verdict.
It is a better question. Specky keeps the page, event metrics, response language, experiment hypothesis, and follow-up decision in one connected loop — so “we should build this” becomes something your team can inspect.
Questions
Validation pages, plainly explained
Is this only for fake-door tests?
No. A page can support fake-door, waitlist, feature-interest, concierge, and prototype tests. The page type changes the CTA and response flow, while the experiment remains the source of truth.
What does a respondent see?
They see a focused page explaining the problem, the idea being explored, what participation involves, and one clear call to action. They do not need a Specky account.
Does Specky claim that the idea is already validated?
No. Generated copy is deliberately framed as an experiment. The page makes the promise testable without inventing customer proof, traction, or product capabilities that do not exist yet.
What happens to the responses?
Specky records page events and responses, attaches the response language to the experiment in the Product Graph, and lets you complete the experiment so the result can inform assumptions, opportunities, decisions, and outcomes.
Can I compare different versions of the idea?
Yes. Set a control and up to five active variants. Specky assigns a visitor consistently, compares response conversion with Wilson confidence intervals, shows how much sample is still needed, and keeps the read marked not ready when the evidence is too small. You can also inspect privacy-safe UTM source and medium cuts and configure a guardrail floor.
Can I put the validation test in my product repository?
Yes. After publishing the hosted page, Specky can create or update a specky/validation/... branch in your connected GitHub repository. The branch includes a working static fake-door page, a validation manifest, and a README explaining the test. The CTA still points to the hosted page so responses stay connected to the experiment.
Does repository delivery change my application?
No. The first delivery is a self-contained, framework-neutral artifact for review and preview. It does not add dependencies or change your routes. You can move the page into your application when the copy and test design are ready, or open a draft PR for engineering review.
Give the next idea a fair test.
Connect the experiment to the people who can teach you something, then let the evidence decide how much you build.