Summary

The article argues that while frameworks like WSFJ, ICE, and RICE can assist in product development prioritization, they should not be solely relied upon; instead, a focus on objectives, discovery, and empathy is crucial for making informed decisions about what to work on next.

Abstract

The article emphasizes that in the SaaS industry, where innovation is key, product managers must be cautious not to over-rely on popular prioritization frameworks. These frameworks, while helpful for organizing thoughts and fostering team discussions, cannot replace the nuanced understanding gained through discovery and alignment with company objectives. The author suggests that prioritization is a multi-level process that should begin with clear goals and involve understanding the problems that need solving. Teresa Torres' Opportunity Solution Tree is recommended as a tool to visualize and evaluate potential solutions against desired outcomes. The article stresses that frameworks are not decision-making algorithms and that product managers must incorporate empathy and ethical considerations to avoid developing products that do not address real user needs or could be considered unethical.

Opinions

The author believes that agile methodology has been misconstrued, with the focus shifting from iterative development (agile) to the speed of delivery (agility), leading to an over-reliance on frameworks.
There is a skepticism towards the assumption that frameworks can accurately predict the reach, impact, or effort of a project without proper discovery and stakeholder engagement.
The article suggests that frameworks are beneficial for structuring information and facilitating conversations but are insufficient for making actual prioritization decisions.
The author advocates for a goal-oriented approach to prioritization, starting with clear objectives and using the Opportunity Solution Tree to assess potential initiatives.
Empathy is highlighted as a critical component in product management that is often overlooked by frameworks, which may lead to solutioneering without fully understanding the problem or its implications.
The author warns against the risk of becoming too dependent on frameworks, which can create bottlenecks and hinder the ability to experiment, measure, and learn from the product development process.

What is the best framework to prioritize what to work on next?

Short answer: None of them.

Long answer: None of them.

Let me explain, though.

In the world of SaaS products where customers are constantly expecting new things to play with, it can be difficult to decide what’s the next best thing to tackle.

We’ve got stakeholders to manage, customer to manage, and C-Level executives all with their own opinions about what you should do.

But how do you make the right decisions?

You get a framework, you get a framework, everybody gets a framework!

When the world changed from waterfall to agile, the need to want to predict things quickly followed thereafter.

The more you can predict how things will pan out, the faster you can get things out the door.

Let’s start with the first problem here: Agile is not the same as agility.

Agile is a methodology that focuses on small iterations. Instead of waiting for something to reach its ‘done’ state, you release things little by little and start gathering feedback as you see how people respond.

Agility is how quickly you get those things out the door.

At some point the thought process from small iterations changed to the speed behind the process, and if you can have a framework for that, why can’t you also have a framework to decide what things you will also be working on, right?

The Rise of the Framework Acronyms

And so rise of the framework acronyms came about…

WSFJ, ICE, RICE — take your pick, they’re all out there somewhere. Everyone from Intercom to Basecamp has raved about how their frameworks help them decide what to work on next, but here’s the big fallacy with that:

Frameworks are output driven and assume you’ve already done discovery on those items.

There is no way you can know the reach, impact, or effort on most things without properly having vetted if you’re even working on the right things, even less if you haven’t spoken to anyone about it. So how could you possibly have any confidence?

Prioritize with goals in mind

Prioritization is not a linear process.

You don’t just whip out a framework, tick all the boxes, and then stuff gets done.

Prioritization actually occurs on three different levels: on the roadmap, on the idea backlog, and on the development backlog.

When prioritizing, always start with your objectives. This will allow you to understand how the work you do will help you reach your goals. If you have initiatives that don’t meet your team’s current objectives, you already know what not to work on.

Once you have identified which initiatives do fit your current objectives, it’s time to figure out which ones will give you the desired outcome with the greatest impact.

This is where you can use Teresa Torres’ Opportunity Solution Tree.

The OST allows you to frame and visualize your thinking. It isn’t about what is the best or the worse thing to work on, it’s about understand what is in front of you and objectively asking the question — will this help me reach my desired outcome?

With that in mind, let’s look at the four key elements:

Desired Outcome: What we want to achieve.
Opportunities: The reason for a solution; one direction that could help fulfil the desired outcome.
Solutions: Potential ways of implementing that opportunity.
Experiments: Ways a solution will be tested.

Teresa Torres’ Opportunity Solution Tree

Once you have run experimentation and discovery on these items you will have a better idea of the following:

What are you working on and why?
Is it worth pursuing? (Will it give you the desired outcome?)
How will you measure success?

Now that you understand if something will give you the desired outcome can you really say with confidence — yes, this is the right thing to work on, this is what we foresee the impact being, this is the expected customer reach, etc.

Now I do want to say, confidence is a bit of a loose term here. The reality is that adding a score to anything is a bit of an art itself — but don’t worry. You will get better at this the more you get to know your product and your team.

Sending things to development

After the product team finishes their discovery process and official implementation begins, you will then start sending things off to your development team.

They will be prioritizing based on their own capacity and knowledge, and because this is about the output (that is, the ‘how’ of the process,) they may choose their own specific framework — be it scrum, kanban, or otherwise.

The process here is entirely different. They have to take into account things like new improvements, bugs, and maintenance, ensuring they have a good balance between items.

So what are prioritization frameworks good for anyway?

Product prioritization frameworks are there to help you frame the information that is in front of you. They enable conversations between team members and assists with understanding relevant data.

What they aren’t there for: to make decisions for you.

If frameworks could make decisions for us, what’s the need for a product manager anyway?

Just input all the numbers and done! The algorithm has just done the job for you.

If anything, the more inputs you rely on to make decisions, the more of a bottleneck you create for yourself. Give yourself room to experiment, measure, and learn from the process.

Above all, frameworks lack one key aspect of product management: empathy.

There is so much more to deciding on what to work on next than just whatever ‘fits’ the framework’s inputs.

You must understand what problem you are trying to solve, why, and what the impact is of implementing various ideas. If you don’t take a step back and ask those important questions first, you run the risk of solutioneering too fast and ending up with what could be an unethical product.

To build human-focused products, you need human-focused input.

TLDR

Prioritization is not a linear process, and happens at different stages of development.
Start with your objectives, find problems to solve, and run discovery to better understand how different items may give you the desired outcome.
Frameworks help you understand and visualize information, foster conversations and discussions. They are not there to make decisions for you.