An idea becomes easier to evaluate when you stop asking whether it sounds good and start asking what would have to be true for someone to use it. Before you start a business, separate the problem, the customer, the offer, and the way money would change hands. Each part can fail for a different reason.
This guide develops a small validation project for a hypothetical service that helps independent cafés organize supplier invoices. The example is illustrative, not a claim about café demand. Its purpose is to show how to replace an attractive business story with specific observations, modest tests, and decisions you can explain.
Write a problem statement that can be challenged
Begin with a person in a situation, not with a product category. “Software for small businesses” names a possible solution but tells you little about the work involved. “A café manager spends Monday evenings matching delivery invoices to purchase records” describes a situation you could investigate directly.
Add the consequence you believe matters. The manager might lose time, miss discrepancies, or struggle to hand records to a bookkeeper. Do not assume all three are true. Write them as separate hypotheses and ask what evidence would support each one. The inconvenience you notice may not be the inconvenience the customer wants to pay to remove.
Keep a record of your initial assumptions. A dated paragraph is enough. Without that record, it is easy to reinterpret every conversation as confirmation of whatever you now believe. Changing your mind is useful; forgetting that you changed it makes the next decision harder to audit.
Find the existing alternative
Every proposed solution competes with something, including a spreadsheet, an employee's memory, a different service, or leaving the problem unresolved. Ask how the task was handled the last time it occurred. Observe the steps when the person is comfortable showing them, and avoid requesting confidential customer or financial information.
The U.S. Small Business Administration's business planning guidance recommends investigating demand, existing alternatives, and what customers pay. Use those questions as a research scaffold, not evidence that your own market exists. Its administrative material is U.S.-specific; readers elsewhere should use local sources for registration and other formal requirements.
For the café example, an existing bookkeeper might already handle the task efficiently. That finding would not make the interview a failure. It could show that your assumed problem belongs to a different customer group, or that the cost of switching would outweigh the benefit you imagined.
Recruit people who can contradict you
Choose participants because they have recently encountered the relevant task. Friends who like your ambition may not be able to describe the buying process. A person who manages invoices is also not necessarily the person who approves a new service. Learn how those roles relate before interpreting an enthusiastic response as purchasing intent.
Use a simple recruitment note explaining that you are researching a workflow. State the topic and expected time commitment honestly. Avoid implying that you already have a finished product, a customer partnership, or an endorsement. Participation in research is not permission to use someone in marketing.
Keep distinct groups separate. A café owner, a bookkeeper, and a multi-location operations manager may describe similar paperwork while facing different constraints. Combining their answers into one imaginary customer can produce an offer that fits none of them particularly well.
Interview before presenting a solution
Ask about a recent instance: what triggered the work, which steps took time, who was involved, and what happened afterward. Follow the sequence rather than forcing the interview toward your prepared pitch. An unexpected workaround may explain more than a rating on a scale from one to ten.
Avoid asking, “Would you use an app that fixes this?” That question invites speculation about an undefined future. Ask what the person has already tried, what it cost, and why they kept or abandoned it. When they say a task is annoying, ask for an example rather than interpreting the adjective as proof of urgency.
The companion guide to customer interviews for first-time founders explains how to organize these conversations. Finish the research portion before showing a concept, so you can distinguish an account of current behavior from a reaction to your idea.
Choose a test that matches the uncertainty
Different uncertainties call for different tests. An interview may reveal how a workflow operates. A sample report can reveal whether the output is understandable. A clearly scoped paid pilot can reveal whether a particular buyer accepts a particular offer under stated conditions. None of these alone establishes the size of a market.
Test the output before building the tool
For the café example, a manually prepared sample could test the usefulness of an invoice summary using invented or properly redacted information. This avoids building an entire software product to answer a narrower question about the output. Do not represent manual work as automated technology.
Define what participants will receive, what you need from them, and what you will not do. When money or sensitive information is involved, obtain appropriate agreements and professional guidance for the jurisdiction. Validation should not be an excuse to bypass privacy, safety, or contractual responsibilities.
Decide what evidence would change the plan
Before running the test, write three possible decisions: continue with the same customer, revise the offer, or stop this version. Describe the observations that would lead to each. These are your decision rules, not statistical proof and not thresholds borrowed from an unrelated startup story.
Suppose several managers describe the task clearly but say they cannot choose a supplier. The next investigation may concern the owner or bookkeeper, not a new feature. Suppose the sample is useful but takes you several hours to produce. The next uncertainty may be delivery economics rather than customer interest.
Give negative evidence an explicit place in your notes. Record non-responses, unresolved concerns, and abandoned conversations without treating every one as rejection. The objective is to understand what the evidence means, including its ambiguity, rather than turn a small research exercise into a success statistic.
Connect demand to a deliverable business
Interest is only one part of the model. Estimate the resources required to serve a customer, how payment would work, and who would provide support when something goes wrong. A service that customers appreciate may still be impractical at the price they accept.
For the hypothetical invoice service, outline the inputs, work steps, output, turnaround time, and revision boundary. Then consider a messy case: incomplete records, a disputed charge, or a late request. The difficult case often exposes obligations that a polished demonstration leaves out.
Use the startup cost and runway guide to separate one-time setup spending from recurring delivery needs. Keep the estimates visibly provisional. A supplier quote, a measured task duration, and a guess should not look equally certain simply because they occupy neighboring spreadsheet cells.
Run a review before adding scope
At the end of the project, summarize what you learned in four paragraphs: customer, problem, offer, and economics. Under each, identify one supported observation and one remaining uncertainty. Attach the relevant notes instead of relying on the most memorable conversation.
Ask whether the next step answers a real unknown or merely makes the idea look more complete. Adding a logo, features, or a larger website can feel productive while leaving the main question untouched. Sometimes the next useful action is another conversation with a different buyer.
The Start a Business track brings these decisions into a broader sequence. It is a reading path, not a promise that every project should launch. A decision to pause can be a well-supported outcome when the current evidence does not justify a larger commitment.
Conclusion: make uncertainty visible
Validation is not a certificate that your business will succeed. It is a way to learn which assumptions deserve further work and which should be changed. Start with a specific customer situation, investigate the existing alternative, and choose a small test that addresses one uncertainty. Continue only with a clear account of what the test did and did not establish.
