The product is the experiment.

A product functions as a hypothesis made usable — every real interaction with it generates evidence a pitch deck never could. Where did someone stop? What did they understand instantly? What did they repeat, and what did they ignore? Every one of those small behaviors is a data point that no amount of internal discussion could have produced on its own.

Behavior beats opinion

Those signals are consistently more valuable than opinions collected before launch. People are unreliable narrators of their own future behavior — not because they’re dishonest, but because predicting your own future actions is genuinely hard, even for the person doing the predicting. Someone can sincerely believe they’ll use a feature weekly and never open it again once it exists. Their actual usage isn’t unreliable in that same way. It’s simply what happened.

This is why we treat a launched product very differently from a survey or a set of interviews. Interviews are useful for understanding how people think about a problem in the abstract. They’re a poor predictor of what those same people will actually do once a real, working solution is sitting in front of them, competing for their attention against everything else in their day.

Interface as instrument

This is why product development and experimentation are so closely connected. The interface, the workflow, and the feature set aren’t just implementation details — they’re instruments for learning, not just delivery mechanisms. A poorly designed onboarding flow doesn’t just cost you conversions; it costs you the ability to learn anything from the users who dropped off, because you never got to see what they would have done next.

Treating the product as an instrument changes how you build individual features. A feature isn’t just “does this solve the problem” — it’s also “what will this teach us if it doesn’t.” Some features are worth building specifically because of what they’ll reveal, even if they don’t survive in their first form.

The two jobs of a good release

A useful product has two jobs at once: create value for the user, and create learning for the team building it. Most teams focus entirely on the first job and treat the second as a side effect. Flipping that — designing releases so they teach you something specific, on purpose — tends to produce faster, more confident decisions later.

When both happen together, each release becomes another step in a longer process — never a final answer. That framing also makes shipping less fraught. A release doesn’t have to be right. It has to be informative.

Common questions

How do you design a feature specifically to “teach” you something? Decide before building what specific question the feature is meant to answer, and make sure the way you measure its use actually answers that question — not just whether it shipped, but whether the assumption behind it held up.

Isn’t it risky to ship something mainly to learn from it, rather than because it’s finished? The risk is manageable if you’re honest with users about what stage something is at. Most people are more forgiving of a rough but clearly-labeled early version than of a polished feature that quietly doesn’t work as promised.

What happens when a release teaches you the original idea was wrong? That’s the release doing its job well, not badly. The expensive outcome is spending a year building the wrong thing fully finished. The cheap outcome is finding out early enough to redirect.

Takeaway: when both happen together, each release becomes another step in a longer process — never a final answer.