Why product management is harder than tech
On the surface it might look as if product management is just about writing a couple of Jira tickets and have them implemented by engineers. And since the daily activities are typically not very technical, people might be inclined to think that anyone can do product management.
At least that is how it might look from an engineer's perspective. Well, unfortunately things are not that simple.
Anyone can do product management. But only few people can do product mangement really well.
To the customer, only the product matters
Customers have problems and they want solutions. They couldn't care less about the underlying technology.
Customers only care whether the product you are offering is solving their problems.
Software is not an end in itself but it is a means to create business value.
So basically by offering software to the customer, you give the customer superpower. But it was never about the software. It was always about the the most effective way to solve customer's problem. In other words: customers don't care about tech, they care about solutions.
Therefore, product has a super important role. Because after all product management decides what features and functionalities will be built next. All decisions are made with the customer in mind: which feature brings the most (business) value for the customer?
While this sounds very straight-forward on an abstract level, this actually becomes much harder in practise.
Product Management: many options, but no time to implement
When you do product management you got plenty of ideas and the dragging feet of the tech department.
There is just no time to implement everything. So you need to prioritize. Now if everyone was perfectly rational, the prioritization would be pretty easy. However, stakeholders oftentimes don't optimize for the global, company-wide optimum, but for their own interests.
So if you do product, you need to assess in a neutral way what functionality to implement next. It can be really hard to distinguish the things that are truly worth doing from just some stakeholder's personal interest.
Product Managment and requirements engineering
Anyone can write a ticket. Few people can write really good tickets.
Creating tickets might seem like an easy, sometimes even dull task. But actually, if taken seriously, it is an engineering discipline which is called requirements engineering.
The engineering part here is important because ultimately we strive for a systematic, repeatable and engineering-driven way of eliciting requirements.
As a product manager it is important to understand the level of detail an engineer needs to actually implement a ticket. And as a product manager, you also need to take care of all the edge cases:
- What happens if the customer enters wrong data?
- What happens if a particular data point is missing?
- ...
In my experience there's only few product manager who understand the level of detail that a developer needs to actually implement the ticket.
Tech and product have its own challenges
Granted, software and technology does have its learning curve.
Spotting a bug in a big and messy code base can be challenging. But the thing is that the entire software development process in itself is very logical and consistent.
Even though code bases might be hard to understand at first, once you get the hang on it implementing a new feature is a very structured and repeatable process - unless you do some cutting-edge stuff.
So in other words, the implementation of a ticket is typically a very straight forward and linear process without many complications once you understand the code base.
However, things look completely different when we are talking about the product side. On the product side you need to
- handle many stakeholders at the same time who don't (want to) see the bigger picture
- deal with politics and irrational people
- involve a lot of different people - even for tiny changes
- write a complete, unambiguous and contradiction-free tickets that also take into account the edge cases (if you have software development experience then that helps a lot)
The complexity in product is not due to its analytical nature, but because if involves dealing with people who oftentimes behave in completely irrational way.
As a product manager you are always in between stakeholders and oftentimes it is the missing, incomplete or incorrect requirements that cause delays in projects and not the coding speed.
Conclusion
As we have seen, product is a multi-dimensional discipline that requires the product manager to align with a lot of different people who might behave in an irrational way. In a way product management is less demanding on the analytical side - even though it takes analytical thinking to provide a clear, contradiction-free and complete ticket.