Code is an expensive way to learn that nobody cares. Before choosing a framework or hiring a team, turn the idea into a sequence of testable assumptions: who experiences the problem, how they solve it today, what the failure costs, who buys, and why they would change now.
Write a falsifiable problem statement
Define one customer segment, one recurring job and one measurable consequence. “Small businesses need AI” is not testable. “Property managers with more than 200 units spend at least ten hours per week classifying maintenance requests” is. Write what evidence would disprove the claim before collecting feedback.
Interview behavior, not opinions
Ask potential users about the last time the problem occurred: what triggered it, what they did, how long it took, what they paid and who approved the workaround. Avoid pitching during discovery. Compliments and hypothetical willingness to pay are weak signals; existing budgets, spreadsheets, contractors and missed revenue are stronger evidence.
Test the riskiest assumption with the smallest artifact
Choose the cheapest experiment that can change your decision: a clickable prototype for usability, a landing page for message clarity, a manually delivered concierge service for workflow value, or a paid pilot for commercial demand. Clearly represent what exists; do not present a mock-up as a finished product or collect personal data without a legitimate purpose and appropriate safeguards.
Define commitment and success in advance
A useful experiment specifies audience, channel, sample, duration and threshold. Measure actions close to value: qualified calls booked, relevant data supplied, letters of intent, pilot deposits, repeat usage or referrals. Traffic and survey votes can inform acquisition, but they do not prove retention or willingness to pay.
Map the workflow before the feature list
Document inputs, decisions, exceptions, outputs, integrations and compliance constraints. Run the process manually and record where it breaks. This reveals whether software is needed at all and gives a much sharper boundary for the MVP. Then use the approach in thinking through a technical project before coding to turn evidence into architecture.
Common mistakes
- asking friends whether they like the idea
- describing the solution before understanding past behavior
- treating email sign-ups as proof of payment
- testing several customer segments at once
- building polished software to test a basic assumption
- ignoring the buyer, budget and procurement path
- changing success criteria after seeing weak results
- collecting unnecessary personal data
- continuing because of sunk cost rather than evidence
Practical validation checklist
- name one narrow customer and painful recurring job
- write assumptions and disconfirming evidence
- conduct behavior-based interviews with relevant people
- quantify current cost, frequency and alternatives
- identify user, buyer and decision process
- select the riskiest assumption
- run the smallest honest experiment
- set a success threshold before launch
- record evidence, objections and exceptions
- decide to stop, iterate or scope an MVP
When hiring a technical person makes sense
Bring in a technical product lead or fractional CTO when validation depends on integration feasibility, security, regulated data, meaningful infrastructure cost or a credible MVP estimate. They should reduce uncertainty, not pull the team prematurely into development. Once demand is credible, use a focused idea-to-MVP process to control scope.
Final takeaway
Validation is a decision system: assumptions, honest experiments, observable commitment and explicit thresholds. If you need an independent technical view before investing in an MVP, contact me.