I have recently shifted my field of work from being a backend developer to a product manager. This feels like one of the major shifts I have taken in a long time.
As I write this post, I have completed 3 months of being a product manager, and I’ll discuss what I have understood so far. So let’s dive in.
The Definition Problem
Product Management is actually a really blurry field to define. I suppose that’s why whenever I try to define it, a new task pops into my mind, which I can’t ignore, and that too gets added to the definition. This makes it challenging to describe in simple words.
One of the main reasons for this is that with different companies, the definition, workflow, and responsibilities of a Product Manager change. It also depends on the company, the industry, and even the size of the organization.
To tackle this, I have set some basic rules for myself that help me keep going in this field.
The Rules
Rule #1: You are not the manager of anybody.
Nobody reports to you. You are nobody’s boss, and you can’t fire anybody in the organization.
I made this rule in my early days, but in the culture I’m working in, the team does report to me, and I also take scrums.
But consciously, I’ve ruled it out in my head that I’m not the manager of the team, but of the product. This helps me shift my focus completely from “who is doing what” to “which feature/bug are we working on”.
It may look like a small shift in thought, but it really helps me focus on the work rather than on the team member who is doing it. Somehow, it also gives me a little peace of mind.
Product building is a collaborative effort of skilled people working together. If I think of myself as the team’s boss, it gives me a negative point, because the team may feel hesitant to disagree with me. I don’t want that. I want the team to feel free to put their points forward whenever they feel like it.
Rule #2: The Product Manager should work as a catalyst.
One of the core work of a PM is to become a catalyst between team members, between different functionalities. If anyone is struck on any feature, or have any doubt, it becomes the Responsibility of the Product Manager to either help them directly, or find help in the team. So that the work keeps moving forward.
Rule #3: The No Doubt Rule
In the team of engineers, leads, and upper management, I should not doubt anyone’s capability. If our team have an engineer, they are the best, and same goes for lead, upper management, designers, everyone who is directly or indirectly involve in the project.
I am working with the best team, which can do anything. This line is so powerful and gives immense confidence to me while working with the team.
Even if someone makes a mistake, I try to move my focus from “who” to “what”, instead of starting the blame game (I have seen many, it is pure garbage game), my focus should be on what went wrong. And how can we build a system so that it can be cured next time.
Rule #4: There is a “Manager” in your designation, act like one.
If something, or anything, goes wrong in the Product, I, as a Product Manager, am responsible for that. I need to be extra cautious with the things we are working on and how the end-users are going to benefit from the product.
It is not the developer’s work to think about it, it is completely my duty to see the product through the eyes of end-users and plan the product accordingly.
Basically, the Product Manager is responsible for that product being successful.
Maybe in the future, many more rules will be added with time. For now, these 4 rules are what I’ve been following in my first 3 months as a Product Manager. They may not be universal, but they help me navigate the blurry world of Product Management.
I hope you found them helpful. What are the rules or principles that guide you in your role?
I am happy to learn more.