What if the right response to too many priorities isn't better prioritization?
Two articles made me think about the same problem: finding the optimal answer can become more expensive than acting.
One was The Pudding's experiment on mowing lawns. The other was Stay SaaSy's The Best Prioritization Is No Prioritization.
One is about finding paths through complicated lawns. The other is about deciding what software teams should work on.
Complexity makes optimal expensive
As a lawn gains obstacles, the number of possible paths grows. Eventually, finding the shortest route costs more than it saves.
So people use heuristics: divide the lawn into sections, finish nearby areas, and avoid backtracking. The result may not be optimal, but it is cheap and usually good enough.
Product prioritization has the same problem. Given 20 plausible projects, you might weigh impact, effort, dependencies, opportunity cost, risk, and what each project could teach you.
Organizations add another complication: they may not agree on what “best” means. Prioritization becomes a problem of computation, information, and coordination.
Make wrong decisions cheap
Stay SaaSy makes a useful observation:
The better you are at moving fast, the worse you can be at prioritization.
If shipping takes six months, choosing badly is expensive. You spend more time trying to choose correctly.
If shipping is cheap, you can make a reasonable decision, ship, learn, and change course. You don't need to predict the best path when a wrong turn is easy to undo.
Speed doesn't just help you do more. It reduces how correct your decisions need to be.
Reduce the search space
When lawns get complicated, successful participants don't optimize the whole lawn at once. They divide it into smaller regions and solve those locally.
Stay SaaSy proposes a similar approach: give durable teams bounded problem spaces and let them make smaller decisions.
Instead of centrally ranking 20 unrelated projects, allocate people to a problem space and let them decide what matters there.
You aren't getting better at global prioritization. You're designing the system so you need less of it.
As complexity grows, the answer isn't always to search harder for the perfect path. Reduce the search space, use good heuristics, move quickly, and make mistakes cheap to correct.
The advantage isn't always finding the best path. It's making good-enough paths cheap to explore and abandon.