Help newbie teams get their feet wet first by shipping small wins. Once they have a few production features under their belt, they can progress towards more complex projects.

Prioritizing between projects: Complete the puzzle and get to work

I’m trivializing the amount of work it takes to gather all the information above, but once you have it all, you just have put the pieces together.

Prioritizing work within a project

A ruthless mindset to determine: Is this absolutely necessary to do?

The nature of prioritization is different during the execution of a project. It’s chaotic. Decisions are needed everyday, and you don’t have time analyze each one as deeply as we did when prioritizing between projects. It’s also a more emotional time for a team, as real customers are going to be impacted, and their reputation may feel on the line.

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.

Having a ruthless mindset means accepting reality. It’s a realization that you will have to make hard choices every day on where to focus. It’s a realization that shipping the perfect product is an illusion, and that trade-offs are always required to ship.

Having a ruthless mindset is about the will to ship. Stakeholder and customer expectations create enormous pressure on teams, and as a result they are often afraid to ship. They start sweating tiny issues so much that they’re frozen into inaction. They start losing sight of what matters, customer value created over time, and start trying to be perfect.

Show me a team that has no bugs at launch, and I’ll show you one that should have shipped a long time ago.

In reality, the chaotic nature of prioritizing work within a project means that defining a process around it is foolhardy. A more productive 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 Using product assumptions to make quality vs. speed trade offs The Time Value of Shipping

1. Building prioritization systems

All software is a liability. It has bugs now, and it will develop more over time. When faced with a new bug, if your team can’t quickly figure out if they should fix it or not, their ability to focus on the most important work will be constantly disrupted.

You can’t afford to have a prioritization meeting every time a bug pops up, so 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.

Here’s an example of one that I’ve found productive for my teams:

The X axis represents the frequency that a bug affects users, and the Y axis represents the severity of that bug. A red dot is a bug.

To use this system, work with your team to define what level of severity is too severe (in this case, that users can’t pay) and which level of frequency is too frequent (in this case, 5% of users affected). Then, agree on a set of actions given which zone the bug falls, with at least one of those actions being put in the backlog and do nothing.

If you invest in this, your team will be a bug triaging machine, and the chance of someone working on a low value bug will be systematically removed.

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

You’ll often hear about shitty code written by founders in the early days of a product. As the company became successful, this code created nightmares for new engineers joining the team.

Were the founders poor programmers? Maybe. But more likely than not, they didn’t care much about code quality at the time because the product was unlikely to succeed. Instead, they cared about speed and validating their idea.

In order to ship, every team invariably makes some sacrifices to quality. Teams have to choose when enough is enough, and that comes down to a prioritization decision about what is essential to the quality of a product.

Here’s a useful way to guide yourself to the right spot on the spectrum of speed vs. quality: base it around your product assumptions. Product assumptions are fundamental beliefs that you hold about a customer problem, or the solution you’re building for them.

A simple example from the early days of Facebook would have been the problem assumption that people want to connect with each other online. Once that problem was validated, they then thought of product ideas like being able to add another user as a friend, which is a solution assumption about how to solve that problem.

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