Three things to avoid during Transition

Transitions are exciting and stressful. Here are some things to avoid when you transition into a new PM role, irrespective of where the transition is from (a new role or a new job)

Making noise without identifying who owns the KPI - Especially in a big organization, when you join the train midway, you may encounter some fundamental why, who would use this and what if questions. Questions that bother you so much that you feel uncomfortable being associated with the product. You have the options of taking time and sailing along hoping one day it would make sense, or, start raising questions to the leadership. When you decide the latter, the challenge is - in big organizations, your reporting line may not be the owner of the KPI and that may add to your confusion. More often than not, there are good reasons that back the product initiatives that you have fundamental questions about. There are product initiatives that may sound too optimistic to you, but could be strategic or are meant to target very niche segment. You want to make sure you find out the KPI owners to understand the right motivation instead of owning a feature that you dont believe in.

Beating yourself up for the gaps in the product that you're taking over - When you become the product owner of something or rather, when something becomes your product or your platform, you want to make sure the product or the platform does not have gaps in the basic utilities of it. However, you find out gaps or a stakeholder comes up with a question and you feel uncomfortable admitting (to yourself and to the stakeholder) that 'your product or platform' doesnt have some basic capabilities. You may not want to play the newbie card and you start beating yourself for the product or the platform being imperfect. You dont need this added stress, which would even hinder you from thinking from a new perspective about your product.

Not thinking beyond the existing scope of the product - When you take over an existing product or platform, there are chances that you get overwhelmed by learning the existing product and constrain yourself with what the product is already about and with the existing problems that the product or platform is supposed to solve. It may even make you frustrated or demotivated because you feel that the product is in maintenance mode. The trick is to not become limited by what exists already. You gotta think about what additional use-cases your product or platform can serve.

Three Newbie PM Mistakes

I transitioned from engineering to product management and have been in the continuos cycles of making new mistakes and learning from them. Here are a few of them:

Confusing solution design with product design - This particularly applies to the newbie platform product managers. The requirements rely heavily on what the solution would look like. Dont get me wrong - a product manager should definitely be involved and invested in the solution design, but speaking the requirements or use-case language vs. api or services language can be a learning curve for a newbie (especially someone who transitioned from engineering).

Not having your own roadmap items - Especially in large and growing organizations, resources can easily be sucked up in meeting the needs of the stakeholders and upgrading the infrastructure. A newbie PM would have the added pressure of pleasing the stakeholders and build relationships with the engineering. This could lead to not having your own vision of the product or the platform you are accountable for. In fact, it may get to a point where one feels identity crises.

Relying on engineers to build the tracking - Another newbie mistake is to think that the 'requirements' for building a feature doesnt include the call out for data logging and the PM ends up relying on the engineers to log the right data that could eventually be used for tracking product performance. No matter how small a feature is - one needs to think through the tracking upfront!

What do the Product Managers Do?

Product manager role has one of the broadest job descriptions and it is one of the hardest roles to explain. Here's my take:

Product managers are responsible for identifying and solving the customer problems, measuring the effectiveness of the solutions and iterating. They are engaged in all activities involved in these cycles - from talking to customers to forming solutions, from creating requirements to testing the solutions and from launching the solutions to taking feedback from the customers. Obviously, in most large organizations, one person doesnt get to do all these tasks, but in one way or the other a PM (or an ideal PM) should be involved throughout the lifecycle of a product, which is nothing but a solution to a customer problem.

One would argue that not all the product managers work on customer facing things. Yes, that is true. In fact, most product managers would seem to be not working directly with customer facing things, but if we broaden the definition of a customer and include internal stakeholders, then most product managers should be working on solving a customer problem. Although writing requirement documents or user stories is probably the most important task of a product manager, it is far from being the only task.