The experiment is the product

An experiment is not a half-product. It is a product with a shorter learning loop.

That framing changes the work. If something is "just an experiment," it is easy to accept rough edges that destroy the signal. The copy can be vague, the first screen can be confusing, the URL can be temporary, the empty state can be an apology. Then, when nobody uses it, the team cannot tell whether the idea failed or the presentation did.

The opposite mistake is treating every experiment like a mature platform. That creates a different kind of waste: too many features, too much architecture, too many branches of behavior, and not enough contact with real use.

The useful middle is to make the smallest thing that can be honestly used.

Honest use is the bar

An honestly usable experiment has a real user, a real promise, and a real moment of completion.

The user should be able to tell what the product does without a meeting. The promise should be narrow enough that the software can keep it today. The completion moment should be visible: an edited SVG, a lesson plan, a captured task, a saved draft, a result the user can judge.

That completion moment matters because it gives the team behavior to learn from. Did the user finish? Did they come back? Did they change the output? Did they export, save, share, or abandon it? Did they ask for something adjacent, or did they ask for the core thing to be better?

Without a completion moment, the experiment mostly measures curiosity.

Build the instrument, not the fantasy

Early product work is partly instrument design. The release should make the important behavior observable.

That does not mean turning the product into an analytics dashboard. It means designing the flow so that success and failure are legible.

If a user opens Bizu Vector and leaves before importing or editing anything, the product has an activation problem. If they edit but do not export, the output path may be weak. If they export once and never return, maybe the tool solved a one-off job, or maybe there was no reason to trust it with a second file.

For a planner like MartialKit, the signals are different. The important question is whether the generated plan becomes a useful object. Does the teacher adjust it? Save it? Generate another version with tighter constraints? Return before the next class?

The experiment should be shaped around those questions.

The product should survive the test

A test that embarrasses the product is not a good test.

People do not owe early software extra patience. If the product is slow, confusing, visually careless, or full of dead ends, the user is not evaluating the idea anymore. They are evaluating whether the team seems serious.

That is why the surface matters even when the scope is small. A clean first screen, a good title, useful metadata, responsive layout, and a simple path back home are not decoration. They protect the experiment from avoidable noise.

The standard is not perfection. The standard is respect for the user's attention.

Learning should change the product

The point of an experiment is not to confirm that the original plan was correct. It is to earn the next plan.

After a release, the team should be willing to do one of four things:

1. Deepen the core workflow because the signal is strong.
2. Narrow the audience because a specific group cares more than expected.
3. Change the promise because users are trying to hire the product for a different job.
4. Stop, because the idea did not produce enough behavior to justify more work.

All four outcomes are useful. The only bad outcome is continuing from inertia.

At Bizu, experiments are not side quests from the "real" product. They are how the real product gets discovered. The job is to ship something small enough to learn from and solid enough that the learning is honest.