If you’ve ever answered the interview question “How do you prioritize work?” by saying you use RICE, ICE, or MoSCoW, that might actually be the reason you didn’t get the job.
At first glance, this question may seem straightforward. But it’s one of the most important questions a product manager will face in an interview.
PMs operate in fast-changing environments where conflicting priorities collide with unclear responsibilities. How you approach prioritization reveals far more about your expertise than the frameworks you name.
Many companies deal with limited resources, endless stakeholder requests, technical debt, and complicated dependencies, and ultimately, someone has to make decisions about what gets done first. That someone is usually the PM.
Having a personal strategy for navigating these trade-offs matters far more than giving the “correct” interview answer. In reality, poor prioritization is one of the fastest ways to fail as a PM. And simply learning a few frameworks isn’t enough to succeed.
Why prioritization frameworks alone won’t make you a better PM
Of course, it’s ideal when a company has a unified approach to prioritization. But in reality, that rarely exists at the level needed for projects to truly succeed.
One of the most common mistakes companies make is choosing a single prioritization framework and applying it to every situation. Often it’s something like RICE or Impact vs Effort. On paper, this creates consistency. It feels like the organization has solved the prioritization problem.
In reality, it’s usually just an attempt to standardize product operations. And it almost always falls short. The reason is simple: the total volume of work inside a company cannot be compared using a single framework. The nature of that work is simply too different.
The problem with using one framework for everything
Imagine comparing a new onboarding flow with a database migration using a revenue-based prioritization framework.
The onboarding flow will almost always win because its impact can be measured in dollars. But in reality, the onboarding flow won’t matter if the database crashes under the new traffic.
You can’t meaningfully compare a growth task with a stability task using the same formula. And that’s before we even consider other critical variables:
- Is leadership aligned with the direction?
- Are there stakeholders who might block the project?
- How confident are we that the solution will work?
Try to imagine a formula that could realistically account for all of those factors. It doesn’t exist.
Why different types of work can’t be compared the same way
The right prioritization framework depends entirely on the type of decision you’re making. The key to successful prioritization is identifying the real problem first. And that problem has to go beyond simply saying “there’s too much work.”
Effective prioritization is a multi-step process. You choose the technique based on the situation you’re in. In other words, you match the tool to the tension.
Match the framework to the situation
Before choosing any framework, diagnose the specific blockage in your decision-making process. Different problems require different approaches.
If the team already agrees on the goal and you’re simply debating the most efficient path, use frameworks like RICE or Impact vs Effort. These tools help optimize decisions when everyone is already aligned on the objective.
If you’re dealing with conflicting departments or strong personalities, skip the math entirely. Use MoSCoW instead. In this case, the goal isn’t to calculate the best ROI. It’s to create a shared commitment about what you are explicitly not going to do.
If the strategy itself is unclear, feature-level frameworks are a distraction. Instead, shift to outcome-based prioritization. Align work to OKRs or strategic themes. If a feature doesn’t move the core objective forward, it doesn’t belong in the discussion.
When prioritizing technical debt or platform stability, traditional impact metrics often fail because they favor visible product features. In these cases, frameworks like Value vs Risk or Cost of Delay help change the conversation from “Why should we build this?” to “What do we lose every day we wait?”
And if you’re still in the discovery phase, feature frameworks are premature altogether. You should prioritize the problem space, not the roadmap. Techniques like Opportunity Sizing or Problem Severity vs Frequency help determine which problems are worth solving first.
The real skill behind great prioritization
Here’s the surprising part. To master prioritization, PMs don’t actually need to master frameworks.
Learning a framework is the easiest part of the job. The real challenge is correctly assessing the situation when everything is urgent, and every stakeholder thinks their work is the top priority.
When deadlines are all labeled “ASAP” and your stakeholders include both HiPPOs and ZEBRAs, a better spreadsheet won’t save you.
What you really need is clear thinking. Before choosing any framework, ask three questions:
- Where are we right now?
- What kind of decision are we making?
- What problem are we actually trying to solve?
The answers to those questions matter far more than the formula you apply afterward.
Why prioritization should never be a one-time decision
Think about a simple example. You’re at your office and need to go to the post office. Before deciding whether to walk, take a bus, or call a taxi, you consider several factors:
- Distance between the locations
- Available transportation
- Your budget
- The urgency of the task
Prioritization works the same way. And just like travel decisions, prioritization is never static. I once joined a company and asked a colleague why the team was about to build a feature that didn’t seem to make sense. They explained that earlier in the quarter, they had run a prioritization session, and this feature ranked next according to their ICE scoring.
I pointed out that the company’s objective connected to that feature had already been cancelled. Their response? “You can check the Excel sheet to see how we prioritized it.”
As you can probably guess, the feature shipped. And nobody used it. Because it was built in isolation and the users never actually needed it. Good prioritization requires revisiting decisions when new information appears. If the context changes, the priorities should too.
Align on criteria before you start scoring
Another common mistake in prioritization happens before the framework is even applied. Teams often fail to align on what the scoring criteria actually mean.
Take the ICE framework as an example. When someone says “Impact,” what exactly does that refer to? Does it have an impact on user outcomes? Business metrics? Strategic goals? What about “Confidence”? Does it represent evidence quality, validated assumptions, available data, or technical feasibility?
And when estimating “Effort,” what does that include?
- Design work
- QA
- Coordination
- Rollout
- Support
- Opportunity cost
Or just developer hours? If teams don’t explicitly align on these definitions beforehand, they’re essentially speaking different languages during the prioritization process.
Great PMs manage the gap between plans and reality
For experienced product managers, prioritization isn’t about identifying a static “number one.”
It’s about managing what I call the Prioritization Delta — the gap between your theoretical plan and the messy reality of new information. Priorities shift as markets change, strategies evolve, and new insights emerge.
Strong PMs don’t treat prioritization as a fixed spreadsheet exercise. They treat it as an ongoing process of decision-making and recalibration.
Final thoughts
Prioritization isn’t a spreadsheet exercise, and it’s not a one-time event. It’s a continuous decision-making process that requires clarity of context, shared understanding of criteria, and the ability to choose the right tool for the situation. Frameworks help structure thinking, but they don’t replace it.
Great PMs don’t start by asking: “Which framework should I use?” They start by asking: “What problem are we actually trying to solve?” That question is what turns prioritization from a mechanical task into a true product leadership skill.
Author bio
Vira Chesnokova is a Product Manager at Nulab responsible for scaling through strategic growth initiatives and AI integration. Their mission is to bridge the gap between cutting-edge technology and measurable business impact.
About Author
