Write down the risky ideas to test
Start with the parts that must be true for the business to work. Usually these are the customer, the problem, the offer, the channel and readiness to pay. A logo or finished website does not reduce those risks.
- Who has the problem often enough to care?
- What do they use or do today instead?
- Why would they choose this offer now?
- What clear action would count as proof?
Speak to people about current behaviour
Talk to people who match the customer definition. Ask about the last time they faced the problem, what they tried, what it cost and what made the situation difficult. Questions about real past behaviour are more useful than asking whether someone might buy in future.
- Avoid pitching during the first part of the conversation
- Listen for repeated language and limits
- Treat compliments as context, not proof
Define the smallest paid test
Build only enough to test the central promise. A service can begin with a tightly scoped manual delivery. A product can begin with samples, pre-orders or a tiny batch. Software can begin with a concierge version that produces the same outcome manually.
Simple example
Instead of ordering 100 gift hampers, assemble two representative samples, show them to a defined buyer group and ask for a paid pre-order with a clear delivery date.
Ask for clear action
Payment is the strongest early signal. But it is not the only useful one. A deposit, signed trial, booked appointment or introduction to the budget owner can also show that the problem matters. Choose the signal before starting so weak results cannot be reinterpreted later.
- State the offer, price and delivery clearly
- Make it easy to decline
- Record objections without arguing
- Do not substitute likes or survey votes for clear action
Review the proof
Separate proof about the problem from proof about your current offer. Strong problem proof with weak sales may mean the offer, price or channel needs work. Repeated indifference may mean the customer or problem is wrong.
- Continue when likely customers commit and delivery looks possible
- Improve when objections are specific and repeated
- Pause when the problem is weak or delivery cannot become workable