Why deciding is the hardest part of product

I’ve come to think that most product teams don’t really struggle with execution. They instead struggle with deciding what actually deserves to be built.

Building is the comfortable part of the job. There’s something reassuring about having tickets, designs, deadlines, and a backlog that always moves. Even when you’re not fully convinced the thing will matter, at least you’re doing something. It feels like progress, and it’s easy to mistake that feeling for impact.

Thanks for reading Navigating the product galaxy! Subscribe for free to receive new posts and support my work.

Deciding, on the other hand, rarely feels good. Most of the time you’re working with messy signals, partial data, and problems that are not well defined. You don’t really know if you’re right. You just have a hunch, some evidence, and a lot of uncertainty. And unlike building, deciding creates visible consequences. Someone’s project won’t happen. Someone’s idea will get killed. Someone will feel deprioritised.

Building feels like progress

That’s where I think a lot of product stress actually comes from. When strategy is unclear, the default behaviour inside most organisations is to stay busy. Teams keep shipping, roadmaps keep filling up, and everyone can point to a long list of things that are “in progress”. From the outside, it looks healthy. Internally, it often feels oddly directionless.

The reasonable roadmap

One pattern I’ve seen over and over is what I’d call the “reasonable roadmap”. It’s full of projects that all make sense in isolation. Onboarding tweaks, pricing experiments, internal tools, compliance requests, SEO tasks. None of them are stupid. None of them are obviously wrong. But together they form a kind of graveyard of half-important things, where everything is justified and nothing is truly central.

You end up with ten medium-sized initiatives instead of one real bet. Each project has its own metric, its own stakeholder, its own narrative. But there’s no strong story about what the product is actually trying to become. No clear sense of what really matters most.

The emotional spiral

Over time, this creates a very specific kind of stress. You’re constantly forced to find “the next thing”. You spend a lot of energy justifying why the work matters, aligning different teams, reframing priorities every few months. You’re managing complexity instead of reducing it.

And because deep down you’re not fully convinced yourself, something else starts to happen. You begin to exaggerate impact in decks. A small improvement becomes “strategic progress”. A 2% uplift gets presented as a major win. Not because you’re trying to deceive anyone, but because you need the story to feel coherent, and without a clear strategy, coherence has to be manufactured.

I’ve seen this pattern lead to genuinely embarrassing outcomes. Teams shipping continuously for years, running experiments, launching features, doing “all the right things”, and still not moving the main growth metric in any meaningful way. A lot of motion, very little trajectory.

The political cost of strategy

What’s interesting is that this is rarely a problem of intelligence or capability. Most product teams are smart. They have good people, good data, good tools. The problem is political, rather than cognitive.

A roadmap full of “reasonable” projects usually means the team doesn’t have a strategy. And the reason often isn’t that people are confused about what to do, but that having a real strategy creates political cost. Real strategy means saying no in ways that actually hurt. It means telling a team their project won’t happen. It means telling a stakeholder their idea isn’t a priority. It means choosing one direction and explicitly letting others go. And in most organisations, that kind of decision creates tension, conflict, and risk for the person making it. So instead of deciding, organisations accumulate. Instead of committing, they spread bets. Instead of clarity, they produce activity. Everyone stays busy, no one feels fully accountable, and the system quietly rewards not deciding.

Burnout as avoidance

From the inside, this feels like burnout. You work constantly, manage endless projects, deal with competing priorities, and still feel like nothing really adds up. You start blaming yourself, or leadership, or “the system”, because you’re putting in the effort and not getting the sense of progress or recognition you expected.

From the outside, it looks like productivity. From the inside, it feels like running on a treadmill that never changes speed. The uncomfortable truth is that execution is rarely the real bottleneck. Most teams can ship. The harder part is staying with uncertainty long enough to form a real conviction about what actually matters, and then being willing to pay the social cost of acting on that conviction.

One real bet

This is where I’ve personally landed, after a few years of doing this job in different contexts. I no longer think burnout is mostly about workload. I think it’s mostly about meaning, and more specifically about spending a lot of energy on things you don’t really believe in.

I don’t have a clean formula for fixing this at a system level, and I’m not even sure one exists. What works is always to understand the customer problems and dig into the data, you can create a methodical system to do this but you can’t cut corners. Personally, I’ve ended up with a very simple rule that I try to hold myself to: I refuse to own more than one real bet at a time.

Not one theme, not one initiative per team, not a portfolio of “important” things. Just one problem or opportunity that I’m genuinely willing to defend, say no for, and be wrong about in public. Everything else might still be useful work, but it’s support, not strategy.

It hasn’t made my job easier. If anything, it’s made it more uncomfortable, because it forces more explicit trade-offs and more visible disagreement. But it has made it honest, and it’s the only way I’ve found to avoid spending years being busy on things I wouldn’t actually miss if they disappeared tomorrow.

In the end, I don’t think most product teams are suffering from complexity. I think they’re suffering from avoidance. Not of work, but of the kind of decisions that inevitably make someone unhappy. And until that becomes an explicit part of the role, a lot of product burnout will continue to look like a personal problem, when it’s really a structural one.

Thanks for reading! If this kind of thinking is useful, I write more about product, strategy, and decision-making at michelepm.substack.com.