Engineering leadership and productivity tips straight to your inbox?

Ruthless Prioritization

By John Lafleur 2 minutes read

TL;DR: All high functioning teams must prioritize. Not once a month, not once a week — but rigorously, and ruthlessly. There is always a way to accomplish your goal faster than you currently plan to.

The craft of making prioritization decisions is one of the most difficult skills to impart on teams because of how complex those decisions can become, and while it’s usually a core responsibility of product managers, I’ve found that the best teams are the ones where everyone is maniacally prioritizing towards the same goal, and doing so in a way that’s consistent with each other.

Prioritization in product management can be broken down into two scopes:

  • Prioritization between projects — this is about determining what project your team should do next.
  • Prioritizing work within a project —this is about how efficiently you can execute a project.

Prioritizing between projects

Answering this question may require rigour, but the process isn’t complicated:

  • Estimate return on investment for each project
  • Apply three constraints: dependencies, timelines, and team composition
  • Put the puzzle together — sequence projects based ROI + constraints

Prioritizing work within a project

The only way to combat the speed and chaos of building products is to develop a ruthless mindset, one that is constantly aware of the work a team is doing and challenges them on the necessity of that work.
A good strategy is to help teams internalize product development concepts that aid them in ruthlessly answering “is this absolutely necessary?”. Here are the one’s we’ll cover in the remainder of this post:

Building prioritization systems

One of the highest leverage things you can do is to create a system that determines when to fix bugs or when to move on.

Using product assumptions to make quality vs. speed trade offs.

If you think about your product, there are three situations you can be in with respect to your product assumptions:

  • The problem you’re trying to solve is an assumption. You want to focus on speed.
  • The solution to fulfill a known problem is an assumption. You want some kind of balance between speed vs quality.
  • Neither are assumptions (you know exactly what’s needed and why). You want to focus on quality.

The Time Value of Shipping

We should be able to place a value on shipping something faster to customers. Shipping 80% faster could get 20% of customers upset, but in the end they will be served as fast as if you shipped only when 100% was covered. Ship at 80% if you can.

Challenge your team to be better. Challenge them to be ruthless.


Want engineering leadership and productivity tips?

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.
%d bloggers like this: