Product

Product work is the discipline of turning a real problem into a system people can understand, use, trust, and return to.

It is not only taste. It is not only shipping features. It is judgment under constraint: what problem matters, whose behavior must change, what tradeoff is acceptable, and what the product should refuse to become.

The best product work makes the next right action obvious for the user and the next right decision clearer for the team.

When you build something people love with a great attention to craft and manage to tell a compelling story, people show up for you.

That’s something a data driven founder, busy optimizing funnels and nudging button colors, will never quite reach. Because trust isn’t a metric, goodwill doesn’t fit in a dashboard, and people don’t rally behind experiments. They rally behind work that feels intentional, human, and worth supporting.

Start With The Problem

A product is weak when it starts from a feature list instead of a tension in the world.

Before designing a solution, I want to understand:

• Who has the problem?
• How do they handle it today?
• What does the current workaround cost?
• Why has nobody solved it well yet?
• What would make the user switch?
• What would make them stay?

If the problem is vague, the product becomes decorative. If the problem is sharp, even a simple interface can feel powerful.

Design The Loop

Most products are loops, not pages.

A user arrives with intent, takes an action, receives feedback, builds trust or loses it, and decides whether to continue. The product either compounds that behavior or leaks it.

Useful loops usually contain:

• A clear trigger.
• A low-friction first action.
• Fast evidence that the action mattered.
• A reason to return.
• A way for the product to get better through use.

Bad loops create motion without progress. Good loops make the valuable behavior easier each time.

Respect Incentives

Incentives are part of the interface.

What you measure, reward, notify, rank, hide, or make easy will shape behavior. If a product claims to value quality but rewards volume, volume wins. If it claims to value focus but constantly interrupts the user, interruption wins.

Good product judgment asks what behavior the system is training.

The strongest products align:

• User value.
• Business value.
• Team incentives.
• Operational reality.

When those drift apart, the product may grow while quietly becoming worse.

Interfaces Are Decisions

An interface is not a skin over the real product. It is where the product makes its promises visible.

Every button, empty state, label, default, and error message teaches the user what kind of system they are dealing with. The interface should reduce uncertainty, expose structure, and make consequences legible.

Good interfaces are not merely pretty. They are honest.

They answer:

• What can I do here?
• What happened?
• What changed?
• What should I do next?
• What can go wrong?

Clarity beats novelty unless novelty solves a real comprehension problem.

Make Tradeoffs Explicit

Every product decision spends something.

You can spend complexity, time, attention, trust, performance, margin, flexibility, or future optionality. The danger is not making tradeoffs. The danger is pretending they do not exist.

Product strategy should make the important tradeoffs visible:

• Breadth or depth.
• Speed or certainty.
• Power or simplicity.
• Automation or control.
• Growth or trust.
• Flexibility or coherence.

The right answer depends on the system, the customer, the moment, and the cost of being wrong.

Strategy Is Constraint Design

Strategy is not a document full of confident language. Strategy is the choice of constraints that make good decisions easier and bad decisions harder.

A useful strategy names:

• The user and problem that matter most.
• The behavior the product must create.
• The advantage the team can actually build.
• The things the product will not do.
• The evidence that would change the plan.

Without constraints, everything can sound reasonable. With constraints, the team can say no without turning every decision into a new debate.

Questions I Return To

• What job is the user hiring this for?
• What painful workaround proves the problem exists?
• What is the smallest version that teaches us something true?
• Where does the product create trust?
• Where does it ask for too much attention?
• What behavior are we accidentally rewarding?
• What would make this simpler without making it weaker?
• What should this product refuse to become?