When prioritization becomes difficult

In theory, prioritization should not be that complicated.

A company should have a strategy that gives direction to the work of product and engineering. When that direction is clear, many decisions become easier. Teams know what they are contributing to and why.

But this is not always the case.

Sometimes the strategy is unclear. Sometimes a new technology or trend suddenly shifts the conversation and everything starts feeling urgent.

When that happens, prioritization becomes harder than it should be. Discussions shift from purpose to opinion.

Internally, teams start questioning why certain initiatives matter more than others. Externally, customers and partners may feel that the product lacks a clear long-term direction.

Without strategy, prioritization often turns into debate instead of decision.

Implementation disagreements are about trade-offs

Disagreements about how something should be built are usually more complex.

From a technical perspective, many things are possible. The real question is how much time, effort and risk a certain approach introduces.

This is where many discussions actually happen. Should we build something quickly and iterate later? Or should we spend more time designing a more robust solution?

Speed often comes at the cost of stability, performance or security. Doing things more carefully often comes at the cost of time.

There is rarely a perfect answer. Most implementation decisions are simply trade-offs.

When data is missing

In many cases disagreements are not really about opinions. They are about missing information.

When good data exists, decisions tend to become clearer. Numbers help remove part of the subjectivity that often fuels debates.

But sometimes the data simply does not exist yet.

Maybe the product is new. Maybe customers have not used a feature yet. Maybe the team is exploring a new area where feedback is still limited.

In those situations there are usually two possible paths.

  • One option is to build something small and quick to test an assumption.

  • The other option is to wait.

Waiting is often underrated. If customers truly need something that does not exist, they will usually ask for it. That signal alone can be extremely valuable.

Experience and intuition still matter, of course. Looking at how other companies approach similar problems can also provide useful signals. But when information is limited, resisting the urge to overbuild is often a reasonable choice.

In situations like these, teams often feel pressure to move forward anyway and build something just to reduce the uncertainty.

But sometimes the more responsible decision is simply to wait and gather better signals before committing to a solution. I wrote more about this in another note on why waiting is often one of the most underrated product decisions.

Taking a stand without making it personal

One thing I’ve learned over time is that product managers need to take a stand.

If you are responsible for an area, you should have a point of view. That point of view should come after listening to engineers, designers and other stakeholders, but at some point you need to form your own opinion and be ready to defend it.

At the same time, it’s important not to become attached to that opinion.

The goal is not to win an argument. The goal is to build something meaningful and valuable.

For that to happen, disagreements must not become personal.

Assuming good intent from colleagues is essential. Most of the time people are trying to solve the same problem from different angles.

It also helps to remember that work relationships are still human relationships. Understanding the context other people are working in — the pressure they are under, the constraints they face — often makes discussions healthier and more productive.

Conclusion

In the end, product work is not just about deciding what to build. It is about helping teams move forward when smart people disagree.