Prioritizing is easy, really.
One of the easiest things in product development is prioritizing. It’s one of the most important and, as such, people tend to overcomplicate it. Much has been written and theorised about it at the expense of actually being useful. Let’s simplify. You can be in one of two states: either you have a task that is clearly the thing to be done next and everyone in the team agrees, or you are undecided between options about what to do next.
What really matters is deciding what to do next. If you are uncertain what to do in 6 months, don’t decide; keep the options open. Therefore, if the product team all agrees on what is the right thing to do now, you have that part solved. If you are uncertain amongst several options on what to do next, then you and your team haven’t explored the product problem deep enough, and you are still navigating on the surface level where solutions look about the same (given that you are working with a large enough scope to find interesting problems to solve). If you still can’t decide, then just pick one. If after investing some time on a problem there is not a clear winner, then there is still too much uncertainty, and it can’t be planned out without execution, so you need some execution. Solved.
One could argue now: But how do we determine what is the right thing to do? Well, that’s taste.