Name what you do not know
Ask intended customers about the last time they faced the problem: what they tried and what remained difficult. Then name the uncertainty—need, behavior change, trust, or completing the task. A polished prototype cannot test everything.
Match the test to the doubt
Fictional example: you want to build a portal for customers to request recurring maintenance. Before building accounts and dashboards, try a clearly described request process with a small, appropriate group. Handle the scheduling manually and be honest about how it works.
If people do not request the service, learn why. If they request it but struggle to choose the right option, test the wording and choices. If demand exists but fulfillment breaks down, the next build may be an internal scheduling tool rather than a prettier front page.
Decide what would count as evidence
Choose an observable action: someone submits a suitable request, completes the task, returns to use it, or makes an agreed commitment. Compliments are encouraging. They are not the same as use.
Keep the test safe and permission-based. Do not imply that an unfinished service exists, collect unnecessary sensitive information, or accept commitments you cannot fulfill.
Build the repeated part next
Once the manual path reveals a real need and a workable process, identify the step software should support. Keep the rest out of the first version unless it is necessary for access, safety, or a complete user task.
One small test cannot prove a market. It can help you avoid building an answer nobody needs.