There are different frameworks to prioritize the product backlog. How practical is the use of such frameworks? How to manage top management expectations?

Ultimately, prioritization comes down to a chain of decisions. Regardless of the framework that you use, the question I see folks overlooking a lot is "who is the right person to make this decision". Is that you, the PM? Is that your manager? Or maybe, if the work relates to security vulnerabilities, is that your VP of Engineering? At Atlassian, we use the framework named DACI for all decision making documentation: https://www.atlassian.com/team-playbook/plays/daci The great thing about DACI is that it helps you align on whose call it is to make something a priority. You would be surprised how often top management expectations turn out to be just suggestions, whereas top managers will want you, the PM, to make the final call as an Approver in DACI terminology. 

My recommendation is to make draft prioritization of backlog using the framework that suits you, but be very diligent about whose call it is to prioritize something, and be proactive in communicating that to management and other stakeholders. This way, you will separate really critical items that may get prioritized based on someone else's decision making power from things where folks have just opinion, and ultimatley want you to decide.

The most important thing to prioritizing a product roadmap is to deeply understand your company's strategy. How does your leadership think about 1) Goals for the year (revenue, profitability, user retention/satisfaction, ...) and 2) Balancing goals that might contradict each other (revenue growth that might reduce profitability)? You can ask your manager, read up any material that talks about strategy and join all-hands or other forums to bring such questions to the table. Another important element is to understand what are the key metrics that are being used to define each goal and use those extensively in your prioritization. Once you understand the strategy, you can reframe any of the known frameworks to make it work for your team. 

To manage top management expectations, first ensure that you are proactively setting up some expectations. Share learnings as you gather stakeholder inputs for reviewing pain-points, be open to the unknowns, do roadshows or email share-outs of the roadmap and establish communication pathways (e.g. a bi-weekly newsletter) to share progress. Most gaps arise when either expectation is not aligned upfront or updates (e.g.a shift in priorities) are shared too late which surprises stakeholders.

The various frameworks are just guidance to help you think through the various approaches. There is no silver bullet; however, using a single framework helps to make decisions in a clear consistent manner. I don't prescribe a single framework to every squad in my team but when they use one framework they stay consistent unless the team is ready to get more sophisticated.

I recommend keeping this simple because the more dimensions to your framework, the more assumptions you are making and the less likely that your framework is accurate any more.

I also recommend that you start with your business goals - what goals need to be achieved and then what product outcomes will help you get to those business goals. That will help narrow down areas tremendously.

In managing product backlogs and aligning with both executive expectations and customer needs, I've found a focused approach to be most effective. This involves two main strategies:

1. Ongoing Lightweight Impact Assessment: As new requests and initiatives come in, I evaluate their potential impact on the business. This involves considering how an initiative will enhance the product, benefit customers, and contribute to our business goals. It's similar to using a simplified version of the RICE methodology (considering Reach, Impact, Confidence, and Effort) to prioritize tasks based on their expected value.

2. Quarterly Planning with OKRs: Every quarter, I identify 3-5 key projects that are most important to our executives and customers. By setting these as our Objectives and Key Results (OKRs), we focus on what's truly important. It's crucial to choose projects that are ambitious yet achievable, given our resources. This also involves ensuring we can still meet our ongoing obligations, such as performance standards and service level agreements (SLAs).

This approach helps keep the backlog organized and impact-focused. When it's time for quarterly planning, it's easier to select validated opportunities that align with our company's objectives and are likely to have a significant impact. By focusing on what really matters and ensuring alignment with broader goals, managing expectations at all levels becomes more straightforward.

Hopefully you have a senior/executive management team that believes in data-informed decision making. Data, by the way, is not just quantitative data (e.g. # of customers asking and their ARR) but qualitative counts for a lot, too, especially in B2B. If you don't have such a team, then this is job one, otherwise it doesn't matter what framework you have; prioritization decisions are going to be made by executive team opinion or pontification rather than examination of ideas through that framework.

But, assuming you have a management team like that, and largely agrees to let you prioritize based on a framework, then yes, you need one. I wouldn't recommend going crazy here. Effectively all you need to adjudicate whether an idea is worth pursuing is the old effort vs. impact measures. Now, there are many ways to come about this (t-shirt size, 1-10 scoring, etc.) but the most important thing is not the absolute score but the ability to compare ideas against one another. Why are we investing in this versus that? Sometimes the differences are small but meaningful.

Last point on these prioritization frameworks: place a few big bets (high effort but high reward) but don't forget to fill the jar with "sand" also (low reward/low effort).