Use Networks to Prioritize Product Features

Features prioritization is the hardest problem in product management. There are many techniques that might help and I’ve tried them all (with no great success). I think something important is missing. In a nutshell, these techniques are just linear models that work as good (or as bad) as intuition of an experienced product manager.

I think one important missing thing is… network.

Features Network

Any system can be represented as a network. In our case we work with a software product. Here I use Feature as a node, and Features have connections. Let’s take Google Suite. You have Document feature and Search feature. Search is connected with Document, since you find something in docs.

Abstract features network looks like this:

The main idea is simple:

Feature importance is defined by connectivity.

More connections—the importance is higher. Less connections—the feature is less important.

Overall, less important features will be quite lonely and isolated, while important features will form a system’s core. I call well-connected features core features.

NOTE: Here you may immediately feel that this is somewhat similar to PageRank algorithm by Google. Indeed, every node is a page and connections define page importance. Promising similarity so far.

Let’s explore this model.

Lonely features may be dead ends, but may explore new frontiers.

They may be there for a reason. For example, you may explore new opportunities and new areas of product applicability. In Google Suite it might be Video calls. It still has some connections to features like Auth, User Profile, but overall this is a peripheral feature.

Adding 10 loosely connected features is a bad strategy.

This situation is not uncommon, by the way. You have a backlog, use some linear model like RICE and ta-dam, decide to implement top 10 features in a new release. It may happen they have few connections.

It’s spray and pray tactic, in fact, when you try to explore dozen different areas without depth. In almost all cases this superficial exploration will be a disaster for the product. That is why linear models may not work without network.

Adding features cluster is a true exploration of a new area.

It means you try to explore new area with a set of coherent connected functionality and increase your chances. Basically, when you try a new area, it might be loosely connected with product core, but most likely it forms a new solid cluster. When you do this, you should always think about a completely new product or a new module that can be enabled/disabled. Atlassian follows this strategy with great success.

Note that this approach is good when the product core is solid enough and you can’t find new growth points inside the core.

Another situation when this might work is a crisis. When the core functionality can’t find market fit, you have to try new areas as quickly as possible and this might be a good way to do that.

Core connected features.

This is the real meat. You almost always improve core functionality and core focus of the product by adding super-connected features. Imagine in Google Suite you have docs, spreadsheets and presentations, but no search. New Search feature will affect all these areas and will improve core user experience a lot.

An Example

I work on Fibery, so let’s check Fibery as an example

Any LEGO block here will be a core feature. For example, new Hierarchical List View can be used in dozen use cases: product backlog management, work hierarchy, candidate tracking, etc. New field type, like URL field, is a core feature as well, since there are many applications for URL field. These features are well connected.

However, Intercom integration is relatively loosely connected feature, that affects only product management and customer success cases.

Let’s say we have 10 requests for URL field and 8 requests for Intercom integration. Should we implement Intercom integration or URL field? From network perspective the answer is definite. In fact we can’t be sure without use cases.

Adding more dimensions: Use cases

Feature is just a solution. Problems are missing here. To have a better product picture we need two networks: Problems (Use Cases) and Solutions (Features).

Use Cases can be grouped by Work Processes. For example, “as a product manager I want to aggregate feedback in a single place” is a use case, that relates to “Customer Success” process.

Features can be grouped into Epics. For example, “Full Text Search” is a Feature that belongs to “Better Navigation” Epic.

Follow me carefully from here, since it’s easy to get lost in features.

Intercom integration was a hint for us. Why people requesting it? They wanted to link Intercom chats to real work in Fibery. Is it enough to solve this problem? Well, maybe, but if we blindly do it, we’ll miss a great opportunity to make product managers life easier.

What people really wanted is to have Intercom chats in Fibery, review them, highlight important insights and connect these insights to real work (features, bugs, stories). Let’s call it “Feedback Review” use case.

We have to add three features to make this case smooth:

1. Intercom sync to feed chats to Fibery
2. Feed View to scroll through all recent chats and read all text right away
3. Highlights to mark important insights in text and link highlights to real work.

As a result, we have two strategic choices:

1. Improve general platform (add more LEGO blocks) like ULR field and better Formula fields.
2. Add a new cluster “Feedback Review” and implement all important features to make this use case cool.

From pure network perspective core features always better, but you have to take strategic opportunities into consideration.

In the best case scenario you have both: well connected features and completed strategic use cases. For example, Feed View is a core feature that will be useful in many other cases, like backlog review. Highlights in text can be helpful for all kind of bi-directional references, like connect meeting notes with work. So it seems only Intercom sync is peripheral feature, but we have to implement it to close the case.

Feature Importance function

Finally, we can define a function for Feature Importance:

Feature Importance = f(number of connections between features, number of connections between use cases).

The function should be more complex for sure. It should take into consideration at least two more parameters:

• Current strategy and use cases we focus on (more weights on them)
• Effort to implement

Most likely the real function will be quite complex and closer to PageRank.

Tools support

The fundamental problem here is this:

How to build and visualize this network?

Are the any good tools for that? Exactly zero. All current solutions for product managers like Aha! or Productboard don’t have anything similar. All specialized tools to create networks are not connected to product management apps and can’t be used to calculate Feature Importance.

Here are some properties of the tool that can solve this problem:

1. It should be inside a product management software that product managers work with. Integration will not work, since you need to see the connections all the time.
2. It should be possible to quickly connect use cases and features via relations.
3. It should visualize the whole graph or sub-graphs of a product.
4. It should allow to customize exact formula or algorithm for Feature Importance calculation, since products are different and it is hard to define all parameters upfront.

I’ve tried to build part of our own Features Network in Fibery to explore the idea. Here is the result:

• Green — core features
• Light green—missed core features.
• Blue — features in near future plans.
• Gray — peripheral features.

The problem is that you don’t see relation to real use cases. For example, all blue features on the right side belongs to “Feedback Review” use case, but this information is missing here and you don’t see why these features are planned. Still you see that all blue features on the right are connected and form a cluster, this is a good sign of coherent strategic choice.

I’m curious to explore this idea further. So far I just throw this rough idea with a hope that it will resonate with some people.

UPDATE: Anton Iokov enhanced this idea further, and now you can have a real framework to prioritize features! Enhancing prioritization with networks