Why product management is harder than tech
On the surface, product management looks like writing Jira tickets and having engineers implement them. Since the daily work isn’t very technical, people assume anyone can do it.
At least that’s how it looks from an engineering perspective. Unfortunately, things aren’t that simple.
Anyone can do product management. Few people can do it 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 solves their problem.
Software is not an end in itself. It's a means to create business value.
By offering software to the customer, you give them superpowers. But it was never about the software. It was always about the most effective way to solve the customer’s problem. Customers don’t care about tech. They care about solutions.
Product management decides what gets built next. All decisions should be made with the customer in mind: which feature brings the most value?
Sounds straightforward in the abstract. Much harder in practice.
Many options, no time to implement
When you do product management you've got plenty of ideas and the dragging feet of the tech department.
There’s never enough time to implement everything. So you prioritize. If everyone were perfectly rational, this would be easy. But stakeholders don’t optimize for the company-wide optimum. They optimize for their own interests.
So as a product manager, you need to assess in a neutral way what to build next. It’s hard to distinguish what’s truly worth doing from what’s just some stakeholder’s pet project.
Requirements engineering
Anyone can write a ticket. Few people can write really good tickets.
Creating tickets might seem easy, sometimes even dull. But if taken seriously, it's an engineering discipline: requirements engineering.
The engineering part matters because we want a systematic, repeatable way of capturing requirements.
A product manager needs to understand the level of detail an engineer needs to actually implement something. You also need to cover all the edge cases:
- What happens if the customer enters wrong data?
- What happens if a data point is missing?
- …
In my experience, few product managers understand the level of detail a developer actually needs.
Tech and product have different challenges
Software development has its learning curve.
Spotting a bug in a big, messy codebase can be challenging. But the entire software development process is very logical and consistent.
Even though codebases can be hard to understand at first, once you get the hang of it, implementing a new feature is a structured, repeatable process.
The implementation of a ticket is typically a straightforward, linear process once you understand the codebase.
Product is different. 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 different people for even tiny changes
- Write complete, unambiguous, contradiction-free tickets that also cover edge cases
The complexity in product isn't analytical. It comes from dealing with people who behave irrationally.
As a product manager you’re always stuck between stakeholders. It’s the missing, incomplete or incorrect requirements that cause project delays. Not the coding speed.
Conclusion
Product is a multi-dimensional discipline. It requires aligning a lot of different people who might behave irrationally. It’s less demanding on the analytical side, but it takes sharp thinking to provide clear, contradiction-free, complete requirements.