top of page

What Do PMs Do?

A man working at a computer

Maybe a better title for this post would be "What SHOULD PMs Do?" because almost no one seems to agree on this issue. The actual job duties vary wildly from company to company. Even the experts seem to disagree quite a bit on this topic. And worst of all, there are a lot of hidden expectations setting landmines for unsuspecting PMs who think they are doing their job correctly, but who are actually being silently judged (and found wanting!) by their peers and supervisors.


Disclaimer: This post contains what I think PMs ought to be doing, which may or may not reflect the reality of what they are doing at your company.

Let's get a basic definition

Venn diagram of business, UX, and tech with product in the center
^^ Not true!

Just about everyone starts with some variation of product managers being at the intersection of business, user experience, and tech. You've seen that Venn diagram of it a thousand times, right? (May I recommend choosing an alternate at The 10 Best and Worst Venn Diagrams Explaining Product Management?) Personally, I think that's an outdated explanation that appears to give PMs ownership of tech, which isn't theirs in the slightest. And UX should be shared by both the product designer and the PM with input from tech.


Instead, I think I'd rather take Melissa Perri's definition. Perri, author of Escaping the Build Trap and Product Operations, said "My definition of Product Management has always involved optimizing the business and user needs to produce value for both sides."


Or, we can go with a similar definition from Marty Cagan, author of Inspired and Transformed: "The job of a product manager of an empowered product team is to be responsible and accountable for addressing value and viability risk" where he defines value as "whether customers will buy it or users will choose to use it" and viability as "whether this solution also works for the various aspects of our business."


Here's my version, which I think is a little easier to read because we get away from that nebulous word "value", which I find hard to concretely define. Product managers are responsible for meeting business goals while creating solutions that are compelling enough to get customers to buy and use them.


But what do product managers actually do?

Good question. It's not really clear yet, is it?


So, let's talk about the four key activities that PMs own. They have a tendency to overlap a lot, but that's okay because product management is a complex job with a lot of different responsibilities in a lot of different areas.


  1. Discovery - You primary responsibility is learning what your customers need, want, and like. Discovery also covers understanding your business's needs, the market, and your competitors. You'll be running tests and gathering feedback. You'll be talking with lots and lots of people, both internal and external. You'll monitor product performance after releases to see if launched initiatives performed as expected and if there are any interesting trends or anomalies to investigate. You'll also act as the subject matter expert (SME) around all these topics.

  2. Product tactics - In general, your boss or someone even further up the chain will own the product vision and the product strategy, though you should be part of those conversations as a SME and the product manager. You, however, own the tactics to get the strategy done. This includes building the roadmap and prioritizing initiatives. This is the "why" behind what gets built and the order in which it's built.

  3. Initiative design - Roadmaps are filled with individual initiatives. These are specific products and features being built to accomplish the product tactics. You'll be working hand-in-hand with the product designer and the tech lead, plus hopefully one or more of the engineers, to figure out how to meet a specific user need with an amazing user experience in a way that is feasible and maintainable on the tech side. This is a highly iterative cycle, which means you will likely be working on multiple initiatives at the same time but be in a different place on the cycle for each of them.

  4. Comms - I could just have easily called this category "Peopling" but "Comms" sounded more professional. This is a very diverse groups of activities around explaining how and why product decisions were made, keeping everyone informed about initiative statuses, building trust with coworkers and executives, hyping upcoming product releases to internal groups, reporting back on how successful launches were, answering questions, and more. The unofficial motto of PMs everywhere is "Communicate, over-communicate, and then over-communicate some more."



Another way of looking at it

In order to be really clear, let's talk about what product managers do NOT own and what they should NOT be doing:

  • Management - PMs are not in charge of cross-functional teams, they don't get to tell anyone what to do, and they are certainly not the "CEO of their product." PMs are good team players who accomplish their goals through collaboration, negotiation, and the bank of accumulated trust they have built with their coworkers. Obviously this doesn't apply to you if you have actual direct reports; in that case, you have an additional job of "leadership" with different duties.

  • Sales - In general, PMs should not be training sales or doing customer demos, though there are rare occasions for high-profile clients where you might get called in as a subject matter expert to help close the deal.

  • Product Marketing - PMs shouldn't be writing press releases, creating one-pagers, writing playbooks, writing internal training materials, and other such content.

  • Customer Operations / Support - PMs shouldn't be onboarding clients or handling their special requests or updating configurations for a user.

  • Data Science - You absolutely need to embrace and love data, and be extremely data driven in all you do. But you also need to understand that data science is a complicated field with lots to consider in order for your data to be meaningful. You should be comfortable with basic data analytics, but make friends with a data scientist because you are going to need their help!

  • Finance - I really don't think PMs should be involved with setting pricing, other than knowing what the market currently is paying for similar products. Setting pricing is really a job for sales or finance or the CEO or the general manager of the business unit.

  • Design - PMs should leave product design to experts, though I will repeat myself: user experience (which is not the same thing as product design) is shared.

  • Engineering - This is going to be the one to provoke some strong reactions, but product needs to stop sneaking into engineering. PMs should not be "running" product teams, playing the role of either scrum master or product owner, looking at velocity and burndown charts, interjecting themselves into how deployment works, and many more things that I see PMs regularly doing at companies.


Do you see what I did there? The list of things product should NOT be doing are all departments that already exist who have people who should already own all those things. Not only do we not have time to do all the activities in that list, but we miss out on the chance to collaborate with the accomplished, experienced professionals in those departments who already know how to do their jobs better than we do.


Caveat: When working at an early to mid-term startup, all of these rules are off the table. In those companies, everyone is probably wearing many hats every day and the specialists in the other departments may not exist yet. If you are in that situation, do what needs doing!

 

I'm not sure if that cleared anything up or not. No two days for PMs ever look the same, which is part of why I love being in product. We do so many different activities that it's hard to even create categories for lumping them together. I look forward to many, many blog posts in the future to dig into the ideas here.

Comments


bottom of page