How to win the Product vs. Engineering prioritisation battle
Use the same scoring system for all projects and watch your roadmap finally make sense.
It’s Monday morning. Your inbox is already exploding. Slack notifications won’t stop. Your product manager pings you before your coffee’s even had a chance to cool:
“Hey, any chance we can squeeze this feature into the quarter? Super high priority. CEO is asking.”
You glance at your roadmap. Three large features are already planned. Tech debt work is completely deprioritised. The engineers on your team are frustrated - we have important tech debt to get to. Leadership is asking why things are taking so long.
And you already know how this plays out…
The Same Old Story
This happens in nearly every company. And it usually ends in one of two ways:
🟢 Product wins: New features get built and we keep piling up tech debt.
🔵 Engineering wins: Tech Debt gets reduced slightly, but the product manager feels like nothing is moving forward.
Neither is a good outcome.
I have seen:
Product work being prioritised when it has the potential to generate revenue (+$).
Engineering work being prioritised only after a severe customer-impacting incident occurs (to prevent more -$).
This system is broken.
Every project should be assessed the same way.
Let’s discuss how.
If you enjoy posts like this, consider supporting my work and subscribing to this newsletter.
As a free subscriber, you get:
✉️ 1 post per week
🧑🎓 Access to the Engineering Manager Masterclass
As a paid subscriber, you get:
🔒 1 chapter each week from the book I am writing “The Engineering Manager’s Playbook”
🔒 50 Engineering Manager templates and playbooks (worth $79)
🔒 The complete archive
Engineering Work Needs a Clear Case Too
Just like product features need a strong business case, engineering work should follow the same standards. Too often, technical projects, like migrations, or addressing bigger tech debt are dismissed because their value isn’t clearly stated.
Every significant piece of work, whether product-driven or engineering-driven, should be able to have first a project proposal that includes:
The problem statement – What specific issue is this solving?
Business value – Will it improve stability, reduce costs, speed up development, or prevent customer issues?
Risks addressed – What happens if we don’t do this? Will downtime increase? Will future work take longer?
Effort required – How much time and how many people are needed?
When engineering work is framed following the same standards product work does, it becomes easier to compare their priority against each other, align stakeholders, and technical improvements get the attention they deserve.
One Scoring System
Once you work with your team to have engineering and product projects in one list you will need to prioritise them somehow.
There’s a framework that can help with this: RICE.
RICE stands for:
Reach – How many people will be affected?
Impact – How much will it improve their experience?
Confidence – How sure are we about the feasibility of the project?
Effort – How much work is needed?
By scoring every project the same way, you remove bias (somewhat at least). It’s no longer a debate about "tech debt vs. product". Instead, it’s which projects bring the most value to the company.
How RICE Works
Imagine your team has two competing priorities:
Product Feature: A new feature that the CEO has been asking for years and the team finally has time to work on it.
Engineering Fix: An infrastructure upgrade to improve system stability.
According to the CEO, the product feature has been asked by many customers and will have a significant impact. Leadership might push to prioritise it immediately.
But let’s evaluate both with RICE:
Surprisingly, the infrastructure upgrade delivers significantly more value per unit of effort compared to the new feature. This might not have been immediately obvious without using RICE.
This is what makes RICE so powerful: it replaces arguments with data. Instead of debating priorities, teams can use data to make decisions.
And in this particular scenario, this would be the only way I would be comfortable using to meaningfully push back the CEO’s request.
How to Get Your Team On Board
Even if this makes sense, you might still face pushback. Change is hard. Here’s how to roll it out smoothly:
1. Make It a Team Effort
Bring your product manager and engineering team together to agree on the scoring system. You need to have buy-in from everyone.
2. Use Past Projects to Show the Impact
Pick a few old projects, score them retroactively, and compare. It helps people see why this approach is fairer.
3. Apply It to Everything
No exceptions. If a project needs time and people to be worked on, it gets a RICE score.
4. Make Decisions Based on Scores
Once scores are assigned, sort projects by their final number. The highest scores go first - no debates, no gut feelings.
Faster Progress
When product and engineering use the same rules, something magical happens:
Engineers feel heard because tech debt is judged fairly.
The Product Manager better understands engineering work.
Leadership can finally see why certain projects take priority.
Most importantly? Your team moves faster.
And the next time someone asks:
“Why are we prioritising this over that?”
…you will have an easier time answering it.
You’ll have a score.
You’ll have data.
You’ll have alignment.
Some useful links from me
👨💻 Become a better Software Engineer with CodeCrafters (use my partner link to get 40% off and build your own Redis, Git, Kafka and more from scratch).
🎯 Book a mock interview with me (System design or Behavioural & Leadership) to smash your next real interview!
👋 Let’s connect on LinkedIn!
Really important topic and great post!
The critical component is to agree, beforehand, on a prioritization framework. RICE is a great place to start, but even if you end up tweaking it or using something else, it doesn’t really matter. As long as there is real alignment on how to prioritize, most of the conflicts will be avoided.
Actually, no.
The conflicts won’t be avoided.
They will be front-loaded to the prioritization framework/criteria discussions.
This is a GOOD thing. The goal is not to avoid conflict, healthy conflict is critical to achieving great things. The conflict will just be out in the open, at once, instead of spread around dozens of implicit and explicit conflicts that drive engineers crazy.
While I do not work directly in Engineering or Product, I work closely with both teams in my Data Analytics role. Leveraging the RICE method to prioritize I can see having application across the various business units, to get to the right prioritization for the most impact. Thank you for sharing the wealth of information.