Product managers often find themselves with a rather unenviable task. While slicing and dicing their way through competing priorities and requests from different stakeholders, they somehow have to make sense of it all and prioritize the features for an app build.
It’s often a delicate balance. If you’re in a larger company with multiple stakeholders, you’re probably going to be disappointing someone for the time being in the name of building features in an order which makes sense.
If you’re smaller and looking to grow, then failing to make the right calls in terms of feature priorities can kill your business before it has really even got off the ground. You’re constrained by time and budget, you can’t afford for any resources to be wasted.
What should you do? How do successful product managers prioritize app features?
Have Clear Goals
This seems so simple, yet is often lost in the noise that goes with any kind of product development. You should always begin with the overall strategy behind the new app and the specific end-goals before getting stuck into any feature requests.
You can create product roadmaps and roadmaps for your roadmaps, but they’re all leading nowhere if you don’t have overall strategy straight.
As a product manager, part of your job tends to end up being managing the various personalities you will come across in your work environment. If you fall back on listening mostly to the biggest customer or the loudest stakeholder, the lines can get blurry when it comes to following a clear path to your goals.
At the beginning of any project like this, call everyone together, including key stakeholders, and take the time to set everyone straight on overall strategy. You don’t want your development team being pushed and pulled across different directions and you need to make it clear to everyone that they will be prioritizing based on the goals which will help achieve that overall strategy.
If your strategy has been validated through customer development and feedback? Even better. Your overall strategy should always have the end-users at its heart.
Generate Feature Ideas
You’re often going to end up bombarded with ideas, including those based on “gut feeling”, but it’s important to take stock and understand the real “why” behind those ideas. How will they impact upon the customer? Where did they come from?
Data is your good friend here. If the idea came from repeated customer feedback from usability testing, interviews or tested hypothesis, these are likely to be much better to go with than gut feeling. You don’t want to be simply chasing competitors either; if you’re adding the feature to keep up with them or to chase industry trends, you might simply be jumping on a bandwagon to nowhere. Analyze first!
Yotpo uses a Feature Request Portal which allows anyone in their community (customers or staff) to submit feature ideas. Other users can then vote them up which gives Yotpo some excellent data on what features are going to be popular. Besides that, the portal allows all users to see which features Yotpo are thinking about and to provide suggestions or comments. It’s a great way to not simply be stabbing in the dark when it comes to building features.
Create a Roadmap
You’ve probably heard oft-repeated the advice to “build a roadmap”, however the term is perhaps so over-used that people are often missing the point about creating a strategy that is actually of value.
A roadmap is literally the laying out of all of the steps required to get your product to the point of that strategic vision you first outlined. It is not simply putting your list of features in order, but, as Bruce McCarthy points out, your roadmap should “make it obvious how things will improve for your customers, organization or shareholders. Like any good sales pitch, it should focus on delivering value.”
At this point, it’s also worth being mindful of other mistakes which McCarthy lists in his article on product roadmapping. For example, sometimes there is a tendency for organizations to take too much of an “inside-out” view, where goals are not in alignment with the reality of the external market and priorities are not necessarily driven by the needs of the people.
It’s easy to get excited over your “pet project” or some feature which you think is really cool, but your position in the organization means that you’re not necessarily conversant with that view from the outside.
McCarthy also suggests avoiding creating a roadmap which is simply a “popularity contest.” Sometimes organizations will simply list feature requests from customers in order of frequency or popularity of the request. Those features might be fine if they really address unsolved problems, but otherwise you could end up with another “me too” product similar to competitors. His advice? Look for those unique, unsolved problems.
Rank Based on Business Value
It follows that you’re going to have to rank features somehow to integrate into your roadmap. This is not the time to run with gut feeling; make sure you have come up with a way to qualify your features that is based on the priorities of your overall strategy.
For example, Daniel Elizalde suggests using a scorecard to prioritize your features. This way you have something more than just “taking a stab at it” and can show logical analysis to any executives or others who may need to give overall approval. You could use a project management tool to create a scorecard through their inbuilt software, or you could simply create a spreadsheet as Elizalde suggests.
To build your scorecard, you’re going to need some proposed parameters and weights, and perhaps to get input or agreement from stakeholders on what those finally look like. For each feature relevant to your overall goals, you then assign a weight from 0 to 100 in each category, with 100 meaning extremely high impact in that category. See the example screenshot from Tech Product Management below:
How did he arrive at final scores? Here’s the calculation for that Monthly Report feature: Monthly report = 90*20% + 90*10% + 50*30% + 20*40% = 50.
It’s also worth pointing out that you can assign negative weight in a category to give it lower priority. An example Elizalde suggests is “risk of implementation” so that features which are riskier to implement are pushed further down the priority list.
Some product managers prefer to use a scorecard method along with the simpler “Value vs Complexity Quadrant” for plotting out features. This simply places features on a chart of high vs. low business value and high vs. low complexity. Check out the example from Product Plan below:
Whichever method you prefer (and there are others such as the Kano model), the important point is that you come up with a somewhat scientific way to prioritize feature development. This helps boost your credibility as a Product Manager with stakeholders or executives and provides a simple way to explain why the feature request of one department was prioritized over another.
Prioritizing features is no easy task, particularly when product managers are often trying to balance the requests of parties with different agendas.
The key is to start with the overall strategy and goals for the product and to be able to present a strong business case relating to those for any feature.
Rather than the “loudest voice” or “gut feeling” approach, find a way to prioritize features which has a clear method of calculation behind it. You probably can’t please everyone, but you can at least present a good case for why or why not.
Koombea has a world-class team that can help you bring your app to life. Get in touch with us today.