Testing a product idea is not a branding exercise. It is a risk-reduction exercise. The goal is not to prove that the idea is brilliant; the goal is to learn, quickly and cheaply, whether real people care enough to pay attention, sign up, click, pre-order, or talk to you about it.
Most product failures happen before the product is finished. Teams spend too long refining features, naming packages, polishing visuals, or arguing over edge cases before they have evidence that the idea solves a real problem. The fix is not to test everything. The fix is to test the right questions in the right order.
Rick Kettner’s approach is useful because it keeps the process practical: define the idea, expose it to real people, and look for evidence of demand before you build too much. That is the core of product validation. The rest is just choosing the cheapest experiment that can answer your next question.
What you are trying to learn
A good product test does not try to answer every question at once. It should tell you one of these things:
- Do people recognize the problem?
- Do they care enough to keep paying attention?
- Do they understand the proposed solution?
- Do they want it enough to take a low-friction action?
- Would they pay, preorder, or at least give you a strong signal of intent?
If you try to answer all of those with one test, the data gets muddy. A landing page might measure curiosity, but not payment intent. An interview might reveal pain points, but not actual click behavior. A prototype might show usability, but not whether the market is large enough.
The trick is to stage your testing so each step removes a specific layer of uncertainty.
A simple testing ladder
| Step | What you test | Best signal | Main risk |
|---|---|---|---|
| 1 | Problem awareness | People immediately recognize the pain | You are solving a non-urgent issue |
| 2 | Solution clarity | People understand the idea without coaching | The offer is confusing or too broad |
| 3 | Demand | People click, sign up, or request access | Interest is only polite curiosity |
| 4 | Payment intent | People pre-order or commit money | You built hype without value |
| 5 | Delivery | Early users get results from the product | The concept was right, but the execution was weak |
Use the ladder in order. Do not jump to building a full product when the first step still has holes.
Start with the problem, not the feature
Many founders describe their product in terms of features. That is usually the wrong starting point. Features are easy to invent and hard to validate. Problems are what customers actually feel.
A better test starts with this question: what painful, expensive, repetitive, or embarrassing situation does the product remove?
For example:
- Instead of “AI dashboard for freelancers,” test “freelancers waste hours turning client notes into invoices and updates.”
- Instead of “premium meal planner app,” test “busy parents struggle to decide what to cook every night.”
- Instead of “smart home organizer,” test “people lose track of tools, cables, and household gear.”
This framing helps because it makes your test more concrete. People respond more honestly to a problem than to a polished pitch.
The cheapest ways to test a product idea
You do not need a full product to get useful data. Start with the least expensive version of the idea that can still produce a real response.
1. Customer interviews
Talk to people who match your target user. Keep the conversation focused on their current behavior, not your solution.
Ask:
- How do you handle this today?
- What is the most frustrating part?
- What have you already tried?
- What happens if you do nothing?
- What would be worth paying to fix?
Do not lead with a pitch. If people only like the idea after you explain it for five minutes, the concept may be too weak or too dependent on your personal enthusiasm.
2. Smoke test landing page
Create a simple page with one clear promise, a brief explanation, and one call to action. The action could be joining a waitlist, requesting a demo, or pre-ordering.
This is one of the strongest early tests because it measures behavior, not compliments.
A good smoke test page should have:
- A headline focused on the outcome
- A short description of the pain point and solution
- One primary call to action
- Minimal navigation
- A believable reason to act now
If visitors land on the page and do nothing, you may not have a demand problem. You may have a message problem. Test different wording before assuming the market is uninterested.
3. Click test ads
If you already know where your audience hangs out, a small ad budget can test whether your message gets attention. You are not trying to scale. You are trying to see whether a specific promise earns clicks from the right people.
Low click-through rates may mean the audience is wrong, the offer is weak, or the headline is too vague. Strong clicks but weak signups often mean the landing page is not carrying its weight.
4. Manual concierge MVP
Before automating the product, do the work by hand. If the idea is a workflow tool, run the workflow manually for a few users. If the idea is a service marketplace, match people manually. If the idea is a reporting tool, generate reports yourself.
This method is powerful because it tests whether users actually value the result, not whether they like your software architecture.
5. Pre-sell or waitlist with commitment
The strongest signal is money. If someone pays, reserves, or commits to a next step with real friction, you have something more meaningful than a like or an email signup.
Even a small payment tells you more than a thousand casual page views. A pre-sell forces clarity around value, pricing, and urgency.
What makes a test trustworthy
A product test is only useful if the signal is clean. That means avoiding common mistakes that inflate optimism.
Watch out for these problems
- Friends and family saying nice things without real intent
- Asking leading questions that invite approval instead of truth
- Testing too many ideas at once
- Changing the pitch every five minutes and treating each version as separate proof
- Interpreting curiosity as demand
- Mistaking a broad audience for a paying audience
A weak test can still be useful if it teaches you something specific. For instance, if people understand the pain point but ignore the offer, that tells you the framing or the channel is wrong. If they sign up but do not activate, the promise may be too vague or the product may not deliver quickly enough.
A practical validation workflow
Use this sequence when you are starting from scratch:
- Write the problem in one sentence.
- Identify the exact audience that feels that pain most often.
- Draft one simple promise for the solution.
- Run 5 to 10 short customer conversations.
- Turn the best wording into a landing page.
- Drive a small amount of targeted traffic.
- Ask for the next commitment, not just interest.
- Review the results and revise only one major variable at a time.
That sequence keeps you honest. It also prevents overbuilding. Once you have a signal, you can decide whether to improve the offer, narrow the audience, or kill the idea.
How to read the results
Not every result is a yes-or-no answer. Often the real value is in understanding the type of demand you have.
| Signal | Likely meaning | Next move |
|---|---|---|
| People say the problem is real | Pain exists | Narrow the audience and clarify the value |
| People click but do not sign up | Message is interesting but not convincing | Improve the offer and CTA |
| People sign up but do not pay | Interest is real, commitment is weak | Add proof, urgency, or a stronger promise |
| People pay early | Strong validation | Build the simplest version that delivers the result |
| People use it once and leave | Product misses the workflow | Rework the core use case |
Avoid forcing a positive conclusion. A weak test result is not failure. It is a cheap correction.
What to build after a good test
Once you have evidence of demand, your next build should be the smallest version that can deliver the promised outcome. Do not turn validation into a reason to over-engineer.
If the test was a landing page, build the one workflow that fulfills the promise. If the test was a concierge service, automate only the manual steps that repeat. If the test was a waitlist, deliver a narrow first version to the most engaged users.
The fastest path is usually:
- Keep the audience narrow
- Keep the promise specific
- Keep the first version constrained
- Keep collecting feedback from users who actually took action
That is how a test becomes a product instead of a pile of opinions.
Final check before you commit
Before you spend real time or money, ask yourself three blunt questions:
- Can I describe the problem in plain language?
- Have I seen evidence from real people, not just friends or assumptions?
- Is the next step still cheaper than building the full thing?
If the answer to all three is yes, you are ready to move forward. If not, run one more small test.
The point of testing a product idea is not to delay building forever. The point is to earn the right to build with evidence instead of hope. A small, honest test now is almost always cheaper than a large, elegant mistake later.