Product managers are playing both strategy and tactics.

Strategically, you set the long-term goals that inform the product roadmap.

Tactically, you want to ensure your Agile team is following the roadmap and delivers as expected. It looks like all you need is to prepare the backlog, prioritize it, push into development and follow up on the status and results.

Sounds like a plan, except that you have to re-plan on an ongoing basis to adjust for emerging changes.
You plan for what you know, and acquiring new knowledge may affect the plans. Besides, the team may get bogged down in some delivery challenges that may fire back at the strategic plans as well.
So you have to stay flexible while also guard the strategy.

Your only salvation is prioritizing. And re-prioritizing. Like juggling.

Define the priority scale

Start with defining the priority scale to clearly communicate the level of importance of the backlog item. For instance:

• Critical — items that have to be fixed/delivered as soon as possible. These could be incidents or delayed features that are badly needed in production
• High —items that have to be addressed first thing after the critical ones are dealt with
• Medium — items of medium importance, which are good to have; no immediate need
• Low — something that rarely ends up in the sprint backlog, and often ‘dies’ in the product backlog never being implemented

Choosing clear and unambiguous titles makes the proper understanding and work with priorities an easy job for your team.

Do not go for more than four, as probably the items of the lowest priority do not deserve to exist in your backlog at all.

Employ prioritization techniques

Now that you have the priority scale, you need to assess the backlog items against it. And here are some effective prioritization techniques that would help you with that.

Cost vs. Value
Evaluate your backlog items based on the value they deliver and relative implementation complexity. The composite score of both will inform a priority:

• Drop those of low value but requiring considerable implementation effort;
• Assign low priority to the low-value & low-effort items;
• Think twice about the items with high value but requiring significant effort. Don’t take many of them into one sprint as more complexity usually means more risk, which may negatively reflect on the success of the sprint;
• Grant higher priority to those bringing the highest value and requiring the lowest effort as they are the low-hanging fruit.

Guidance by the roadmap
For your team to be productive and steadily move towards accomplishing the goals, you need to keep the big picture in mind.
Set into the habit of constant review of where you are going and what to channel your efforts on.

“Prioritizing without goals is like scaling mountains without maps.”
— Mike Cohn

Important vs. Urgent
Urgent doesn’t mean important, urgent is not always a priority.
If someone says that something is urgent, you need to get it straight who it is urgent for, why the urge, what would be the consequences of doing and not doing the task, and what is the cost of delay.
What is claimed to be urgent may have a very low likelihood and severity, thus not being important at all.

Being busy working on the emergencies, you may drastically fail on productivity, risking to sacrifice progress on something bigger (remember your roadmap?).

Technical enhancements & Bugs vs. Features
Optimizing the code and resolving bugs is no doubt useful. But again, as a product manager, you want your team to be productive and deliver a product increment each and every iteration. That means you have to balance different types of product items and select the optimal combination for a sprint.

Most risky go first
Typically, your sprint backlog contains items of various uncertainty and complexity, causing a different impact on the existing functionality and requiring a different amount of testing.
Make the riskiest items a priority to reveal the lurking impediments as early as possible and decide on the course of action. For instance, you might want to launch the additional research and re-plan the implementation until after the research to eliminate the undesired consequences.

Prioritization of bugs by policy
The gist of it is in establishing the rules which define how quickly a bug should be fixed.
This one is very well explained by Mike Cohn in his article Defect Management by Policy: A Fast Easy Approach to Prioritizing Bug Fixes

Work with dependencies
Address the blocking items first to avoid the lockout of dependent issues.

Effective prioritization on the tactical level keeps you flexible while also secures your definitive movement towards achieving the strategic goals.
Prioritizing can be tough sometimes, though you will inevitably master it with practice and experience. Whoever tried juggling knows that the balls had fallen dozens of times before one became capable of juggling freely. Focus, accuracy, and timing are essential.