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 , and your design team will need a vacation to even come up with an idea to fit your next “awesome” feature into the product. tracking the right metrics 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 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. labelled as an ideologist 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: Signed up Activated Retained 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, that compares the frequency of usage versus the number of people who will end up using the features. Intercom plots their feature requests on a graph 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. “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 , 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. team collaborates to work on a new feature 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: 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. Top Left — High Value; Low 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. Top Right — High Value; High 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. Bottom Left — Low Value; Low 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. Bottom Right — Low Value; High Effort: 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: Keeping the long term vision in mind.Considering where a user is in their lifecycle.Thinking through how many users will use the feature frequently.Analyzing the effort that needs to go into building a feature. Once you've gone through this process and figured out, it's a matter of communicating the priorities to your team. If you are using , you can simply drag and drop features from within the Progress tab to build a roadmap and let your team know the priorities. And as your development, design, and QA team makes progress, you can see how your entire feature is progressing in real-time. Zepel . 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 vikash@zepel.io with your thoughts and suggestions.

The Graph

Apple

Basecamp

How to Run Scrum Meetings

Building JIRA alternative for software product teams

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Build Products, Not Fluff: How To Prioritize Your Backlog

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

5 Acceptance Criteria Mistakes Teams Should Avoid

Agile35 cards which will improve your backlog refinement process and engage every team member

5 Ways to Prioritise Your Product Backlog

A Junior Developer Explains Task Estimation

Create an Effective Product Roadmap by Using Uncertainty Bubbles

How to Export and Analyze Jira Issues in Google Sheets vs. Coda

5 Acceptance Criteria Mistakes Teams Should Avoid

Agile35 cards which will improve your backlog refinement process and engage every team member

5 Ways to Prioritise Your Product Backlog

A Junior Developer Explains Task Estimation

Create an Effective Product Roadmap by Using Uncertainty Bubbles

How to Export and Analyze Jira Issues in Google Sheets vs. Coda

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps