A compliment
is not a test.

Validating a project idea means reducing an important uncertainty with evidence. It does not mean obtaining a universal “good idea” score. A business can fail even after encouraging early tests; a narrow test can still be valuable because it helps you choose a better next action.

Before building, separate three questions: does the problem happen, does your proposed approach help, and will people make the commitment the product needs? A friendly answer to one does not settle the others.

Find the assumption that could stop the project

Write one sentence that has to be true for the first version to matter. “People want an app for remote work” is too broad. “Remote workers in this neighbourhood cannot reliably find a quiet place with power for a two-hour session” describes a situation you can investigate.

List what would make the idea unnecessary. Perhaps people already have a satisfactory solution, the problem happens rarely, the information changes too fast to maintain, or the audience cannot be reached. Test the assumption whose failure would change your plan most.

The first useful experiment is often much smaller than the first software release. A spreadsheet, a sketch or a manually delivered service can isolate the question without introducing authentication, integrations and deployment as new uncertainties.

Ask about the last real time

Start with a recent event, then follow the person’s account. Avoid pitching the solution before you understand the situation. Once you describe the product you hope to build, people may try to be helpful by agreeing with you.

Three relevant conversations can uncover misunderstandings, but three people are not a representative market survey. Choose people who have experienced the situation recently. Friends can help you rehearse, but their enthusiasm may not describe the intended audience.

Ask permission before recording. Capture only the information you need and separate what the person said from your interpretation. If the person has never had the problem, that is useful context; do not force them to invent an answer.

Match the experiment to the uncertainty

Use a task walkthrough for a utility

For a calculator, timer or tracker, ask someone to bring a real input. Give them a sketch or small working version and a neutral task. Watch what they choose, what they misunderstand and whether the result is useful. If you explain every step, you have tested your explanation as well as the interface.

Use a manually delivered result for a service

Before automating a website review, deliver one review by hand. Ask for the actual page, agree on the scope and provide the promised result. See whether the recipient uses it to make a decision. This reveals the delivery process before you invest in a portal or report generator.

Use a real choice for a directory

A person browsing ten interesting entries is weaker evidence than a person choosing one for this week. Ask which details drove the decision and which facts required another search. The answer can tell you that one well-maintained field matters more than five additional filters.

Use participation for a community

A signup is a low-cost action. Invite a small group to one specific session with a useful ritual. Ask participants to contribute something. Observe who contributes and who chooses to return when another session is offered. Do not treat the size of a dormant mailing list as a functioning community.

These approaches are consistent with the early, direct work described in Paul Graham’s “Do Things that Don’t Scale”. The experiments here are examples to adapt, not a claim that one method proves every market.

Choose the rule before seeing the result

It is easy to reinterpret every result as encouragement when you care about an idea. Write what you expect to observe before running the test, including a result that would make you pause.

For the directory example: “At least two of three people can choose a real venue for an upcoming session without leaving to verify essential details. If they all need to search elsewhere, improve the entries before adding more venues.” This is a small learning rule, not a statistically justified conversion target.

Prefer behavior to vague ratings. A person bringing real material, completing a task, returning voluntarily or making an informed commitment is different from saying the page looks nice. Do not fabricate a checkout or hide the state of an unfinished product to create apparent demand. Be clear about what exists, what a participant will receive and any relevant terms.

Keep the evidence simple and inspectable

You do not need a research dashboard for a handful of sessions. A small observation sheet makes it harder to replace what happened with what you wanted to happen.

In the planner, use the decision-rule field before the experiment and the private notes field afterwards. Notes stay in your local workspace and are excluded from shared plan links and route images. JSON backups and Markdown briefs include them, so review those files before sharing them.

Decide what the evidence earns

A successful small test earns a sensible next investment, not certainty. If people can complete the task but do not return, investigate frequency and motivation before adding polish. If they need a different outcome, change the core flow. If the result depends on constant help from you, decide whether a supported service is appropriate or the product needs work.

A failed test is not a verdict on your ability. It is a reason to spend the next block of time differently. Write the decision, adjust the MVP scope, and keep the next experiment small enough that you can afford to be wrong again.