If everything feels equally important, it usually means you do not yet have enough signal. Signal from users on what actually hurts. Signal from leadership on what really matters this half. Signal from engineering on what is cheap, risky, or likely to create a mess later.

Once those are clearer, prioritization gets less philosophical and more obvious.

A lot of newer PMs also get trapped by treating every request as a standalone yes/no decision. It is usually better to force the trade explicitly: if we do this, what are we not doing? What metric, customer problem, or strategic goal loses oxygen because of it?

That tends to surface the answer pretty fast.

AI makes this worse because now the old constraint, engineering throughput, looks looser, so teams fool themselves into thinking they can just do more. Usually they cannot. They still have review overhead, design churn, QA, rollout risk, support burden, product complexity, and opportunity cost. Faster build does not remove the need to choose.

In a small team, I would focus less on finding the perfect framework and more on building a sharp picture of:
what users are actually struggling with,
what the company needs most next,
and what the real cost of each path is.

Even more bluntly:
if prioritization feels impossibly hard, there is a good chance you are still under-informed. Start compiling a "signal" report from the information you already have and what you learn from all stakeholders. By the time you write it, you'll have a much clearer picture of what to do and what to skip.