Products need a point of view

Most product complexity arrives as politeness.

Someone asks for another option, and it sounds reasonable. A setting gets added because different users might prefer different behavior. A fallback appears because the team does not want to be too strict. None of these choices feels expensive in isolation.

Then the product becomes a room full of switches.

The user can technically do more, but they have to decide more before anything useful happens. The product stops carrying the shape of the work. It becomes a menu of possibilities instead of a tool with judgment.

We prefer products with a point of view.

Opinion is not arrogance

An opinionated product does not mean the team believes there is only one valid way to work. It means the product is willing to make the first good path obvious.

For a martial arts teacher, a useful planner should not begin by asking for every possible preference. It should understand the few constraints that actually shape a class: discipline, level, duration, warmup, goals, and available intensity. From there, it should produce something structured enough to react to.

For a vector editor, the first path should be practical manipulation, not a gallery of everything the SVG specification permits. The user came to edit a shape, clean a file, export a result, or inspect something quickly. The interface should bias toward that work.

For voice-first capture, the product should not ask the user to organize before capture. The whole point is that the thought is fragile. Capture first. Structure later.

These are opinions. They reduce the number of possible states. They also make the product easier to improve because we can evaluate changes against a clear main path.

Defaults are product strategy

Defaults are where product strategy becomes visible.

A default tells the user what the product thinks is normal. If every field is optional, every mode is equally promoted, and every workflow has a settings panel, the product is saying that it does not know what matters.

Good defaults do not hide complexity forever. They delay complexity until the user has enough context to care.

That is especially important for small products. Early software often fails because the team tries to expose its flexibility too soon. Flexibility feels impressive to the builder, but it can feel like homework to the user.

The better first question is: what can we decide on the user's behalf because we understand this job?

Refusing states makes software better

One way to make a product clearer is to make impossible states actually impossible.

If a lesson plan requires a duration, do not pretend it is optional. If a saved artifact needs a title, ask for it at the moment it matters. If a workflow only makes sense after a user is authenticated, do not design three half-authenticated versions of the same screen.

This sounds like engineering hygiene, but it is also product taste. Every unnecessary state creates copy, layout, QA, support, and user confusion. A product with fewer states can feel calmer because the team has removed decisions instead of decorating around them.

We like discriminated paths, explicit required inputs, and names that say what something is. Not because strictness is virtuous by itself, but because unclear state leaks into the interface.

The product should be able to say no

The hardest part of having a point of view is refusing features that are plausible.

Plausible features are dangerous because they are easy to defend. Someone can imagine a user needing them. They fit the general category. They make the roadmap look richer. But if they blur the main promise, they make the product weaker.

A small product does not need to become generic to become useful. It needs to become more itself.

That usually means deepening the path that already works: clearer inputs, better output, faster recovery, sharper language, fewer moments where the user wonders what to do next.

When a product has a point of view, people can disagree with it. That is fine. Disagreement is information. The worse outcome is indifference: a product so flexible and unspecific that nobody can tell what it is trying to make easier.

Software should have taste before it has breadth.