If you were to poll 50 product managers and asked them what they did that day for work, you'd get 100 different answers. Product managers don’t write code all day, they don't answer support requests all day, and they definitely don't sit in meetings all day (or at least, I hope not).
Honestly, the best way to describe what a product manager does all day is to say they are a jack of all trades. That means a lot of things, so let's dig in.
Why are PMs so chatty?
One of the most unique things about product managers are how involved they are with different areas of the company. It is not uncommon to have a morning chat with the person over customer support, bounce ideas off of someone in marketing at lunch, and dig into some numbers with sales and finance in the afternoon.
Okay, so why are we pointing out the fact that product managers spend all day shooting the breeze around the office? A product manager works with many different departments to make important decisions in the direction of the product. In order to do this effectively, the PM needs to understand at least the core competencies of all of these roles.
Reason number 1 is that they are trying to understand. They could be asking the support lead what that top few reasons customers called in that week for so that they could fix an area of the system. They chat with marketing because they want to posture those changes well and not just teach customers that if they complain enough they will get what they want (although it's surprising how often that works). Then, they need to make sure sales and finance are okay with pushing back that new feature so that the customer can be happy right now.
Many might point at this and say it is just derailing plans and projects, but perhaps the product manager is thinking about how the customer NPS survey is going out next week, and they want to do what they can right then to remind customers that the product is there for them.
This feels like a great place to say something like "The product manager has one goal to...", but to be honest, they don't have one goal. They have many:
- They want the customers to enjoy using the product
- They want to solve customer's problems
- They want sales to increase in a new market
- They want churn to reduce
- They want to increase the influence of the brand
But the fact is that they cannot do this alone. That is why they browse the office, Slack, or the calendar often. Breaking down the silos that make up the modern office.
Defining the responsibilities
Have you ever read a job description for a product manager? Have you ever read through 10 of them? They are remarkably vague. Usually they talk about how the product manager is "expected to own the product from start to finish" (whatever that means), or "use qualitative and quantitative data to make business decisions" (AKA talk to people and look at spreadsheets to make decisions, like any office job in the world).
So, what do these boil down to?
Really, if I was hiring for a product management position, I'd say we are looking for the worlds best coordinator and communicator. A lot of designers and developers become product managers, but in some cases I think I'd rather hire an event planner. An event planner knows how to juggle projects, sell on their toes, roll with the punches, and keep everyone smiling during the entire process. A product manager does the exact same thing. Only, instead of weddings and parties, the PM is planning features and product changes.
Now don't get me wrong, there is certainly value to having a design or engineering background working as a product manager. It will certainly make your job a lot easier. I also think that for every role there are attributes which are harder to learn that others. My opinion is that it is harder to learn how to juggle projects than it is to estimate a development story. If you disagree, email me and tell me! I'd love to dive into it 😄
Everyone knows their name
So we've established above that a product manager is expected to have their finger in everyone's pie, but this also points out the product managers biggest downfall: focus.
Many product managers are charismatic and out going. They also work on lots of cross functional teams, getting to know a lot more people. They are used to finding answers that no one else can, which means when a buddy at work runs into a problem, the PM might be the first person they message on Slack.
Personally, I used to love this. I used to get excited to jump into things I knew about, and share that knowledge with others. I still like doing that, but it needs to be managed. So how do you do that?
Write it down
Product managers should be great writers. I used to rely on the support documentation and say I didn't need to write up information on new features. But an audience is a very important piece of your writing. A support article won't tell things like why a decision was made. It won't talk about how a modal was chosen instead of a new page because of a technical limitation.
Talk about it
Quit siloing yourself and your projects. Being the only person in the office who knows about something is a very selfish way to have some job security. Hopefully you understand that sunk costs are not always reason enough to keep someone or something around. Make sure you are bouncing ideas around the team as you are making decisions.
Use a public Slack channel
At Rain, we have a channel called
#product-dev-questions that is used by customer experience to ask general questions about the product which a PM or developer can answer. I get asked all the time in DMs about features and things, and now even if I know the answer I will tell them to post in the public channel. When something is posted publicly, it gives others a chance to answer and to learn.
I have learned so much about older parts of the system and features other teams have been working on by reading everything posted in that channel. Consider doing something similar if you are able.
The Jack of all Trades
Is the picture coming together? Not once in this post have I written about story points or work in progress, because those are just day to day methodologies that fail to look at the bigger picture of who a product manager is and why they are needed.
When you're building a company, very rarely is employee number 2 a PM. It usually isn't employee number 5, or even 15. So why is that?
One of the largest pieces of value that comes from a product manager is their ability to manage lots of moving pieces. a company of two or 15 doesn't have a whole lot of moving pieces, but when your product gets complicated, and you have more stakeholders than can play a round of golf together, this role becomes critical.
Many companies wait far too long to bring in a PM. It is often viewed as unnecessary overhead. A luxury. But I firmly believe that you cannot scale without one. You can build and you can grow, but scaling becomes very difficult and painful without someone there to look the big picture of what is being built.
When a company is started, everyone wears a lot of hats, usually beginning with the CEO/Founder wearing them all. As a company grows, those hats get divided into sales, support, engineering, etc. I said above that a company doesn't have a PM at the beginning, but I am wrong about this in one very important way.
From day one the CEO is the product manager. They often keep this role as long as possible because it is usually the creative vision they had to start the company. Handing off creative license to someone is not an easy thing to do. There tends to be this dip when a company scales to a point that a CEO cannot manage this portion of the work anymore. Timelines start slipping, features start being lackluster. The CEO has been pulled in too many directions and can't manage it anymore.
Enter the product manager. By no means is this move a saving grace of the growth pains or the CEO, because now the vision has to be translated and that is not an easy thing to do. That is why PM number one is almost never an outside hire. They need to understand the business, customers, and the culture to work effectively. Bring them on early, and bring them on internally to make this as easy as possible.
I hope you've enjoyed this post. If you haven't, please email me at firstname.lastname@example.org and let me know, I'd love to learn from you.