People love to spend time on prioritization.

After all, if you don’t spend time prioritizing business initiatives, you won’t be making progress in the right directions, right? Well, maybe not.

In a perfect world, prioritization could be done using a simple formula: Divide the expected outcome of an initiative by its cost, and go for the highest ratio. For example, say you’re building software. One potential product has an expected revenue of $50 million and costs 10 person-years to develop. Another product has an expected revenue of $100 million and costs five person-years to develop. You’d naturally pick the second because the return on the investment is highest.

Indeed, there are numerous product prioritization frameworks based on this principle that put rigor behind assigning scores to product features.

This may work in an Economics 101 course, but is hardly relevant for real-world software businesses. The problem? In the real world, the numbers are meaningless.

Why? Because especially when it comes to innovation-related initiatives (those not implemented before), effort and impact are practically impossible to truly estimate. People are notoriously optimistic when it comes to estimating effort and, as it turns out, quite bad in making predictions—especially, as an old Danish proverb goes, about the future.

The situation is even more complex in modern agile products.

In the software world, we implement a small subset of new product features and iterate based on customer feedback. If we were to prioritize, would we prioritize the first subset (which often doesn’t deliver a lot of business value), or the overall product, which is yet to be scoped?

Structured prioritization frameworks are not helpful. When the choice is obvious, there’s no need for deliberation. And when there’s a close call, they don’t help much. Instead, I would like to point out a few unconventional angles that are often missed and can help decide which options to go for.

BIAS TOWARD TEAM HAPPINESS

Normal prioritization calculations weight in return vs. project investment, but don’t factor in the impact the work will have on your people. And people, as we all know, are the most valuable part of any business.

So first, one should consider picking a project that the team is excited about. Maybe they prefer it because they believe it has more business impact (even if you don’t). Maybe they believe it will help them advance professionally. Maybe it’s because they’re naturally more passionate about that particular area. Either way, they are likely to work more effectively because they feel they have made the decision on which way to go and gained autonomy over their work, and are more likely to deliver a significant outcome.

There is no shortage of statistics on the benefits of happy employees. Whatever the case, making your team happier will get better results in the long run.

BIAS TOWARD RECENT CUSTOMER REQUESTS

There’s a well-known cognitive bias called “recency bias,” which causes people to give more weight to recent events. In some areas, it is considered negative. In investing, for example, people react more strongly to the returns of the past six months than to the returns of the past five years—which is not necessarily helpful.

But in many areas—especially in addressing customer requests—basing priorities on recency is a good thing. A request that came in a week ago is more likely to be relevant than a request that came in a year ago. Market, technology, or business landscapes might have changed, and addressing more recent requests is more likely to be impactful.

In fact, I can speculate that an algorithm that selects which product feature to develop based on picking, say, the most recent feature request that came up more than three times, is likely to outperform many product managers.

BIAS TOWARD PASSIONATE, COLLABORATIVE CUSTOMERS

Many people are reluctant to prioritize requests just because they come from vocal customers. Wouldn’t it be better to objectively pick what to develop?

Well, I already outlined that objectivity is a bit of an illusion. In fact, the business impact of a feature, especially in B2B software, strongly depends on factors that go beyond its “unbiased value.”

For example, the closer you can work with customers to co-develop the feature, and the more involved they are in providing feedback along the way, the more likely the feature is to end up successful and impactful.

What’s more, the louder initial success is communicated—via testimonials or general enthusiasm—the more excited other people in the company will be about selling and promoting it.

I’ve written before about using design partners as a way to work closely with enterprise customers. Using such customers to help with prioritization is only a natural extension.

LEAN TOWARD MAKING FAST DECISIONS

If you could either take a weeklong vacation in Italy or France, assuming they cost the same and you have equal familiarity with their languages and cultures, which would you choose?

Your impulse is probably to make a “smart” decision. Spend time researching both, identify good reasons to visit each, weigh the reasons against one another, and then choose.

But in reality, are you considering the time to make a decision as part of the value equation? Is it really worth the time it takes to feel like you’ve made the “smart” decision?

In business, this is even more important.

Oftentimes, the people required to make a thoughtful decision are leaders of that domain. Their time is limited, and engaging them in the decision process is costly—both from a time spent perspective (is the decision worth their time?) as well as from a time-to-market perspective (how long does it take to make the decision?). For decisions where the difference between the options is meaningful, it naturally makes sense to invest time in considering all the angles. But if the options are pretty close, wouldn’t a fast arbitrary decision be smarter?

In my 20s, I used to sit in lengthy bug prioritization meetings, where multiple leaders would review software bugs, and tediously decide which ones are necessary to fix ahead of a software release. We would repeat this process for every release, often reviewing the same bugs. Today at Gong, we make an attempt to fix all bugs. The time spent on sorting them is more costly than the time spent fixing them.

CONSIDER USING AN UNCONVENTIONAL GADGET

An objectively sorted list of priorities doesn’t exist. Estimates of business impact and effort are always based on unknowns. Digging into close calls and making rationalized decisions is costly.

So, if you are unsure, may I suggest an unconventional gadget: a coin.

In many cases, tossing a coin and deciding based on its outcome may not be a bad idea. After all, Fidelity’s best investors are dead (because they cannot make deliberate decisions), and rumor says that even intergalactic wars were won based on coin tosses.