Use Stronger Signals Than Interest
Not every positive response carries the same weight.
This matters because early ideas often receive plenty of weak encouragement.
A useful evidence ladder might look like this:
Weak signal:
“That sounds cool.”
Stronger:
The person asks detailed questions.
Stronger:
They provide contact information for a relevant follow-up.
Stronger:
They schedule a call or demonstration.
Stronger:
They provide information required to begin.
Stronger:
They request a proposal.
Stronger:
They agree to a pilot.
Very strong:
They pay.
The closer the behavior gets to a real transaction, the more confidence you can place in it.
Article #5 covered this distinction in depth. Review How to Know Whether People Will Pay for Your Idea when deciding which signals matter most.
Do not count ten compliments as equivalent to one sale.
They answer different questions.
Define Success Before Running the Test
A test becomes much less useful when you decide what the results mean after seeing them.
Before starting, write down:
What are we testing?
Example:
“Will independent personal trainers pay $49 for this client-tracking spreadsheet?”
Who are we testing with?
“Independent trainers who currently manage at least ten active clients.”
What will we do?
“Show the offer to 30 qualified trainers through direct outreach and two trainer communities.”
What result would justify continuing?
“At least three paid buyers, plus useful feedback from qualified non-buyers.”
The exact threshold will depend on the business.
The important part is deciding what evidence you are seeking before emotions get involved.
Otherwise, almost any outcome can be rationalized.
Zero sales becomes:
“People loved the idea.”
Three uninterested conversations become:
“I just haven’t found the right audience yet.”
A clear test forces you to confront the result.
Track the Whole Funnel
Do not track only sales.
Sales are important, but the steps leading to them can diagnose the problem.
Suppose you contact 50 qualified prospects.
Twenty respond.
Ten want more information.
Five schedule calls.
Three request proposals.
Two buy.
That tells a story.
Now imagine:
You contact 50.
Two respond.
Nobody asks questions.
The problem may be targeting or messaging before pricing ever becomes relevant.
Or:
Thirty people visit the sales page.
Fifteen begin checkout.
Nobody completes payment.
That points somewhere different.
Track simple stages such as:
- people reached,
- responses,
- clicks,
- signups,
- conversations,
- proposals,
- trials,
- purchases,
- repeat purchases,
- cancellations,
- and referrals.
You do not need complicated analytics.
You need enough visibility to know where interest disappears.
Measure the Economics While the Test Is Small
A test can generate sales and still reveal a weak business.
Suppose your first service customer pays $400.
Good.
But delivery requires:
- 14 hours of work,
- $90 in software,
- three rounds of revisions,
- two hours of travel,
- and another three hours of unpaid communication.
The sale proves some willingness to pay.
It also reveals a delivery problem.
You may need to:
- raise the price,
- narrow the scope,
- create boundaries,
- improve the process,
- change the customer,
- automate part of the work,
- or abandon the model.
For a physical product, track:
- manufacturing,
- shipping,
- packaging,
- payment processing,
- returns,
- platform fees,
- and customer-acquisition costs.
For a digital product, delivery may be cheap, but distribution may not be.
For subscriptions, retention eventually becomes as important as acquisition.
Testing should begin teaching you whether the economics can work—not merely whether revenue can occur.
Do Not Use Free as Your Only Test
Free users can teach you about usability.
They cannot fully answer a pricing question.
Someone may happily accept:
- a free consultation,
- a free template,
- a free sample,
- a free trial,
- or free work.
That demonstrates some level of interest.
It does not prove willingness to pay.
Free testing can be appropriate when you specifically need to learn:
- whether people use something,
- where they get confused,
- whether the process works,
- or whether the result is valuable.
But if the central question is:
“Will customers pay?”
eventually the test needs a price.
Avoid Discounting Until the Test Becomes Meaningless
Introductory pricing can make sense.
Extreme discounts can distort the result.
Suppose you intend to sell a service for $500 but validate it by offering it for $25.
You have not learned whether customers will pay $500.
You have learned whether customers will pay $25.
Those are different markets.
A first version may reasonably be cheaper because:
- you have less proof,
- the scope is smaller,
- you are still improving delivery,
- or the customer accepts the limitations of a pilot.
That is different from reducing the price so dramatically that almost anyone would say yes.
Keep the test close enough to the intended economics to remain informative.
Make Sure You Can Actually Reach Customers
An idea can solve a real problem and still be difficult to turn into a business if customer acquisition is unrealistic.
Use the test to investigate distribution too.
Ask:
- Where did the first prospects come from?
- How difficult were they to reach?
- Did they respond to outreach?
- Were they already searching for a solution?
- Did referrals appear naturally?
- Did a marketplace provide useful access?
- Did content attract the right people?
- Did advertising become too expensive?
A business is not only an offer.
It is also a repeatable path between the offer and the customer.
Your first test does not need to prove that path at scale.
But it should begin revealing whether one exists.
Run More Than One Small Test When Necessary
One experiment is rarely the final verdict.
Your first version may teach you that the customer is right but the offer is wrong.
Or the problem is real but the price is wrong.
Or people buy but delivery is too expensive.
Or one customer segment responds far better than another.
That is why small tests are useful.
You can change one important variable and test again without rebuilding the entire company.
For example:
Test 1: General bookkeeping setup for freelancers.
Weak response.
Test 2: Bookkeeping cleanup specifically for newly self-employed therapists.
Much stronger response.
The underlying skill did not change much.
The customer and positioning did.
You may need several experiments before a clear pattern appears.
The key is that each test should teach you something specific.
Change One Major Variable at a Time
If you change everything at once, you may not know what caused the result.
Imagine Test 1 fails.
For Test 2 you simultaneously:
- change the customer,
- reduce the price,
- rename the service,
- change the deliverable,
- switch marketing channels,
- and rewrite the sales message.
Then Test 2 works.
What did you learn?
Not much.
You know the combination worked better.
You do not know why.
When practical, change the variable most likely causing the problem and observe what happens.
Business testing is not a perfect laboratory experiment.
Real markets are messy.
But disciplined iteration still produces better information than random changes.
