Enhancing prioritization with networks
By: Anton Iokov
Tags: Product Design, Software Development, Startup, User Research, Product Management

Last month Michael Dubakov suggested using networks to prioritize features. Now let’s go further and try to turn the idea into a practical framework.

This article is meant as a standalone so reading Michael’s post is a suggestion, not a prerequisite.

What are the prioritization techniques missing?

As a diligent product manager, you’ve done customer discovery and collected feedback. You notice recurring Use Cases and even some clusters which represent Personas or Niches:

Use Cases grouped by Personas, Niches or your favorite term

Your team blends empathy with product vision and invents Features to address the Use Cases:

Features address the Use Cases

Now it’s time to decide which Features you should build next. You pick a prioritization formula like Value/Effort or RICE so your teammates can follow your thoughts and rationally debate the score.

Here is what these formulas capture:

Prioritization formulas decomposed

So which of the two Features below should you build next?

Prioritizing these two Features is not a tough riddle, right?

Feature A has more value and takes less effort so it’s a no-brainer, case closed? Not so fast. The formula fails to capture two important factors.

How connected are the Use Cases?

Solving a bunch of unrelated Use Cases means building a product for everyone and no one. Most often than not, this is a bad strategy:

The true importance of a Use Case often lies in its connections

How does the Feature affect other Features?

Some Features open new possibilities and enhance existing functionality, others add complexity and slow the development down:

While some Features solve important Use Cases, they are damaging to the network

With these two questions in mind, let’s take another look at our alphabetical Features:

The same Features and Use Cases with their 1st-level connections

Feature A doesn’t look so good anymore — it would have been a shame to build it first.

Wonder why you often want to override the priorities determined by the formula? It’s because the prioritization formula is short-sighted. It doesn’t know that addressing this small Use Case will greatly contribute to your strategy. It doesn’t know that building this seemingly unimportant Feature will serve as a foundation for something bigger.

The good news is, you can teach the formula.

How to incorporate networks into prioritization?

.The goal is not to replace but to enhance the existing prioritization techniques. Let’s start with a simple formula and make it more c̶o̶m̶p̶l̶i̶c̶a̶t̶e̶d̶ nuanced step-by-step.

The simplest Value/Effort formula

Step 1. Break down the vague “Value” into pieces that facilitate discussion: Reach, Impact, and Confidence. All the Use Cases that the Feature addresses contribute towards the score:

RICE formula visualized: Reach×Impact×Confidence/Effort

Let’s compare the actual RICE scores for our favorite Features:

RICE scores with a lot of confusing numbers

Feature A is indeed a clear winner. For now.

Step 2. Incorporate Use Cases network into the formula. The importance of a Use Case is composed of its isolated value plus its network effect:

The formula enhanced with the Use Cases network effect

A note for really attentive folks When calculating the network effect for Use Case A, measure the ★ scores for other Use Cases excluding Use Case A from the network. Otherwise, a cyclic graph will eat your computer.

Use Cases that have a great effect on other important Use Cases get a boost. Unlike in PageRank, we count the outbound, not the inbound relations:

Examples of positive and negative network effects

Here’s how the scores change with the new formula:

Just look at the final scores, please don’t embarrass me by checking the calculations

Okay, we are getting closer to reality. Let’s take one last step.

Step 3. Incorporate Features network in the same way:

The formula enhanced with both network effects

The Feature is rewarded for enhancing other Features and penalized for negative side effects on the network:

Examples of Features doing good and bad to other Features

Let’s compare our good old pals one last time:

Final scores with both network effects incorporated in the formula

Feature B drops the mic 🎤

We included only 1st-level connections here — the effect of the whole network will be even greater.

As you can see, using networks for prioritization is not just a wild fantasy — it’s both effective and practical.

Are there unexpected bonuses?

Glad you asked.

Once you include networks into prioritization, dependencies are resolved automatically. The foundational Features get a higher score and are implemented first.

If you want to focus on a specific niche or persona, just put a 2x multiplier before the relevant Use Cases’ reach. No need to override the prioritization formula to stay in sync with OKRs.

Do product management tools support this?

Not yet.

Work management tools cannot interactively visualize networks of real data. Hopefully, we’ll see graph views appear in productivity software next to boards, tables, and calendars. We are making baby steps here at Fibery.

Visualization aside, most tools fail to capture attributes of a relation. When connecting a Feature to a Use Case, we need to define impact and confidence. When building networks of Features and Use cases, it’s important to capture the strength of connections. Auxiliary tables in Coda or auxiliary Types in Fibery is the closest you can get so far. However, without proper visualizations, the experience is just bad.

Once any tool solves these two problems, I will be happy to build and share a prototype. Stay tuned!

Thanks to the Fibery team, Tanya Avlochinskaya, and Ilya Tregubov for thoughtful comments.