Product Management is become a more well-defined professional in the last few years. Recruiters, human resource and hiring managers are using this term more consistently, and are adoption this more and more in their job postings.
As I'd often like to say, Product Management is fragmented, and no two product management roles and responsibilities are the same. Even two people working in the same company, with some of the same resources are likely to find there is a different dynamic to the product, the team, the users etc.
Product management also differs when the company is a certain size too -- in a smaller company you are likely to do everything from sales, marketing to launching whereas a large multinational company you are looking at taking on a more specified role. Or it could break all these rules depending on your company culture and environment.
As such, what I do want to do is get the core of what Product Management roles and responsibilities can be...at the very very core and less focused on the environmental and specific setup that each product, team and company may have.
Product managers play a crucial role in any given day. Products typically range from products used in-house or the actual end user are clients of the company.
If we have to distill the core product management roles and responsibilities, it would be this:
It seems pretty simple on paper and perhaps at this level without going into the specifics of the job, it sounds like any other middle management job.
If we have to distill it further, it would be the the ultimate objective a Product Manager is to "own" the entire experience and take responsibility for the product or service. Ultimately, their success is the success of the product and vice versa.
Great product managers (and this entire website is an exploration of how to achieve mastery and excellence) is about knowing the market your product serves, knowing the competition, knowing the nuances of the market and opportunities to exploit so that the product can thrive.
The table stakes are to know all this and/or learn about this you go along and grow into the role.
The other part of it is communications. I originally bought this book when I was starting out as a product manager in a large company. There were many stakeholders, many divergent opinions on strategy and execution and I had to have any tough and frank conversations.
I wished I had know about this book sooner and while I'm still in the middle of finishing it, I've also seen from some amazing Product leaders on Twitter that it has really helped them become better product managers in communicating he vision and strategy. Having Crucial Conversations early and often is one of the things I've found to lead to success as a PM.
These conversations lead to discover with stakeholders and also being able to distill this into a singular vision. Ideally the vision should be a short, elevator-pitch-like blurb. This is the "north star" that people can always come back. Sometimes you can get lost in all the details and forget the forest for the trees -- a great vision helps call out and reminds everyone who the product is for and is aspiration to both the solutions team and also end-users or customers.
Strategy goes without saying. It's finding the right mix of things to do in order to exploit an opportunity in the market. More on this in other areas of our Product Manager advice section.
Choosing to do one thing over another is hard. But it's the reality that we will always have limited budget, resources and time to do all the things we need to do as Product Managers.
In my experience working on both external client-facing mobile apps, to enterprise SaaS applications, it's always trying to choose what to do next that is the best possible thing to do for the product.
This is where the KPIs (key performance indicators) or metrics is important. Every product, no matter in what setting needs to set some quantitative measures to ensure decisions we make to fill the Product Backlog or roadmap is in fact needed. It also set ups a way to measure the impact of any implementations or feature released.
Prioritizations are inherently hard. Crucial conversations are important to guide the internal team and all stakeholders to know WHAT to do, WHY we are doing it. This is a marked distinction than trying to come up with the HOW. The focus instead for great product managers is the WHAT and the WHY.
If you can answer that, communicate that well, motivate your team and stakeholders to make trade-offs, do tiered releases for a feature or choose to do it at a later time, that's all the main product management roles and responsibilities.
Sometimes it picking between fixing defects and new features. Sometimes it knowing that if we don't fix a production issue, it's not going to do well for usage so that take precedence over a much asked feature.
There's never an easy way of doing this and to top it all off, prioritization also means saying 'No'. Saying no to any distractions, any low business value features or fixes that are bound to be in the way of the vision and strategy. It's a complex process and one that is unique to your situation as you master product management, but prioritization is a key responsibility of any good product manager.
There are the team that the Product manager leads with a Scrum-Master or Project Manager, developers, designers. The product manager is the key person to liaise with other groups including marketing, sales, engineering, QA functions, etc.
The key reason is this, these stakeholders serve as subject matter experts to drive requirements for the product. They may be coming to you for requests to build something to meet their needs, they would coming to tell you some timelines and dates they need to meet because expectations have been set.
Either way, your job as a Product Manager is to anticipate risks, problems and clear them up before they become a real issue.
Product Managers don't know it all and they shouldn't, but in order to know the WHAT and the WHY of doing anything to your product, you need to be connected to every person that is serving to deliver this product.
You need tentacles in all these areas and you need to be there to tease out requirements or concerns even if they aren't explicit.
Sometimes it means needing to stand back and take a look at the end to end experience and to know which are potential blockers.