Prioritization needs to start with value, not effort

One of the thoughts that ruminated on my mind during 2020, was about the common practice of prioritizing features based on effort/cost/time.

When the backlog is being prioritized, the most asked questions by everyone in the team (including ourselves… maybe mainly ourselves) are:

“How much time will that take?”…

“How difficult it is to build?”…

As PMs, we even have popular frameworks to help us prioritize based on effort, as the RICE framework (Reach, Impact, Confidence, and Effort).

But when our main concern as a product team should be the outcomes; when our main focus is the impact that our features have on the business and on users’ behavior; then why we always start with effort in mind?

The quick and correct answer is that… it shouldn’t be this way.

If a feature takes less time but it’s less important — as in, has less impact in our goals — then, in most cases, it shouldn’t have higher priority (as RICE implies).

Actually, if it doesn’t have a reasonable effect in our goals, then the team shouldn’t even spend their time and focus in analyzing it in detail (e.g: defining the implementation approach, estimating, etc).

Naturally, and as always, it depends… Every situation is different, and sometimes rules need to be broken. And as a PM, you need to have a 6th sense to know when to break them.

But there are some questions we should ask ourselves when prioritizing a feature:

Is this feature in line with the goals we traced for the month/quarter/year? If not, did the goals change?

It’s normal that, as a product team, we have requests that are outside of the initial plans. Things change, goals change, and sometimes very fast.

But it’s important to first acknowledge what changed. Because it’s crucial that whatever we build has a purpose in line with our strategy.

This feature request may be very important because a client has been pressuring the business to build it, and is even threatening moving to a competitor if not.

But that means that the strategy has shifted, and that making this specific client happy has now become our priority for the following times.

Do we have some confidence this work can have impact on the desired outcomes?

If we don’t have confidence that the requested feature will move the needle — even assuming the feature will be just an experiment, — then why should we spend the time, focus, and resources in building it?

Why should we even spend our energy analyzing the feature in detail and estimating our effort?

Only then, only after asking ourselves these sort of questions, do we prioritize the filtered features based on effort.

Only after we have the confidence that those features will have impact in our outcomes according to our strategy, do we evaluate their effort and apply frameworks as RICE.

Only then do we understand if the effort/cost/time to build it is worth its impact.

If you enjoyed the read, please click the clap button to recommend it to other interested readers!

I’m Daniel, passionate about building great digital products, with 8+ years of experience as Product Manager — from MVPs to Series A — and in building a great company from the start.

Paper Planes is the place where I reflect on my experiences and lessons on the craft of Product Management.