How I think about products.

Most product decisions are made under uncertainty, which means the goal isn't to eliminate uncertainty, it's to be clear about where it lives. I separate what I know from what I believe. Facts are things I can point to: data, user quotes, competitive evidence. Beliefs are inferences I'm making from that data. When I disagree with a stakeholder, it's almost always because we're treating a belief as a fact.

Before I commit to a direction, I write down the assumptions that would have to be true for it to work. Then I rank them by impact and confidence. High-impact, low-confidence assumptions are the ones worth testing. That simple exercise has saved me from shipping things that looked right but rested on something nobody had actually checked.

I also write decisions down, not as a formality, but because the act of writing it out reveals when I can't actually explain it. If I can't write a clear sentence about why we're doing this and what would prove us wrong, the decision isn't ready to be made.

The request for a redesign almost always means something else. Usually it means: users are frustrated with a specific flow, or the product feels dated, or someone saw a competitor do something cool. These are real signals, but "redesign" is rarely the right solution.

A redesign is expensive. It resets learned behavior, introduces regression risk, and takes months to recover from in terms of user support load. Before agreeing to one, I want to know: what's the specific outcome we're trying to move? If you can answer that precisely, "we want to reduce time-to-first-value from 8 minutes to 3", then you probably don't need a redesign. You need targeted changes to the specific parts of the experience that are causing the delay.

I've stopped a full redesign twice in my career by reframing it as a series of specific improvements. Both times, we got better outcomes faster and with less risk. The third time, the redesign was genuinely warranted, the underlying information architecture was broken and couldn't be patched. Knowing the difference matters.

Uncertainty isn't a problem to solve before you start. It's the environment in which all product work happens. The question isn't "do we have enough information?", it's "what's the cost of being wrong, and how quickly can we find out?"

Low-cost-to-reverse decisions should be made quickly, with the information available. High-cost-to-reverse decisions, things that require major infrastructure changes, long sales cycles to undo, or public commitments, deserve more investment in reducing uncertainty before commitment.

The most expensive uncertainty is the kind that hides behind confidence. Teams that are too aligned too early stop questioning their assumptions. I try to protect the space for productive disagreement, not endless debate, but specific challenge of specific assumptions before they get baked in.

This framing, business vs. UX, is usually a sign that something has gone wrong upstream. In most cases, they're not in tension; they're just operating at different time horizons. What's bad for users in the short term (friction, confusion, effort) is bad for the business in the medium term. What's good for the business in the short term (aggressive upsells, dark patterns, manufactured urgency) is bad for users and therefore bad for the business over time.

When a real tension does exist, I make the trade-off explicit rather than pretending it doesn't. "We're adding friction to this step because it reduces fraud, and we accept that some users will drop off" is a real product decision that deserves to be named. Burying it in a design spec means nobody owns the trade-off.

The best product decisions I've been part of started by asking: what does the user need to accomplish, and what does the business need to happen? More often than not, there's a path that serves both, you just have to look for it instead of defaulting to one side.

Good product leadership isn't about having the best ideas. It's about creating the conditions where the best ideas can surface and survive long enough to be tested. That means slowing down premature convergence, protecting space for dissent, and making sure that the team understands the problem deeply enough to generate solutions you wouldn't have thought of yourself.

The most important skill I've developed isn't product strategy or data analysis, it's the ability to distinguish between problems that need more thinking and problems that need a decision. The former benefits from exploration. The latter gets worse with delay. Conflating them costs time and morale.

Leadership also means being willing to be clearly wrong. When a decision I made doesn't work, saying so explicitly, naming what I assumed, where the assumption broke, and what I'd do differently, creates more trust than trying to reframe it as an ambiguous result. Teams that can learn from failures do better work than teams that have to pretend failures didn't happen.