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.

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

→ You can read the rest of the article here (it's free!): https://www.blog4ems.com/p/product-vs-engineering-battle

Other useful links

• ?? Get 50 Engineering Manager Notion Templates.
• ???? 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!