Why product management role is so misunderstood.
The Technical Aspect
Throughout my career as product manager I have talked with many product managers from different companies, seen a lot of product management recruitment ads, and followed many product management discussions and lectures.
I have found out that an alarmingly large portion of those product managers are focused only on the technical aspects of their job. Too many companies are looking for someone who can write PRD and MRD, and too many product managers think their role ends with writing outstanding requirements.
This phenomenon has been worsened by the introduction of the product owner role, which in my opinion is a mere tactical role focused on a very small part of product management. It is hard to define a good product when looking only inwards. You can read more about this in Product Manager vs. Product Owner by Marty Cagan.
I have even seen many product managers (including myself as a junior product manager many light-years ago) think that if they wrote good requirements, and engineering did not deliver them, they have done their job. In reality, the truth is that they failed and did not deliver a good product.
Don’t get me wrong., writing good and well understood requirements is a very important treat for a product manager. However, it’s only a task, not your role. If as a product manager you are doing your job properly, you will find that writing requirements is one of the smallest time-consuming parts of your job.
The Different Sides of Product Management
Product managers are responsible and/or involved in different activities requiring different skills. The list is usually endless, but the major ones are:
Product strategy
Competitive analysis
Customer development and discovery
Pricing
Understanding customer needs
Prioritizing development
Ideation - defining specifications
Execution
User experience
Documentation
Legal
Cost
Product evangelism
...
All of the above are tasks of product management that you may be doing or not doing depending on your strengths and on the company you work at. None of them define your role.
The Undefined Role of Product Management
Product managers come from different backgrounds: Technical, user experience, business, and more. In different organizations product managers are doing different things, usually depending on the other roles in the organization.
Even though good product managers can transform the company they work in and change a good product into an excellent product, product management is many times not considered a crucial role. A company can exist and ship a product without a product manager. In many companies that means that the thought on the product management role unfortunately comes last and the role is shaped by the vacuum created by the things not handled by other functions within the company.
Product management is the glue between engineering, marketing, business development, sales, customer support, customer success, finance, and other functions in the organization. And too many times when the company treats it as a glue, the role starts and ends in the quality of the requirements and the user stories.
What is Product Management About
Your most important role is to be the “focus” advocate and to solve the customer’s pain. You need to make sure that all your team members row in the same direction and that all the right questions are asked. You also need to say “no” a lot. You need to make sure that you bring the customer and user’s point of view while keeping the technical and legal aspects of the product and the strategic goals of your company in mind.
The most important thing for you to do in all times in to try and understand what is the major thing that is blocking your team from delivering the right product as fast as possible or what is the next thing to do that will move the needle for your product. At different times it may be different things. It can be lack of clear strategy, lack of goals or metrics, lack of process or a bad process, lack of customer inputs, communication problems, lack of the right resources, and more. It can also be a need to introduce a totally new direction for the product’s user experience or expanding the product into new use cases or verticals.
Whatever it is, that is where you need to put most of your energy. Because no matter how good your requirements are, if something doesn’t work properly and you are not making big steps, your requirements don’t matter. As the red queen from Lewis Caroll’s “Through the Looking Glass” said “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”
The Things you are not Accountable fo
Many years ago, Ben Horowitz wrote Good Product Manager/Bad Product Manager, in which he claimed that the product manager is the CEO of the product. While many claim that a product manager cannot be the CEO because he does not have the absolute control of the resources and authority, the essence and the mataphor is still right. Product managers should care and think as though they are the CEO of the product.
In many cases, you may rightfully claim that you are not in control of the faulty situation. It may be the responsibility of another department. In such cases, while you cannot change it yourself, it is your responsibility to advocate the needed change to the right managers, and to help in whatever you can until the situation is resolved.
Sometimes you may fail because others do not understand the gravity of the situation. Don’t give up and continue trying. You can never say “I have done what I can and it is the problem of someone else” if it means failure of execution of the right product strategy. A few days after I wrote the first draft of this blog, Marty Cagan published a view on this which I strongly support: “CEO of the Product Revisited”.
Putting it to the Test
A few years ago, I was working as a product manager in a company that still worked in waterfall methodology. The engineering team was inefficient, and it took them few months to deliver requirements I wrote in 2 weeks. Most of my time there was spent talking with management to try and move them to agile and fix the processes. I understood that nothing else mattered. That was the big issue that was stopping my team. At the time the engineering management did not understand the real problem, but my efforts were not in vain. It took them more time than I thought, but after more than a year they finally started the process and moved to a more efficient agile process.
Of course, moving to agile was only the beginning. Doing agile the right way with discovery in mind is not intuitive for so many teams but this is a subject for another time.
Conclusions
I can give many other examples, small and big, and I promise to do it in consecutive blog posts. However, it does not matter, because each organization has its own blockers. Remember that your role is to deliver the best product that serves your customers and your company. Find out what the blockers are and put your focus there. Once you solve one blocker, go look for the next one.
In the meantime, don’t forget to handle your long term tasks such as strategy, goals and metrics and your daily tasks such as prioritization, requirements and more. They are as important as releasing the blocking points.
Always Look at The Big Picture.
Comentarios