Editorial guide
How to Validate a SaaS Idea Before You Build
A practical framework for turning an idea into a small, testable claim — and for deciding in advance what result would make you stop. It is a general method you can run with any tool, including a spreadsheet.
1. Separate a problem from a hypothesis
A problem is something a specific group of people already works around, pays for, or complains about. A hypothesis is your guess about who has that problem and why. Write them as two different lines. If you cannot describe the problem without naming your solution, you have written a hypothesis.
- Problem statement: who is stuck, doing what, and what it costs them.
- Hypothesis: your causal claim that a different approach would help.
- Evidence you trust: something you can point to that exists today, independent of your opinion.
Prefer evidence you can inspect yourself over second-hand summaries. If you cite an external figure, link the first-party source (the company page, filing, or official statistic), not a blog that repeats it. Do not repeat a number you have not opened.
2. Weigh the alternatives
Your idea competes with whatever people use now. That includes doing nothing, a spreadsheet, an agency, or an incumbent tool. List the real alternatives and note why someone might keep them. An idea with no credible alternative usually means you have not looked hard enough.
3. Name the payer
The person with the problem and the person who approves spending may be different people. Write down who pays, from which budget, and what they would stop paying for to fund this. If the payer is unclear, the idea is unvalidated regardless of how much the user likes it.
4. Run a small validation test
Design the smallest test that could prove you wrong. Prefer a test that costs little and returns a signal you can measure, such as a set of interviews with a clear question, a landing page with a specific call-to-action, or a manual concierge run for one customer.
- State the claim being tested in one sentence.
- State the observable result that would support it.
- State the observable result that would refute it.
- Record what actually happened, including results you dislike.
Hypothetical example (illustrative only — not observed data)
The numbers below are made-up shapes to show the difference between a weak signal and a decision rule. No real customer, revenue, or outcome is described.
Claim: small agencies lose billable hours reconciling client feedback that is scattered across email threads.
Weak signal: a landing page gets “some” traffic and “some” sign-ups, so any result can be read as encouragement. There is no rule for what would make you stop, so the test cannot refute the claim.
Stronger test: send one specific offer to 20 named agency owners and count how many book a 15-minute call. Decide first: fewer than five bookings by a set date means this offer did not reach enough of this group to justify the next step. Booking a call measures willingness to discuss the problem, not willingness to pay. The number and the date exist before the results arrive.
5. Set failure criteria in advance
Decide before you start what outcome means stop. Written in advance, failure criteria help you notice when you are rationalising weak results. Keep them concrete: a number, a date, and a decision. “Not enough interest” is not a criterion; “fewer than five of twenty qualified conversations confirm the problem by this date” is.
6. Worksheet (blank)
Leave this blank until you have real information to enter. Write on screen or on paper. Prefer a plain file? Download the same worksheet as a text template:
Download the worksheet template (plain text)
Problem
Who is stuck, doing what, at what cost
Hypothesis
Your causal claim
Evidence
Source + link, or an observation you made
Alternatives people use today
Nothing, spreadsheet, agency, incumbent
Why they might keep the alternative
Who pays
Role and budget
Smallest test
What you will do
Supporting result
Observable
Refuting result
Observable
Failure criterion
Number + date
Actual result
Record honestly
Decision
Continue / change / stop
Where SaaS Idea Finder fits
SaaS Idea Finder can help you collect candidate market problems and save the ones you want to revisit, so the ideas you test stay in one place. It does not replace steps 4 and 5: it runs no test and sets no failure criterion for you.
Questions or corrections about this guide are welcome at [email protected].