A critical part of a product manager’s job is prioritizing what to build. You must decide what to build now in order to make your product successful in the long term. More importantly, you decide what not to build.
This will always draw plenty of opinions. Your colleagues have an example of clients that loved a particular feature idea. Your clients ask for certain features to accomplish their current goals. The customer success teams need you to simplify the product’s integration and usability. Engineering needs time for innovation, cool features, and infrastructure improvements. The sales team request the features that your competition is touting. The marketing team needs you to deliver the future.
As a product manager, it is your job to assimilate many inputs to help create a full picture of the pressures that your product faces. You must use this knowledge to make a recommendation of what must be built over the next 3, 6, or 12 months. How do you do this?
Start with company priorities
If your company’s executive team is worth their pay, they’ve established a clear set of goals for everyone to rally after. You must start your prioritization with these goals in mind. How does your product fit into these company initiatives? What is the key metrics that your company is seeking to improve? Are there any specific markets that must be pursued? Are there certain users that you must prioritize? Make sure that these are the key factors in your prioritization.
If this is not immediately clear to you, clarify it with your company’s management team. You will fail as a product manager if you optimize for your own vanity metrics rather than the company’s goals.
Build a framework to evaluate requests
Evaluating features or initiatives must be a mix of data and judgment. As a product manager, you are trying to factor in a large number of factors: impact on new customer acquisition, customer retention, cost to build, cost to support, differentiation from the competition, etc. For some of these factors, you will have clear information or forecasts. For others, though, you will need to make a judgment call.
You can simplify your prioritization by defining a framework to score each theme and feature. The goal of this framework is to help make it easier to surface the initiatives that will have the biggest impact in the areas that matter the most.
I use a simple spreadsheet. The first column lists all initiatives being considered. The next set of columns contain the various factors identified as important. Each initiative will have a score for each factor based on the overall impact to that factor. There should be a clear definition of what it would take for the initiative to get a 1, 5 or a 10. In the next column, add a blended score for the feature. If you care most about one factor than the rest, you can multiply that factor’s score by some number (2, 3, 5) for the overall blended score. Finally, a column for notes to add any special considerations that went into that initiative’s scoring.
This process is not meant to replace your human judgment or “visionary” work. Instead, it is a way to remove some of the complexity in coming up with an answer. It brings clarity by forcing you to score each factor independently for the initiative. You can then focus your discussions with others on whether the impact to a particular factor or KPI is overstated, understated, or whether the factor should be weighed more heavily than others. Those discussions are more focused than a generic conversation about all the ways in which feature A may be better than feature B. Yes, feature A may be awesome, but if it doesn’t help me improve customer engagement and that’s my core goal, it may lose to Feature B in my prioritization.
Communicate and show your work
This brings back memories from math class back in elementary school. My teacher would always ask me to “show my work.” It wasn’t enough, she said, to write down the right solution. Show the steps and the logic behind the answer. Similarly, it is important for product managers to show how they arrived at a given conclusion. This is critical since there is no one “right” answer that everyone can agree on. Your colleagues can see your work and argue on the logic of prioritization rather than the answer.
Showing your work could take the form of a beautiful spreadsheet (as I described before). Or it could be a presentation succinctly discussing the core factors at play. It could be a write-up. It could be anything. But have something that anyone in your company can take a look at and get a sense of (1) what you prioritized and (2) what else you considered that didn’t meet the cut, and (3) why. Otherwise, be ready to get stuck defending and revisiting your prioritization an insufferable number of times throughout the quarter.
Whatever you do, keep it transparent
Your approach to prioritizing features will invariably be a mix of researching information coupled with a final judgment call. Once a quarter, you sit down and write out 10 things that you must build next in order for your product to be successful. You will have plenty of discussions and considerations that lead you to a certain prioritization. Don’t make the mistake of keeping this information in your head. Take the time to write this information out. Keep the prioritization criteria somewhere that’s transparent to everyone in the organization. Whenever someone has a question as to why something is or isn’t being built, point them to the document and be there to answer questions.
Assuming that your colleagues are trying to accomplish the same goal you have, to make your company successful, this should smooth out conversations. Give your colleagues the proper context and, just maybe, they might agree with you and support you. If they don’t, you can have a healthy and focused debate on what matters for prioritization without getting invested in specific initiative or feature arguments.
Liked this article? Follow the blog to get notifications of new ones as we publish them.
Interested in continuing the discussion? Write a comment below!