by Juan Ramirez
One of the most challenging questions that product managers have to face day to day is whether or not they should include certain features in the product pipeline, and even more, whether those features should be included at all.
In other words, they often face the question of whether or not they should expend time and development resources in certain features, without knowing the impact of that feature in the product value and/or the revenue.
The reason this question poses a challenge for product managers is because they have to ship and deliver value through their product strategy, but there are no methods or simple formulas which indicate which is the best way to do it.
When asked, most product managers would admit that instinct plays a big role in the way things are prioritized for the product and how they make their decisions.
This is true in most of cases. Good product managers have a good product instinct. They know what’s best for the product and the final user before there’s even actual data to understand those insights.
Good product managers develop this ability mainly due to the fact that they get used to seeing the big picture of what they are working on, without missing the small details of the execution. They are, in other words, great philosophers and amazing executioners.
In my years of wearing different product hats, I have realized that the so called “product instinct” is just the ability to make accurate product decisions without missing out on the big picture.
Here are 5 rules that you, as a product manager or product stakeholder can follow to help you make better product decisions that align with the big picture of the product and the business.
1) You’re not the CFO but costs come first. Development time is money
One of the biggest mistakes of any PM is to not evaluate the cost of a feature. PMs deal with pipelines, product backlogs, and scrums. They are used to see resources as development time and not necessarily as money.
As a PM, always make sure to evaluate your resources in money value. This will give you a different view on how to prioritize and make product decisions, especially because you will begin to see how your burn rate relates to the immediate future of the company’s finances.
2) Understand the value of a feature
When evaluating feature development, always assess the value of that feature in the final user experience. Would the user pay more money for that feature? Would the user spend more time with your product if that feature is implemented?
How relevant will this feature be in the near future? In general, ask yourself why this is something that should be implemented and make sure to find enough arguments that support a decision.
Being a very UX focused product manager myself, I always like to do early low fidelity prototypes of any feature that is being evaluated or those which are in the pipeline. Create use cases, do internal customer development sessions, and let people play and give you opinions about your sketches and wireframes. Always get feedback.
3) Get feedback but don’t live by it
Feedback is important for any product strategy. However, always take into account that most of the feedback is useless. In order to get useful feedback, remember that people are very bad at telling you what they want but are very good at telling what they don’t want. Learn to ask the right questions and learn how to integrate the right feedback into your product strategy.
4) Prioritization over optimization
Your goal as a PM is to prioritize rather than optimize. This is one of the things that most PMs get wrong. They focus too much on trying to create the optimal distribution of resources when their job is instead to prioritize the resources.
This means that you should be putting all the resources in what is important for the product and not for what is optimal for the operation. In other words, your job philosophy is: ideate, ship, test, and repeat. Commit to that philosophy.
5) Distrust the pessimist, but more importantly, distrust the optimist
At the beginning of my career, I worked on a project with an external development team. When I pitched the idea and showed all the wireframes and requirements of the product to this outsourced team they looked very confident and comfortable with the idea of developing this app.
One week later they came with their own wireframes and to my surprise, they had a lot of more features than the ones we initially pitched. Being a fresh product guy in that moment, I saw this as great news. Those guys were so good that they were going to deliver more for the same money and still within the deadline.
I have never been so wrong in my life. Their optimism was just naivety and over confidence. If there’s anything in this post to live by, this is it: always enforce your requirements and address delays before they occur. Don’t let anyone negotiate your deadlines in exchange for more features because this is a free ticket to “never ship anything”.
You know your product and your users better than anyone and therefore you already went through the process of evaluating and discarding features. Therefore, don’t let someone who can’t see the big picture make those decisions for you.
As you may be thinking, there are many other potential rules and thoughts on how to make good product decisions, but in my experience I have found that the ones that I just described are accurate representations of a good product decision system. Moreover, I have found that “excellent” product managers have a very solid product decision system that helps them to align the product execution with the business vision.
Please feel free to leave your comments and give your own ideas on a good product decision system.
Tweet this: 5 Rules to Make Better Product Prioritization Decisions http://wp.me/pXBON-45D #prodmgmt
About the Author
Juan J. Ramirez is a Product Manager at Contactive. He is also a Master’s student at Carnegie Mellon University where he is pursuing a Master of Entertainment Technology. Before that he was CPO at Usuallee, a startup based on Bogota, Colombia. You can reach him via firstname.lastname@example.org