Build Products, Not Fluff: How To Prioritize Your Backlog

The word “prioritize” has kept product managers awake at night since the time pigeons carried messages and horses pulled carts.

In the early days of starting your company, you’re most likely trying to solve an itch, a problem you have. As your company matures, you develop a deeper knowledge of your industry, your user’s processes, and their pain points. Satisfying their needs without losing sight of the direction can be a challenge, and failing to meet their requirements can result in losing happy customers.

“In a sense, there’s just one mistake that kills startups: not making something users want.” ~ Paul Graham

But that doesn’t mean you have to build and solve all their pain points. In fact, you probably can’t build all of it, unless you’ve got an army of developers and designers on your payroll.

As a product manager, when you’re bombarded with feature requests and tasked with prioritizing an overflowing backlog that even your project management tool can’t handle, it’s easy to lose sight of the big picture and prioritize the wrong feature.

And when you get your feature priorities wrong, a huge chunk of your resources get eaten up, while your customers leave you for a competing product.

So how do you prioritize the right features?

A Guide To Prioritizing Your Product Backlog

1. Mind The Vision:

There are two kinds of products in this world. Products that take a stance, and products that try to please everyone.

At a time when people constantly seek instant gratification, it’s easy to give in to the short-term goals and try to satisfy the requests of few customers in the hopes of retaining them. But that will only lead to chaos.

When you try to build a product that tries to please everyone, you end up pleasing nobody, including your own team. It’s hard to understand what the product does, how to use it, or even find where certain buttons are. Your marketing team will have a hard time coming up with a story, your analytics team will end up not tracking the right metrics, and your design team will need a vacation to even come up with an idea to fit your next “awesome” feature into the product.

Worst of all, the customer — the very reason why you built all these low hanging features — will get frustrated and stop using your product altogether.

Image Source — The Daily WTF

Apple has been known to not let its users download files on their phones since the launch of their first iPhone in 2007. Basecamp has been labelled as an ideologist since they took a hard stance against GANTT in 2005. And Android phone makers have been hell bent on not removing the additional layer of their software on every Android release.

Growing companies must learn to deal with feature requests that doesn’t fit the product vision. If you want to build a product that stands out, you’ll have to make tough decisions, and say no to feature requests, even if it means accepting a fair share of criticism.

Takeaway: Stay true to your product’s vision, even if it means saying no to your highest paying customer.

2. Where Are Your Users In Their Product Journey:

In a perfect, simple world, a majority of your active users will scream at you for not building a certain set of features. In reality, feature prioritization isn’t that straight forward. When you look at your feature backlog, it probably varies from a simple “add image filters” to a more complex “an engagement report of all picture uploads”.

What do you do when the varying feature requests leave you wondering why users with similar profiles have needs that have nothing in common?

Take a step back and look at where your users are on their product journey.

A user goes through different stages in their lifecycle before becoming an engaged user of your product. And every feature you build should help your users cross over to the next stage effortlessly, so they can quickly achieve their goals with your product.

“A lot of times what you’re creating when you’re creating software is less of a tool and more of an environment for accomplishment.” ~ Samuel Hulick

Once a user signs up for your product, they broadly fall under one of the following buckets:

1. Signed up
2. Activated
3. Retained
4. Delighted

Before you even begin researching about a feature, fire up your analytics tool and consider evaluating where the majority of your users are in their lifecycle. The pain point of a user who just signed up and performed few actions on your product will be poles apart compared to a user who has been actively using your product for six months.

For example, if you’re planning to build a reporting feature to help your users see the big picture of what they’ve achieved, consider if your users have performed enough basic activities to see value in the report that your product generates.

Takeaway: Build features to move the majority of your users to the next phase of their lifecycle.

3. Impact Of A Feature

Not all feature requests carry the same impact. There are features that will make your users a caped superhero. And there are features that a high paying customer will want, but in reality, they’re just another set of nice to have features.

In order to build features that move the needle in the right direction, Intercom plots their feature requests on a graph that compares the frequency of usage versus the number of people who will end up using the features.

The idea is to focus on implementing the ones on the top-right corner of the graph — the ones that will be used by all of your users, every time. The closer you move towards the top-left corner, or the bottom-left corner of the graph, the more danger you are in building a feature that only some of your users will use, or even worse, will use only on rare occasions.

Related Read: Learn how to focus on your user’s pain points with user stories._Want to get your team to focus on your user’s pain points? Learn how to write user stories. Best practices, templates, and examples included._blog.zepel.io

“Focus your efforts on the top right. Doubling down on those features there adds far more value than bolting on more toothpicks… If you’re building features that only a small sliver of your customer base heavily depend on, your product is doing more than it should.” ~ Des Traynor

Takeaway: Features should be prioritized based on their significance and impact. Not by how much a customer is paying.

4. Effort And Complexity:

The final step to ensure you prioritize the right feature and put a smile on your customer’s face is further filtering your backlog based on the effort required to see the feature come to life.

After all, every time your team collaborates to work on a new feature, your design team will have to spend time doing research and customer interviews, and your engineering team will have to think through technical complexities and pick up knowledge of new technologies. This is crucial as it ties down to your most scarce resource — time.

Once you’ve figured the effort required to build the features in your backlog, you can now map all your features on a value by effort 2x2 matrix.

Image Source — App Cues

When you slice and dice the graph, you’ll end up having your features mapped into four categories:

1. 
   

   Top Left — High Value; Low Effort:This category of features should scream “WHY ON EARTH ARE WE NOT WORKING ON THIS RIGHT NOW?”. They’re, after all, features that provide high value to your users and can be built with minimum effort.

2. 
   

   Top Right — High Value; High Effort:The features you’ve categorized under this quadrant are the ones you wish you could ignore because of the high effort that is involved but can’t. Since these are features that will add value to your users, consider breaking them into tiny, executable modules that you can re-map to this 2x2 matrix and re-prioritize.

3. 
   

   Bottom Left — Low Value; Low Effort:These are features that add little value to your users but can be pushed to production frequently without breaking a sweat. They help give your users the impression that you’re constantly pushing out features to improve their experience and gets your team pumped and motivated even when you’re nearing a weekend. After all, there is no better morale booster for a product team than pushing features to production.

4. 
   

   Bottom Right — Low Value; High Effort:These are features that you shouldn’t be working on right now, unless of course, you’ve exhausted the entire list of feature requests and bugs in your backlog. You’re more likely to bring your users more value by focusing on the other three quadrants.

Takeaway: Build features that deliver maximum value at minimum cost/effort.

Over To You

Product managers take the big-picture, turn them into actionable next steps, and by getting the priorities right, they can turn a product that is struggling, to a product their customers can’t live without. What might seem straightforward from the outside, requires thinking through various angles, including:

1. Keeping the long term vision in mind.
2. Considering where a user is in their lifecycle.
3. Thinking through how many users will use the feature frequently.
4. Analyzing the effort that needs to go into building a feature.

This was originally published on Zepel Blog on July 12th, 2018.

Zepel.io is the project management tool for product teams to manage backlog, collaborate, and ship features on time, every time. Drop us a line in the comments or shoot an email to [email protected] with your thoughts and suggestions.