The Best Prioritization Is No Prioritization

In the course of conversations with startups that I’ve invested in, that I advise, or that I simply encounter, it’s very common to get into discussions about prioritization.

Some common situations that I hear about all the time:

• We don’t know how to balance incremental features that our current customers want versus more differentiated / futuristic features that would help us sell.

• We don’t know how to balance tech debt or supportability investments versus business-oriented features.

• Our platform consists of 3 main products. One of them has the most revenue opportunity, one of them has the most upset customers, one of them has the most scaling problems. We’re figuring out which one to focus on first.

The advice that I give in almost every case – the best way to prioritize is to not prioritize.

Prioritization Sucks

Prioritization sucks for a few reasons.

First off, frameworks are BS. People have written breathless blog posts about product prioritization frameworks like RICE or the Kano model which are designed to generate imposter syndrome about your decision-making and encourage you to buy some online course. These frameworks are often largely vibes, or rooted in such completely abstract concepts or unknown assumptions that you might as well just ask ChatGPT what to do. Like what’s the meaning of “Reach” (the “R” in “RICE”) when we’re in a market that’s growing 50% YoY, or when we’re a startup with 10 customers? How do we calculate “Effort” (E) when AI coding is going exponential?

And just as importantly, the quality of your prioritization skills is unprovable. You’re only going to set your team on a single path, and proving that it was optimal retrospectively will be a purely philosophical exercise. Your business is going to thrive or it’s not, and it probably isn’t going to hinge 100% on this decision anyway. So while we can debate various merits going into prioritization, you’ll never even really know if you were right; you’ll just know whether the business overall worked or you got fired. As a side effect, this sort of unprovable philosophical argument is also a recipe to make people furious (“I told you that we shouldn’t have done that!”).

And of course reprioritization also takes a lot of cognitive effort. It’s wild how many planning meetings, summits, planning spreadsheets, and program managers can get rallied to answer the question “what do we do next week.” If your startup has less than 50 people and you see a Gantt chart, you should pull the fire alarm, throw out your employee badge, and run.

So there’s basically two alternatives to prioritization that work well.

The first is to just build faster. If you can only build one thing, what you choose to work on matters enormously. If you can build 10 things, you only need to have a vague sense of what a good idea looks like, and a sensible way of determining whether it’s actually working once it’s done.

The better you are at moving fast the worse you can be at prioritization. Prioritizing well requires being very clever. Building fast is great because you don’t need to be clever at all.

And I don’t mean this in some facetious, philosophical trick-question kind of way, I mean literally cut time spent on prioritization and refocus it on being faster. Instead of a week-long planning onsite with 2 travel days, have a half-day planning session and then spend an abbreviated offsite streamlining the build process, making sure teams are well-resourced, helping teams get into a better operating rhythm, and actually hanging out so that people are motivated to build faster. And then just do actual work for the rest of the week.

Speed pays dividends in basically every scenario and it’s empirically proven to work. There are many winning companies that make dumb prioritization decisions that they have to unwind all the time. There are no winning companies that move slowly. Also, shipping faster teaches you more about good prioritization than reading blog posts about backlog grooming. You’re unironically probably better off building 3x faster and going down your list of product roadmap candidates in alphabetical order.

The next strategy is to take cross-goal prioritization off the table entirely.

Team A is working on increasing sales for our new product, but what if they helped reduce support on our core product instead? Which is a higher priority? I dunno. What if we just literally didn’t ask that question, and teams stayed in their lanes forever?

Enforcing that teams always focus in one area takes a huge amount of total prioritization effort off of your plate. All of your decision-making turns into apples-to-apples comparisons within a fixed domain – for example, do I want my core product:

• To have less support issues

• To have more features that customers want

• To be cheaper to run

• To have higher reliability

These are vastly simpler questions than the apples vs. oranges comparisons like new product vs. old product. You can just ask customers or your CFO what they need, and all the variables are simpler. Also, your business would be stronger if you did all of these things (bringing us back to the prioritization point above).

Keeping teams together through thick and thin turns your prioritization problems (hard, difficult to prove correctness, cause significant context-switching) into resourcing problems (easier to reckon with, faster overall). Resourcing problems are far better because they’re less contentious and force you to transact in the world of facts – how fast is this team actually moving, how much actually needs to get done to ship. The fact that you solve resourcing problems by hiring, downsizing, or reorging teams is also an advantage because those activities take longer, which means that you’ll move slower on the decision, which causes less thrash, which gives more focus, which drives higher velocity (see above).

Teams that stick together are also a better match for certain types of problems. For example, if you’re running a high-upside experiment on a new product area, you could pare off a varying amount of resourcing every month to try to breathe life into it. Or you could just have 1-2 engineers spend 3 months seeing if they can go 0-1 on their own. The 2 engineer model is significantly more likely to work (simulates an early stage startup) and it doesn’t require any ongoing logistics. If the product takes off, add more resources. If it doesn’t, spin it down to 0.

This strategy is almost unfair in how well it works compared to constantly reprioritizing work. Stakeholder management also becomes dramatically easier. “When is that new product shipping?” is much simpler to answer if you don’t need to jump through the mental hoops of whether or not you could prioritize some other team’s project, and what that would do to other promises that you’d made. Even if that time is technically longer than pulling everyone onto the key project, the certainty and confidence that you can project typically make customers and internal partner teams happier overall.

Takeaways

Prioritization is a trap. It wastes time, wastes effort, and delivers worse results than just executing faster. Instead of spending your time prioritizing:

• Spend more time focusing on building faster (or literally just spend the time building)

• Shift everyone into durable teams that don’t have to do cross-business prioritization at all, and manage your “prioritization” by the resourcing decisions of growing, downsizing, or splitting teams

Share to X, Hacker News, LinkedIn