The Best Way to Prioritize Customer Ideas on Your Roadmap
June 23, 2015

The Best Way to Prioritize Customer Ideas on Your Roadmap

The dreams of product managers perish in the gap between what customers say and what they actually do. Product ideas gathered from customers are crucial. However, they should not be accepted as absolute truths. In a similar vein, complaints from users often motivate product teams to react at the expense of fulfilling long-term goals. This is an enormous mistake.

Product managers must diagnose customer complaints to address the root of a problem — not just soothe a symptom on the surface. They must also scrutinize requests relative to their product vision.

Building what’s most valuable hinges on having a thoughtful product roadmap with specific, measurable goals that can be achieved within 12-18 months (“Grow users 4x in 2015,” “Acquire X market segment that engages with channel Y”, etc). Adding clear objectives to your product’s roadmap helps you evaluate customer requests — before you stack them on your pile of features to be implemented.

Well-designed roadmaps are a powerful tool when seemingly urgent requirements strike. In such scenarios, product managers can take a “goal first” approach by urging stakeholders and teammates to explain how a feature idea will achieve objectives. Simply put, roadmaps make it easier to have hard conversations that involve saying, “No” or “Maybe later.”

An Approach to Prioritization

When you have ideas competing for limited time and money, it’s important to act cautiously. At the same time, you can’t afford to get paralyzed by analysis. So, you need a quick way to separate obvious hits from near misses. Try creating a chart or a scorecard for prioritization so you can focus your efforts on concepts that matter most.

For one axis or metric, consider the positive impact of a feature related to the goals on your roadmap. With the second axis or metric, consider the level of ambiguity in either the definition of a feature or how it may be implemented. Then, as a team, plot or rank the items on your list in one of the following categories:

Do it These product improvements are critical and their benefits are quantifiable. These are glaring pains or exciting opportunities to be taken advantage of. Beyond their obvious benefit, these features are also well understood. Their value to the product line and business is clear.

Queue it This category is for items that have high business value. However, your product team is fuzzy on how the feature will be implemented. That ambiguity may be due to technical or business uncertainties. For such items, your team may need additional evaluation before they promote them to the “Do It” quadrant. These features are candidates for your next release.

Trash it Sometimes, a feature request is well understood, and your team agrees that its functionality offers little or no value. In this case, the request should find a home in the “Trash it” quadrant. The key is to keep track of such features and capture reasons for passing on them. That way, if it bubbles up again, you won’t rehash your analysis.

Triage it Let’s consider a feature that is shrouded in mystery. Set aside time to further analyze it. While some of these items progress to “Trash it”, this is not always the case. Occasionally, upon further analysis, you find that the item is of great value — and will be promoted to the “Do it” quadrant.

Effective Attributes of Prioritization

All product teams have their own ways to score feature requests. Regardless of which path you pick, ensure that your framework is:

Transparent The process of prioritization should be transparent. Not everyone in the organization gets to decide which features make the cut. However, it’s important that teams understand the method for selecting these ideas. This way, they will trust its outcome.

Unbiased The framework for choosing ideas should be shaped before the list of new product functionality is created. This beats the risk of introducing a bias towards features that favor what the product team wants.

Marketable The output of the exercise to rank new features should be easy to socialize within your organization. The benefit of cascading this information to all members of the product team goes beyond building trust. It ensures that teams are equipped to quickly recall the reasons for prioritization. As a result, teams keep their forward momentum when questions arise from new or existing members.

Traceable The decision-making process should link back to the overarching vision and priorities on your product roadmap. It should entail establishing a cause and effect relationship between proposed enhancements and their impact on the strategic objectives outlined in the roadmap.

To state the obvious, it is foolish to ignore customer feedback. Efforts must be made to gather data from them on aspects of the product that wowed and frustrated them.

Admittedly, it’s no easy feat to prioritize ideas – least of all those which come from people who use your product. But we – product managers with our teams – carry the responsibility of interpreting signals from the customers to shape a product that meets their true needs.

As product leaders, we are responsible for building products and a business that have a viable return on investment. So taking a data-driven approach to prioritization that establishes links to your product’s strategy is key. It eliminates the friction caused in teams when they perceive that their work is driven by personal agendas instead of long-term plays to win.

This is a guest post by Natasha Awasthi. If you are looking to be a great product manager or owner, create brilliant strategy, and build visual product roadmaps — start a free trial of Aha!

Natasha Awasthi is a New York-based product manager and writer. She artfully untangles messy problems by discovering unexpected patterns in behavior, processes, and technology. A self proclaimed Jedi-in-training, she writes about channeling the force and embracing her creativity. She has written for Fast Company, LA Review of Books, Women2.0, General Assembly, and others.

Follow Natasha @natashaawasthi

Follow Aha! @aha_io

Guest Author

Follow Aha!

Related articles

The Product Plan vs. the Release Plan
January 8, 2018
The Product Plan vs. the Release Plan

Confused about the differences between product plans and release plans? Learn how to use both product plans and release plans to deliver a winning product.

The 6 Principles of Strategic Product Roadmapping
April 14, 2020
The 6 Principles of Strategic Product Roadmapping

Strategy is not optional. I wrote this just a few weeks ago in a blog post about recent world events. The context was how to make clear decisions when the future is…

User Stories vs. Requirements: What Is the Difference?
January 23, 2018
User Stories vs. Requirements: What Is the Difference?

Are user stories and requirements the same, or do they serve different purposes? Find the answer (and others) in this guide.

Agile vs. Roadmaps
March 2, 2020
Agile vs. Roadmaps

Have you ever tried to follow a complicated recipe? Exotic ingredients, specialty cookware, and professional techniques — it takes more than instructions to cook a…