An early idea usually comes with a long list of possibilities. It also comes with something less comfortable: assumptions.

Will customers understand the concept? Can the existing system provide the data? Would an automated step be accurate enough to save time? Is the proposed experience actually easier than what people do today?

A good prototype doesn’t try to make all those questions disappear. It picks an important one and makes it possible to learn something real.

Find the assumption that could change your decision.

Start by asking what would make you stop, change direction, or significantly revise the idea. That’s usually a better target than the easiest feature to demonstrate.

If the project depends on an external system exposing reliable data, a polished interface won’t reduce that risk. Test the integration first. If the technical work is straightforward but the customer journey is unfamiliar, a clickable prototype may teach you more than a functioning backend.

Write the assumption as a question with a decision attached: “Can a new customer submit a complete request without help? If not, we need to simplify the flow before building it.”

The prototype is not the deliverable that matters most. The decision it helps you make is.

Match the prototype to the question.

Different uncertainties need different experiments. More technical completeness does not automatically produce better learning.

  • A sketch or clickable concept can test language, navigation, and whether people understand the idea.
  • A technical proof of concept can test an integration, a performance constraint, or whether a model can handle representative examples.
  • A thin working slice can test one complete journey across the systems involved.
  • A partly manual service can test whether the outcome is valuable before automating the steps behind it.

Be explicit about what is real and what is simulated. A convincing demo can accidentally create confidence in things it never tested. Label those boundaries for everyone watching.

Decide what evidence would be enough.

“People liked it” is encouraging, but it’s difficult to act on. Before running the experiment, decide what you’ll observe and how it will influence the next step.

For a workflow, you might watch whether participants complete the task without prompting and where they hesitate. For an integration, you might test representative records, missing fields, and error responses. For AI, you might compare outputs against a small, reviewed evaluation set.

The sample should resemble the conditions you care about. Internal enthusiasm is not a substitute for customer feedback, and a perfectly clean test record is not a substitute for messy real data.

Choose participants and data responsibly. Get permission where needed, avoid exposing sensitive information, and use anonymized or synthetic examples when they can answer the question just as well.

Put a boundary around the experiment.

A prototype becomes expensive when every new possibility turns into another feature. Set a timebox, write down what is out of scope, and keep returning to the original question.

When someone suggests an addition, ask whether it changes the evidence you need. If it doesn’t, capture it for later rather than quietly expanding the build.

This is not an argument for sloppy work. The prototype still needs to be safe and understandable. It simply doesn’t need every capability of the product you might eventually create.

Finish with a decision, not just a demo.

At the end, summarize what you expected, what you observed, and what remains uncertain. Include the surprising or disappointing results. They’re often the most valuable part.

Then choose a next step: proceed, run a narrower experiment, change the approach, or stop. Stopping after a small test can be an excellent outcome if it prevents a much larger investment in the wrong direction.

Finally, be honest about the code. Prototype code may be a foundation, or it may be something you learned from and set aside. Production readiness involves reliability, accessibility, security, support, and maintainability that an experiment may not have explored.

Build enough to learn. Learn enough to decide. Then invest with a clearer view.