When testing an idea, you usually do not know what the final product should be yet.
That is the point of testing the market.
You may think the answer is:
- a course;
- an app;
- a membership;
- a dashboard;
- a coaching program;
- or some complicated automated system.
But until you have spent time with the people who actually have the problem, that is mostly a guess.
Do not be so confident in your first guess that you spend three months building it.
Instead, find the smallest thing you can sell that lets you create part of the desired result manually.
Start With Something You Can Deliver Today
Suppose you think Portuguese-speaking software engineers need help communicating during international interviews.
You do not need to build a complete pronunciation course.
You could offer:
A 60-minute communication assessment
You listen to them speak, identify the biggest problems, explain what matters most, and give them a personalized plan.
Now you are learning:
- what problems actually appear;
- which ones customers care about;
- what language they use to describe them;
- what results they want;
- what questions they ask;
- what they will pay for;
- and what they need after the assessment.
After doing ten assessments, you may discover that your original idea for a course was wrong.
Excellent.
You discovered that before building the course.
Things You Can Sell Before the Full Product Exists
Your first offer can be extremely simple.
For example:
An assessment
Examine the customer’s situation and tell them what is wrong, what matters, and what they should do next.
An audit
Review something they already have:
- their website;
- sales process;
- advertising;
- finances;
- CV;
- training;
- operations;
- or technical system.
Then give them specific recommendations.
A strategy session
Spend an hour helping them solve one narrow problem and leave with a plan.
A manual service
Do manually what you eventually imagine software doing automatically.
If you are considering software that analyzes sales calls, analyze five calls yourself and produce the report manually.
You may learn far more from doing that than from building the software.
A workshop
Teach or solve one narrow problem with a small group.
A pilot
Deliver an early version of the service to a few paying customers while openly explaining that the process is still being developed.
A deposit or preorder
If building the product genuinely requires work first, ask people to commit money before you build the whole thing.
Money creates much stronger evidence than:
“Yeah, I would probably buy that.”
Do Not Give Away Expensive Tests
There is a major difference between giving away something cheap to distribute and giving away your time.
Sending 1,000 people a free PDF costs almost nothing per additional reader.
That can be perfectly reasonable if you are testing:
- a message;
- a headline;
- a distribution channel;
- or whether people will take a small next step.
But be careful about giving away work that requires significant personal effort.
If you spend three hours giving someone a personalized consultation for free, what have you proven?
You have proven:
Someone is willing to receive three hours of valuable work for zero money.
That is not a particularly surprising result.
Free changes behavior.
Someone who would never pay €100 for something may happily take it for free.
People accept free samples, free chocolate, free downloads, free consultations, and free trials partly because the decision costs them almost nothing.
So if your actual question is:
“Will people pay for this?”
you eventually have to ask them to pay.
Otherwise you are testing a different question:
“Will people take this when it is free?”
Those are not the same market test.
Free Can Still Test Certain Things
Free is not useless.
It simply tests different things.
A free guide can test whether a topic attracts attention.
A free checklist can test whether people will exchange an email address for information.
A free tool can test usage.
A free webinar can test whether people will show up and stay.
But none of those proves that people will pay.
Use free deliberately.
Do not accidentally use free because you are afraid to ask for money and then tell yourself you have validated a business.
Manual Before Automated
A useful rule is:
Do manually what you eventually hope to automate.
Suppose your idea is an AI system that reviews hundreds of company accounts and identifies business risks.
Before building it, find five customers and produce the analysis yourself.
You will discover:
- which signals they care about;
- which information they ignore;
- which conclusions they distrust;
- what needs explaining;
- what they would pay for;
- and what the actual useful output should look like.
Then automate what you now understand.
If you automate first, you are encoding assumptions into software.
Do Not Fall in Love With the Product
There is another reason not to build too early.
Once you spend months creating something, your relationship with the idea changes.
It is no longer:
“I wonder whether people want this.”
It becomes:
“I need people to want this.”
Now your ego, time, and money are invested.
And your mind becomes extremely good at protecting the decision you already made.
When customers do not buy, you may start saying:
“The market isn’t ready.”
“People don’t understand the product.”
“We’re too early.”
“We just need better marketing.”
“Customers don’t realize how useful this is yet.”
Sometimes those explanations are true.
Often they are stories that allow you to avoid the simpler explanation:
People do not want what you built badly enough.
That is why testing before building matters.
The less you have invested in a particular solution, the easier it is to listen when reality tells you to change it.
Discover the Product With the Customer
Your first idea should be treated as a hypothesis, not a blueprint.
You might begin believing customers need a course.
After five conversations, you realize they want personal feedback.
After ten paid assessments, you realize the most valuable part is interview practice.
After twenty customers, you notice the same five problems repeatedly.
Now perhaps those five problems become a course.
The product emerged from reality.
You did not invent it alone and then search for people willing to justify its existence.
That is a much safer direction:
Problem → customer → paid manual solution → repeated patterns → product
rather than:
Idea → months of building → launch → hope
Your First Offer Does Not Need to Scale
Beginners often reject manual offers because they say:
“But I couldn’t do this for 10,000 customers.”
You do not have 10,000 customers.
You are trying to find out whether you can get one.
The first version of your business is allowed to be inefficient.
You can:
- send things manually;
- make reports yourself;
- schedule calls yourself;
- customize the service;
- use spreadsheets;
- use existing tools;
- and personally deliver the result.
Once people repeatedly pay for the result, you can ask:
“Which parts should become templates?”
Then:
“Which parts should become a process?”
Then:
“Which parts should become software, content, a group program, or automation?”
Scale what you have learned works.
Do not build scale for demand you have not found.
The Goal of the First Sale
Your first small offer has two jobs.
It should create a real result for the customer.
And it should teach you something about the business.
That makes offers such as assessments, audits, pilots, workshops, and manual services particularly useful.
You get paid to learn.
And the customer gets something genuinely useful in return.
That is much better than spending months secretly building what you hope they will eventually want.
Do not build the product and then ask the market to justify it.
Use the market to help you discover what the product should be.