The Best Prioritization Is No Prioritization

Stay SaaSy

SubscribeSign in

The Best Prioritization Is No Prioritization

Stay SaaSy<br>Jul 28, 2026

Share

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.<br>Some common situations that I hear about all the time:<br>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.<br>Prioritization Sucks

Prioritization sucks for a few reasons.<br>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?<br>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!”).<br>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.<br>So there’s basically two alternatives to prioritization that work well.<br>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.<br>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.<br>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.<br>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.

Subscribe

The next strategy is to take cross-goal prioritization off the table entirely.<br>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?<br>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:<br>To have less support issues

To have more features that customers want

To be cheaper to run

To have higher...