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 high value post per week

As a paid subscriber, you get:

• 🔒 50 Engineering Manager templates and playbooks (worth $79)

• 🔒 The Engineering Manager’s Field Guide (worth $29)

• 🔒 A weekly "What would you do?" scenario & breakdown from real challenges EMs face

• 🔒 Full access to 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:

1. Product Feature: A new feature that the CEO has been asking for years and the team finally has time to work on it.

2. 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

• 📂 Get 50 Engineering Manager Notion Templates to streamline your workflow.

• 📕 Read The Engineering Manager’s Field Guide for practical leadership insights.

• 👨‍💻 Become a better Software Engineer with CodeCrafters – build Redis, Git & more from scratch (40% off with my partner link).

• 🎯 Book a mock System Design or Behavioral interview with me to prep for your next interview.

• 👋 Connect with me on LinkedIn for more Engineering Management tips.