Its been more than 3 years since I delved into Products role. And it has been one heck of a learning curve. Product Management is kind of a tricky role-you are called the ‘CEO of your Product’ but then, you have to get things done without authority and purely through collaboration.
A PM is often stuck between two extremities : demanding business or clients on one side and an Engineering team that often has its own style of functioning. Reconciling the expectations and in the process adding value to your role and the organization is what makes it a challenging role.
As a PM, I always found the 5Ps : People, Process, Problem, Project, Priority to be the most important driving factors in determining the end deliverable and what are we are credited for : The Product.
Let’s explore each of the above facets.
People : Arguably, the most important facet. Who are your stakeholders and what’s their attributes? What’s their expectations from you? Often, a PM has to wear the hat of a Business user to truly understand business expectations. People define culture and more importantly, how much of this would they want to be solved structurally and how much would it be stop-gap process.
One of my ex-colleagues told me — ‘I am unable to visualize what the people in my organization want me to do!!’ You need to define your roles to their stakeholders, resulting in lucid expectations.
A lot of PMs including myself started working less as a PM and more as a coordinator in just sorting out expectations of various stakeholders. It was a lesson well learnt for me, but not something that ever ceases to be as part of being a PM.
Bottomline : Every PM has to be a People Manager and you better know your people very well to manage expectations!
Problem : A PM is on a mission to solve problems, some of which are the outcome of the problems your organization wants to solve and some what you identify. What’s the problem your organization is solving is a good place to start with to understand the scope of your work. If your organization isn’t clear about the problem statement and how they want to solve, it’s going to be one bumpy ride as a PM.
Problems are always contextual and dependent on the ecosystem : Sector, Customers, Users, Partners and Vendors. There is no standard problem statement for PMs even within the same organization.
If you are a customer-facing PM, your problems will be driven more by marketing and customer experience. How do I minimize customer friction or how to I enhance the funnel conversion at various stages? PMs who work under the hood are more concerned with Processes, costing and efficiency metrics.
Bottomline : Every PM should be a Problem Solver, but know your Problems first and know the ones you can solve!
Process : Inherently, every organization has its own processes and maps that define output of each process to ensure smooth functioning. Processes vary across sectors and type of firms : Startups are as chaotic as they get while Corporate are overtly process-oriented. No matter what is your KRA, processes (or lack of) impact your performance. Clear process maps help PMs visualize the impact of a new feature development or identify gaps. Lack of processes can result in PMs struggling to identify the right things to build.
‘People just want quick-fixes and stop-gap solutions; it’s never planned’, wailed a PM friend of mine. And it resonates often with most PMs, especially the ones who work with startups.
Most of the PMs are tasked with not only developing a Product but (unofficially)managing the Process aspects as well. This would resonate a lot with PMs who work with internal users. Processes drive Products and its adoption and vice versa. Users blame a PM when a Product doesn’t fit within the existing Process and PM in turn blames for poor adoption, resulting in a vicious circle.
Bottomline : Every PM needs to be a Process Manager, including setting up Processes if need be. And you better know your processes!
Project : Every PM has to work on small or large projects that are out to create an impact. Typically, Project Management is a separate function within large organizations. Nevertheless, knowing a bit of Project Management never hurts. After all, every Product requirement written is eventually translated into a Project. A lot of PMs here are uncomfortable about getting hands-on due to possible conflict with Engineering teams.
I am doing more Project than Product Management, I find myself musing many a time. And it is closer to the truth than I want to acknowledge as I often extend my scope beyond Products to Engineering.
Unlike Product firms, where Engineering will work on a defined SoW, a PM with a startup or in-house function has to deal with a lot of uncertainty and changing requirements. And that is where a bit of Project skills help. No matter the Agile methodology or the traditional SDLC methods, PMs have to extensively coordinate cross-functionally.
Bottomline : Every PM needs to manage Projects, especially if you are driving complex Projects else you will be lost!
Priority : No organization has infinite resources. And the P in PM aptly applies to Priority. Every PM has to (de)prioritize infinite number of times and place it rightly in the roadmap. But prioritization is hardly that simple, not always driven by impact. Often, business users have requirements that can be whimsical bordering on unrealistic. And in most such scenarios, PMs know its not a feature for the next 3 Sprints. But it often gets pulled into current one.
‘Why do we even prioritize when it will anyways be turned upside down by business functions?’, a colleague once had asked me. And my response was ‘What’s the point of being a PM then?’
Prioritization often goes for a toss in Product organizations where Sales functions dictate prioritization. And features are often built for that 1 elusive order from a Leading MNC. Startups, on the other hand are much more priority-driven, trying to justify each feature. But, Prioritization is no easy task, requiring a lot of balancing act among the People you work with.
Bottomline : Every PM needs to prioritize to the utmost capability, else impact and the essence of the Product will be long lost!
The above 5Ps is what typically will define the “Product” that in turn will realize and frame the answer to the 5Ws. While there are multiple Ps that will lead you to a W, each of them have a dominant factor.
Project : When is that you will shipping as per the Roadmap?
People : Who is it that will be using the Product and benefit the most?
Priority : What will be the value addition or impact of the Product?
Problem : Why is the Product valued for and should be improved upon?
Process : Where do you intend to deploy and expose the Product?
The Product definition established and deployed will be a culmination of the 5Ps and 5Ws, making a PM’s task structured in an ocean of chaos and business expectations. Of course, every PM has unique problems that requires modifications and contextual changes. There is no one-solution-fits-all-scenario panacea.
It is a well known fact that it isn’t easy to be a PM as it is stated above. But investing time and effort in each of the above facets will bring in massive dividends, well worth the satisfaction that comes with being a PM.
This article was originally published here
