Why Product Management Is a Laborious Role
What is a product manager (PM)? PM is a person who manages the product, in other words, the “CEO of a product”. According to the Scrum Guide, PM is a person who is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Although there is a well-known and short definition of PM, maximizing the value of the product resulting from the work of the Scrum Team hampers the PM’s efforts to manage the product. How does it make PM’s life difficult? I am going to summarize three well-known situations for this question.
The first is that PM’s responsibilities change across different companies.
Although PM’s main duty is to be “CEO of the product”, PM’s roles and responsibilities change across different companies and industries. After deciding what the team will do, PM’s role is to design the product or feature. However,
Design is not just what it looks like and feels like. Design is how it works.- Steve Jobs.
PM with less design and technical approach: In some companies, PM works as a project manager- when a task will start and be completed- because the design decisions are made by another dedicated team. In other words, executives supply a long-term vision for the company, and PMs are tasked with implementing that vision.
PM with more design and technical approach: In some companies, PM works as a more technical person writing technical specification documents, describing product capabilities, appearance, and interactions with users. In these companies, it is hard to update the product after release because it is likely to have a long release cycle and an enormous customer base.
PM with more design and less technical approach: In some companies, PM works as a communication hub by discussing user interfaces with the design team, technical constraints with the engineering team, and metrics with the analytics team. In these companies, it is likely to have a short release cycle and move quickly to run new experiments, and PM is considered a non-technical person.
Therefore, PM’s responsibilities changing from company to company prolongs PM’s adaptation time and makes PM’s life difficult when they change their job.
The second is that PM has to influence a coder, a designer, and a business owner without authority.
Although PM is the “CEO of a product”, PM does not have direct authority over people. What does PM do? I think nobody certainly understands what they do except for other PMs. PM does not code. PM does not design. PM does not sell something. On the other hand, PM is the balance between technology, user experience, and business. PM does not code, however, has to convince a coder to do what they do the best. PM does not design, however, has to convince a designer to do what they do the best. PM does not sell something, however, has to convince a business owner to do what they do the best.
Hence, persuading a coder, a designer, and a business owner means that PM should always work on all sorts of different things like design, engineering, and business. So, PM should speak their language and let them do what they do best.
The third is that PM must juggle different expectations and realities.
Stakeholders and customers always come to PM with requests to add new features. Saying “yes” to all requests is easy, but, unrealistic.
Human wants are unlimited but resources are limited. — The scarcity theory in economics
- Some requests don’t support the company’s primary objectives. This means that PM can’t add these types of requests to the roadmap at least for now because they don’t meet the company’s primary objectives and they needs to focus on the company’s primary objectives.
- Some requests support the company’s primary objectives but might be a high-cost feature. This means that PM might not add these types of requests to the roadmap at least for now because development schedules are filled with emergent features.
- Some requests support the company’s primary objectives but they might be a low-impact feature. This means that PM might not add these types of requests to the roadmap at least for now because the roadmap is filled with high-impact features.
As a PM, it is usually a good idea to explain how you prioritize and use data/experiment rather than the gut feeling for the requests above which are not added to the roadmap.
It is obvious that the product manager’s role is more like an artist than a scientist. Changing responsibilities across companies, influencing all parties without authority, and juggling expectations and reality might make a product manager’s life difficult. As a product manager, it might be better to improve technical, design, and business knowledge to speak the same language with all parties by adapting to different companies. Moreover, being transparent about the roadmap might help a product manager to explain the reasoning behind the prioritization even if you say “no” to some of the requests.
