The first P of being a PM

The idea for this series of posts stemmed from a completely different discussion I had with a colleague on the differences between product management and program management. I won’t delve into that but what got my mind racing was me trying to introspect on a product manager’s role. After running through a whole host of responsibilities and attributes, I finally narrowed it down on Prioritization. I believe this is the first and foremost task a product manager has to be responsible for. I did cover this briefly in my introductory post of my first month as a Product Manager.

Why is prioritization important?
As a product manager, you are measured against metrics related to your user’s goals. These metrics could range from Gross Margin Value (GMV) to Average Order Value (AOV) to Engagement (DAUs, Cohorts) and so on. There is absolutely no room for anything else if your features/releases aren’t impacting the metrics the most. It’s the holy grail. Intercom published a really informative read on prioritization. They subscribe to a model called the RICE framework — Reach, Impact, Confidence and Effort. Each of these parameters are scored and the overall RICE score determines the priority of a feature. Honestly, it cannot get simpler than this. But I personally also like to leave some room for judgement and intuition as well. What follows from prioritization is the product roadmap.

Roadmap vs Ad hoc Requests
A product roadmap is created after you are done prioritizing tasks and features/releases. Depending on the stage of your company, you may have a roadmap for a quarter, a year or possibly even more than that. I’ve only worked for small to medium sized startups so my product roadmaps haven’t gone beyond 6 months. I believe that once you’ve gotten the items in your roadmap prioritized, half your job is done. But wait…

…and just when you’re mid-way feeling good about your roadmap going on as planned, someone from the marketing team makes a feature-request. Someone from Finance asks for alterations in certain dashboards. Long story short, it’s a balancing act between handling ad hoc requests and ensuring you’re still on course with the roadmap. On receiving an ad hoc request, I ask myself (and the stakeholder) these high-level questions:

1. What is the impact on my user and the aforementioned metrics?
2. Can I measure this impact? Short term gain or long term gain?
3. How much of a pain point is it to the stakeholder/user?
4. Can I quantify or measure the pain point or criticality of #3?
5. Can it be resolved or shipped with a complementary feature which is already in the product roadmap?
6. What is the effort (quantified by time) involved?

There are more questions but I’ll stick to the above six. Based on these, I take a hard call on whether to pursue ad hoc requests at that time or post-pone working on it or shoot it down all together.

What certainly helps is organizing your engineering team into developers who can work on long term features and shorter term features separately. I have seen this through experience as I’ve faced resource crunch working with small teams of about 5–6 developers. I may have groups of 2 or 3 developers working on the big ticket items which typically have a development effort of more than 1-2 weeks. On the side, I will reserve one developer who will work on relatively smaller features (development effort of ~3 days or less). If you can draw up a mental picture of a Gantt chart, you will realize that I am constantly shipping small features and/or bug fixes on a regular basis without having the major chunk of my roadmap affected. In light of this segregation of resource, I would then assign the ad hoc requests (post scrutinizing on whether to take them up, of course) to the developer working on short term features. In the worst case scenario, I would be able to get to those ad-hoc requests in a few days. There you have it, my approach on handling a roadmap with ad hoc requests. (Vincent’s secret sauce much?)

Dealing with stake-holders
By nature of the PM role, you will be dealing with multiple stakeholders and inevitably, everyone wants their requests as soon as possible. To be specific, I’m talking about internal stakeholders of the company such as marketing, finance, sales, operations and others. Prioritization becomes important more than any where else. As I had described earlier, there will be times you have to shoot down proposals or feature requests by nature of failing the ad hoc test. I wish there was a surefire way of coming out with a win-win outcome. It’s subjective and depends on the context of the discussion. I have learnt though, that being empathetic with your fellow peers is a step in the right direction. Back up your reasons with data, guesstimates or strong hypothesis to ensure that your stance defensible. Without these, it’s all about people management skills. On the flip side, do take into account that these stakeholders are equally important to you and the success of your product roadmap. One such example would be at the time of product launch, you’d have to coordinate with the sales and marketing teams to conduct demos with customers/sales representatives. I guess you get my drift, right? Product managers need to develop people skills to handle such situations.

If there was a punk rock song about product management, it would be ‘Prioritization Über Alles’ which translates to ‘prioritization above everything else’. It determines the success or failure of your product.

Stay tune for the next post — The second P of being a PM.

Originally featured at: https://www.vcent.in/writing/2017/2/8/the-first-p-of-being-a-pm