From 60 “must-haves” to actually shipping: a practical lesson in prioritization.
I’ve been in situations where stakeholders handed over a list of 60+ things they wanted to achieve—some of them sitting there for years. The frustration was always the same: “Why hasn’t anything been delivered?”
At the same time, the development team was constantly busy. Just not on these things.
That disconnect is more common than we admit.
“Everything is a priority” is the fastest way to achieve nothing
When everything matters, nothing moves
The real issue wasn’t capacity. It was clarity.
When every item is labeled as “important,” teams lose the ability to make meaningful progress. Work gets fragmented, priorities keep shifting, and outcomes stay stuck in limbo.
So instead of trying to push delivery harder, I stepped back and focused on prioritization.
Running a prioritization workshop
I set up a workshop with stakeholders to bring everything into one place and force a conversation around trade-offs.
We used the MoSCoW method:
- Must have
- Should have
- Could have
- Won’t have (for now)
It’s simple, intuitive, and works well when you need quick alignment without over complicating things.
The hardest part: “Won’t Do”
As expected, the biggest resistance came with the “Won’t Do” column.
“These are all important. We can’t skip any of them.”
Fair point—on the surface.
So I reframed it:
“This isn’t ‘won’t ever do.’ This is ‘won’t do in the next two quarters.’ If priorities change, we can revisit.”
That small shift made a big difference. It turned a hard rejection into a time-bound decision. Eventually, they agreed.
Breaking the list into reality
Once we started sorting, patterns emerged. Finally wt had two clear groups each further sorted with MoSCoW:
- Small improvements: quick wins, incremental value
- Big initiatives: larger efforts that needed new thinking or full transformation (epics)
This separation helped a lot. It gave us a practical way to balance short-term delivery with long-term impact.
Forcing focus at the sprint level
For the upcoming sprints, I asked stakeholders to commit to:
- 1 big initiative
- 2 small improvements
Alongside that, the team continued working on ongoing initiatives and technical debt.
This wasn’t about limiting ambition. It was about creating focus.
What changed
We didn’t magically deliver all 60 items. But we started shipping.
Small improvements went out faster. Bigger initiatives got proper attention instead of being half-started and abandoned. From the top 10 priorities, we were able to deliver meaningful value within a couple of quarters.
That shift—from activity to outcomes—made all the difference.
Final Thoughts
Prioritization isn’t just stacking features by deadline. It’s an exercise in making trade-offs—often uncomfortable ones.
If you can’t clearly explain the cost of delay for a feature, you’re not really prioritizing. You’re reacting to whoever is the loudest in the room.
Product management requires the discipline—and sometimes the courage—to say “no” to good ideas, so you can say “yes” to the ones that truly move the needle.
How do you handle pushback when you have to deprioritize a stakeholder’s “must-have”?
