Three products later, I build differently

Shipping changes the questions you ask. Before I had products in the world, I could spend a long time deciding what the ideal version should be. The work felt clean because most of the uncertainty still lived in my head. After launching China Trip Pilot, CubeOrbit, and Lullaly, I see the work differently. A product is not an idea that becomes complete. It is a set of decisions that has to survive contact with real use.

The three products are different, but each one made the same lesson harder to ignore: clarity is more valuable than volume. More pages, more settings, and more clever technology can all make a product feel substantial. They can also hide the one thing a visitor came to do. I now start by asking what deserves to remain when everything optional is removed.

Start with the smallest useful promise

I used to think an early version had to explain the whole ambition. That creates pressure to build a broad surface before the central interaction is strong. Now I try to define one useful promise in plain language. If I cannot say what the product helps someone do without adding a paragraph of qualifications, the scope is probably still too wide.

This does not mean making something careless or disposable. Small is not the same as unfinished. A narrow product still needs coherent language, reliable behavior, and a clear beginning and end. The discipline is in choosing fewer responsibilities, then taking those responsibilities seriously.

That shift also makes feedback more useful. When the promise is specific, I can tell whether a confusing response points to the interface, the wording, the underlying assumption, or the value itself. When the promise is vague, every reaction can be interpreted in several ways and little is learned.

Treat the whole path as the product

Writing code is only one part of shipping. A visitor first meets a name, a sentence, a visual hierarchy, and an expectation. They may never reach the feature I spent the most time building. The path into the product is therefore not packaging around the work; it is part of the work.

I pay more attention now to the sequence around the core interaction. What does the first screen say? Is the next action obvious? What happens when there is no data, an invalid input, or a slow response? Can someone recover without understanding the implementation? These are ordinary questions, but answering them consistently is what turns a functioning tool into a usable product.

The same applies after launch. Maintenance, small corrections, and clearer explanations do not feel as dramatic as a new feature. They often improve the experience more. A shipped product creates obligations, and those obligations are useful constraints on my attention.

Let evidence narrow the next decision

Independent work has many possible directions and very little natural structure. I can always find another feature worth exploring. The harder skill is choosing what not to pursue yet.

I now prefer decisions that produce evidence. That might mean simplifying a screen, publishing a focused page, or testing whether a visitor understands the action without guidance. The goal is not to collect activity. It is to reduce uncertainty enough to make the next choice better.

Evidence does not automatically decide the product. Numbers can show where people stop, but not always why. A few observations can be noisy. My job is still to make a judgment, only with less fiction around it. The most useful learning often comes from comparing what I expected with what actually happened.

Build a practice, not a streak

Three launches have not produced a universal method. They have given me a more grounded practice. Define the promise. Remove competing ideas. Build the complete path. Release it. Observe where reality disagrees with the plan. Make the next decision from there.

That practice is slower in some moments and much faster in others. It prevents me from polishing assumptions for too long, and it keeps a small product from becoming a random collection of features. Most importantly, it gives each launch a role beyond being finished. Every product becomes a way to improve how I build the next one.

Monaro is the next chapter of that practice. I am carrying forward fewer certainties and better questions.