What does a Product Manager do?

I was asked this question twice in a week by two different people who have ventured into Product Management newly.

The definition of Product Management is so ambiguous that I find it hard to fit inside a well articulated description.

It is as ambiguous as it is varied.

To make an bold attempt, from 30,000 feet above,

A Product Manager supports the team towards successful outcome.

Be it a good outcome, or a bad outcome depends on how the Product Manager has set the vision and goal of the product or feature they are into.

So here’s what a typical PMs would do or does, or expected to do.

Zero authority

A Product Manager has no explicit authority to tell what needs to be done.

PMs are not heads of an engineering division, nor the design division of a product.

They neither hire or fire people.

A PM however has fair advantage over the idea that is being conceptualised, designed, and developed. The use cases, or the prototypes or the test cases pertaining to the product or feature is what belongs to the PM, but not the people implementing it as well as the how it is being implemented by design or development team.

A PM has complete control over what is virtual, but not on real people.

Effective communicator, not just communicator.

A PM though have no explicit authority over teams, but sure does have the sole responsibility of effectively making the whole team understand the product vision and what as a whole team is rallying forward to achieve.

A PM must talk in five different lingo IMHO,

Talk to a designer like a designer.

Asking the designer to move the rectangle thingy on the screen doesn’t work out, rather tell them to move the div or container and set padding as 10px on each side to make it appear the alert box on centre of the screen.

It is not to show off that you know HTML jargons, rather it is for them to understand quicker and implement it faster.

Talk to a developer like a developer.

Don’t just tell them that report page takes much time to load, and just ask them to make it load faster.

Ask them if it has any JOIN operations being performed, if yes, why are these columns being split across tables.

By this, the developer might better brief you next time when they’re face a hiccup in timeline or during the server audit.

Talk to a QA like a QA.

Don’t bluntly ask them when will your feature be released. Ask them, when will next TB be pushed.

Ask them, what needs to be done to make the build quality better, should we involve them from design phase, and check if the said design is being developed, and what was developed is working as per the idea that was conceived to start with.

Talk to a Support rep like a Support rep

Don’t load them with jargons, tell them what you have build in clear, concise, and simple words as much as possible since they will be majorly dealing with layman’s of software.

Talk to a Sales rep like a Sales rep

Clearly articulate what you have build, and what is available with competitors. They are the one’s who get bombarded with Why should I buy from you when I have X offering the same for so-and-so price tag?

Prioritisation is the priority

Product Manager initially takes up an ambiguous problem, and then converts it into smallest chunks of action plan.

When the problem is defined and even broken down into smaller pieces of work items, the priority must still be followed up against the committed date.

When something is amiss, either make them proceed to next action plan or take corrective measure to minimise any further delay.

A simple metric that I personally have for product prioritisation is Now Vs. Later.

Now — What needs to be included right away for the upcoming release.

Later — What can be deferred for now, and can be pushed for next release.

Last one to talk in a meeting

Be it written or verbal, PM should be one last to speak.

The initial kick-off of why the team has gathered, or why the product team should read your post should be clearly mentioned for others to actually start giving their ideas.

Being owner of the idea need not necessarily have to do with leading the conversation, rather it can be time to evaluate your understanding as opposed with your team.

Make it a point to summarise the other’s person point of view as-brief-as possible if need be, so that others can review your recent summary and take discussion from there.

Single point of contact

Your product might have close contact with server team, client team, security team, and even i18n team. Make sure that you streamline all those communications and allow the developers an extra ten minutes space to take a break or sip a tea in leisure.

First advantage is that you learn the nuances of the development that is going on behind the screens, and remotely.

Second advantage is that your team starts to rely on you, making you a better manager and responsible one.

Trust in debates

Finally, as a PM, always trust in healthy debates with your team. When someone feels that your design elements are good but not worth the trade-off, listen to them honestly with all open ears.

Never get into right vs. wrong argument, it is push vs. pull in such debates.

Reiterating from my own understanding, the other person working for the product is equally excited to make the product successful.

It is not who wins at end, it should be the product that should be the clear winner at end of the day.

To sum up, these are few of core expectations that are needed from a PM.

A Product Manager simply put is paid to think all day long and come up with things that make the product a better product.

In nutshell, anybody can do it, but make sure how your idea is differentiating from other ideas.

A Product Manager although is often called CEO of the product or Product owner, I strongly defer from being called as such, since a Product Manager should pass on the baton to other teams to make it better.

From your table as a plain wireframe, to designers table to add visual appeal and experience, then to developers table where it get’s it’s breathe of life, and finally to QA and then to sales and support where it realises it’s reason of existence.

Being a Product Manager and being a Product Leader are two different things. :-)