How to validate a startup idea before building more.

1. Write a problem statement you can challenge

Describe the person, the situation, the task they struggle with, and the consequence. For example: an operations manager loses time reconciling delivery updates across several channels before responding to a customer. This is more testable than saying that logistics needs innovation. Write down what you know from observation and what you are assuming. Identify the riskiest assumption: the problem may be infrequent, an existing workaround may be good enough, or the person feeling the pain may not control the budget. Your first experiment should address one of these uncertainties, not validate the entire business at once.

2. Interview for recent behavior

Find people who actually perform the task. Ask them to walk through the last time the problem occurred, what triggered it, how they handled it, and what happened afterward. Listen for tools, handoffs, time, and consequences. Avoid explaining your solution at the start because it can turn the conversation into feedback on your pitch. Take notes with permission, preserve the customer's language, and separate direct observations from your interpretation. A polite compliment is weak evidence. An example of a recent costly workaround tells you much more about urgency and context.

• When did this last happen?
• What did you do, step by step?
• What have you already tried to change?
• Who else was involved in deciding or paying?
• What happens if the problem remains unsolved?

3. Test a concrete next commitment

Once a pattern appears, offer a bounded next step. It might be a follow-up with the decision maker, a supervised workflow trial, a prototype task, or a clearly described paid pilot where appropriate. Be transparent about what exists and what is still an experiment. Do not imply that an unavailable product is ready. Choose an action that tests the uncertainty you identified. A mailing-list signup can test curiosity, but it cannot by itself establish repeat use, willingness to pay, or delivery feasibility. Record who accepted, who declined, and the reason; negative responses often reveal a narrower and more useful customer segment.

4. Make a decision from the pattern

Review the evidence as a group of cases rather than selecting the most encouraging quote. Ask whether the same problem, trigger, buyer, and workaround recur. Note important differences by role or organization type. Decide whether to continue, change the segment, revise the problem, or pause. Define the next question before building another feature. Keep a short evidence log with the hypothesis, people reached, observations, limitations, and decision. You are reducing uncertainty, not proving that a startup must succeed. A small, biased sample should be described as such; it can guide the next experiment without supporting a broad market claim.

Questions, answered.