A software idea often arrives disguised as a solution: a list of screens, integrations, automations, and features that seem inevitable. The problem is that the list describes what someone wants to build, not what another person needs to use.
Validation reduces that distance. Its purpose is not to prove you were right. It is to discover, at the lowest reasonable cost, whether a relevant problem exists, who feels it, and what change would make someone adopt a solution.
Validation is not asking for approval
Asking “would you use this app?” almost always produces optimistic answers. People want to help, imagine an ideal future, and do not need to pay, migrate data, or change their routine in that moment.
A useful conversation investigates past behavior and present friction. Instead of presenting the solution too early, learn:
- when the problem last happened;
- how it is solved today;
- how much time, money, or energy the workaround consumes;
- who feels the pain and who decides to buy;
- what has already been tried and why it did not last.
Opinion is a signal. Behavior is stronger evidence. Someone who has improvised with a spreadsheet for months, pays for an incomplete tool, or repeatedly performs a task by hand is showing that the problem occupies real space.
1. Turn the idea into a hypothesis
Before writing code, formulate a sentence that can be wrong. A useful format is:
We believe [type of person] experiences [observable problem] often enough to adopt [proposed change]. We will know this is true when [measurable behavior] occurs.
“Build a complete ERP for schools” is a broad intention. “Coordinators at small schools lose hours reconciling enrollment, contracts, and billing across separate tools” is an investigable hypothesis.
This language forces the team to name the audience, problem, and expected evidence. It also reveals how many assumptions were hidden inside the original idea.
2. Find the right people
Five conversations with people who live the problem can teach more than fifty generic survey responses. The segment must be specific enough for accounts to be comparable.
Start with the context where the pain occurs: operation size, task frequency, current tool, and the person’s responsibility. A receptionist, manager, and studio owner may see the same process in completely different ways.
Record literal phrases, examples, and exceptions. Do not turn every answer into confirmation. If nobody can remember the last occurrence, the problem may lack the urgency you imagined. If every person describes a different pain, the segment is still too broad.
3. Build the smallest test that creates learning
An MVP is not necessarily a smaller version of the final product. It is the smallest mechanism capable of testing the most dangerous uncertainty.
If the question is comprehension, a navigable screen may be enough. If it is willingness to change a process, a manually operated service behind a simple interface may be more honest. If it is technical feasibility, an isolated prototype should attack the integration or performance risk before any polish.
Possible tests include:
- a page that explains the proposal and measures access requests;
- a clickable prototype used during a real task;
- a manually assisted operation that exposes the full workflow;
- a sample-data import that measures complexity and errors;
- a pre-sale or letter of intent, when trust and context support it.
The test should feel real enough to require a decision but remain small enough to discard without attachment.
4. Define the signal before running the test
Without a prior criterion, every result can become a convenient story. Define what will be observed, for how long, and which result changes the next decision.
Avoid vanity metrics disconnected from the hypothesis. Visits and likes may reveal reach, but they do not show that someone completed a task, returned to the product, or paid for value.
More useful early signals might include:
- people reaching the end of the flow without help;
- time required for the primary task;
- spontaneous return after the first experience;
- real data someone agrees to import;
- an invitation sent to another team member;
- a concrete commitment to a pilot, payment, or meeting.
A four-step protocol
At TestaAí, the editorial process fits into four verbs:
- Ideate: record the hypothesis and central uncertainty.
- Build: create only what makes the test possible.
- Test: place the mechanism in the real context and observe behavior.
- Evolve: continue, change, or stop based on what appeared.
The value lies in repetition. The protocol prevents months of execution from hiding a question that could have been answered in days.
When to continue, change, or stop
Continue when the same problem appears repeatedly, the test produces behavior compatible with the hypothesis, and the next investment reduces a relevant uncertainty.
Change direction when pain exists but the audience, moment, or proposed solution does not fit. Stopping is also a valid outcome: sometimes the problem is rare, behavior change is too expensive, or the required operation contradicts the business you want to build.
Learning must end in an explicit decision. “We will think about it” often only delays the conversation.
The next test
If you have an idea today, do not begin with the complete architecture. Write the hypothesis in one sentence, choose three people who recently experienced the problem, and define the evidence that would make you invest one more week.
Then build only the test. That is how an idea stops being a promise and starts becoming a product.
Read the TestaAí manifesto and follow the experiments in motion.
