Because if you’re working on a project big enough, you don’t have the time to be a good dev or a good manager.
As a developer I wanted time to think about how best to solve the problem I was facing, not writing documents, refining the big picture, get a buy in from the stakeholders, giving reports, making sure the other parts of the project kept getting along and so on. It was important for me to be kept in the loop, not doing it on top of my job.
As a product manager, it’s the other way: I have a product that need to be there and so I’m trying to find a good compromise between the stakeholders idea, what would really work and what can be done with the ressources I have. That means sometimes I recommend to not start anything, but to buy a solution (then I need to validate that it will work as intended, that the budget and contract are ok and so on)
It’s another job altogether. That doesn’t mean I won’t follow the technological trends, educate myself or refuse to program anything. I wrote some postman script to validate what’s happening with our api, know the infra behind it, and can generally point people in the right direction. I have to know the product inside out to make educated answers when something goes wrong or if a decision is required.
It’s often a people job. And that’s something I try to share with the teams I work for.
When I was a product manager for large computer systems back in the dark ages, I can pretty much guarantee you that none of the engineers wanted to spend probably the majority of their days on the phone with sales reps, in customer meetings, providing updates to management and other groups involved with product launches, writing technical sales docs, and reviewing marketing materials, etc. Many engineers liked sitting in on a customer meeting now and then as a change of pace but they (properly) wanted to spend the bulk of their time focused on actual engineering.
That’s not product management. That’s an under-qualified person misunderstanding their role. Product management is mostly a people job, understanding internal stakeholders, understanding customer, understanding the market, understanding the solution options, formulating and understanding strategy for the product, coordinating product marketing and documentation for the product.
If someone can do all that well, there’s simply no time to micro manage jira tickets
Even if they have the time, my rule is that nobody who does not understand the complexity of the solution (not the problem or the what) should be allowed anything more than watch rights in jira and standups. I would love to hear one non coding product manager who does not run jira in their org of more than 100 people.
The problem is that it is hard to be a product manger and own those tough customer metrics. It is easy to do jira and get credited for engineering work.
It’s another job altogether. That doesn’t mean I won’t follow the technological trends, educate myself or refuse to program anything. I wrote some postman script to validate what’s happening with our api, know the infra behind it, and can generally point people in the right direction. I have to know the product inside out to make educated answers when something goes wrong or if a decision is required.
It’s often a people job. And that’s something I try to share with the teams I work for.