What does a product manager actually do? A new PM's take

Maybe you’re an aspiring product manager. Maybe you work as a PM. Maybe you accidentally clicked on this link and are now regretting it...

Whatever the case may be, if you’ve ever wondered what a PM does, this article is for you.

Hi and welcome to the second article in my series on product, The New PM. I’m writing this series for new and aspiring PMs to help product noobs (like myself) learn more about product management and grow into better product people.

These articles are meant to start a conversation about this stuff so let me know what you think in the comments below.

If you’re already a subscriber, welcome back! If you’re not a subscriber but want to be, tap “Subscribe” and you’ll get notified next time I publish an article in this series.

In this article, I’ll offer my take on what a product manager (PM) does. I’ll outline what her role on the team is, and how that translates into her day-to-day work.

My definition was inspired by how Linda Leung, a bomb PM on my team, defines the role.

My take…

The PM defines the WHAT, facilitates the HOW, and articulates the WHY for her product.

Here’s what I mean.

the WHAT

There are always about a thousand things a product team could build. Each has benefits, costs, and unknowns that vary across metrics, timelines, and audiences.

Feature A will drive short term engagement but hurt monetization, feature B will help with long-term retention but means we won’t get that tracking bug fixed this quarter, feature C is better for our customers but adds cognitive load for our users.

In theory, it’s easy to say the user should always come first. In practice, things can get messy.

A PM’s first job is to wade into that ocean of complexity and uncertainty, and decide WHAT her team builds.

She doesn’t have to come up with all the ideas, and she shouldn’t decide by herself. But she should come with a strong point of view and ultimately sign off both on what the team builds and in what order they build it.

An example: My team recently launched a project called Series. Series brings serialized professional content onto LinkedIn, starting with newsletters written and published on LinkedIn that users can subscribe to. Curious what a series looks like? You’re looking at one (woah). More on Series here.

Since launching, we’ve been focused on building out Series's next set of features. Coming up with ideas on what to build has been easy. Choosing what to build first has been hard.

Figuring out that order has been a group effort. Just a few weeks ago, I entered a meeting with our designer Maria with one order and exited with another. (What happened: she brought up points I hadn't thought of and an hour later most of her order became our order.)

Still, I would say finalizing that WHAT is one of your main jobs as a PM. The PM is, theoretically, best situated to make that call having the most context across functions. Will you get it wrong sometimes? Absolutely. Should you listen to and be swayed by your team? Of course. But ultimately, the PM needs to sign off on that WHAT so the team can move forward.

the HOW

After deciding what to build comes figuring out how to build it. Sometimes, a team or company already has a process they use to go from idea to feature. Sometimes, they don’t.

Either way, new features often call for a new or at least modified approach. The end goal remains the same — deliver the most measurable value to your users / customers / company as quickly as possible. But how you get there changes.

A PM’s second primary role is to facilitate HOW the product gets built.

Once again, this is not a job a PM should do by herself. In fact, one of the most common complaints cross-functional partners have about PMs is that they are too prescriptive about the HOW. Beyond being annoying and unscalable, that kind of micromanaging is also irrational. A team’s designer should know more about design than the PM; a team’s engineering lead should know more about engineering than the PM. (A good PM still knows when to dig in and/or push back.)

Facilitating the HOW is a key function the PM plays. By asking good clarifying questions, giving feedback, and setting parameters, she can both focus and empower her team.

An example: Over the last few weeks, my team’s been thinking through how we can track small changes to the product like bug fixes in addition to so-called “big rocks,” ie larger features that require substantial planning and work.

A few weeks back, we got helpful guidance on that HOW from Jasper, a more senior PM on the series team. Jasper encouraged us to group features in thematic buckets. Suddenly, 40+ features became 5 buckets of features. That change in approach allowed us to operate with greater focus (working with 5 things is a lot easier than 30) and better communicate what we were working on to partners.

While leaving the implementation to the team, he thus was able to facilitate the HOW with his feedback.

the WHY

Underlying every prioritized backlog and every JIRA board is a WHY. That WHY can be more or less thoughtful, more or less conscious, and more or less well explained. But if you keep asking, there is always some why behind what a team does. (Warning: the why may not be satisfying.)

A PM’s third primary function is to articulate the WHY behind her team's work.

This can be done well or poorly. Done well, the WHY is infused into every product spec, JIRA ticket, and email the PM produces so the team always understands WHY it’s building what it’s building and WHY it’s building it the way it’s building it.

Done poorly, the WHY is not well-considered and/or left unsaid, leaving the team to fill it in themselves. Charitable teams may give the PM the benefit of the doubt and assume there’s some good unspoken reason. Less charitable ones might assume they’re doing it just cus the PM felt like it.

An example: Every time I ask for something, I try to include a brief explanation as to why I’m asking for it. It’s something I started doing after seeing others I admire do just that. Including the why doesn’t actually take much more time to do — usually a few extra words does the trick — but it conveys the WHY and your respect for their time.

On a day-to-day basis

All PMs do is send emails and attend meetings get out while you still can!!!!

^^ forget I said that let's start this section over.

A PM’s day-to-day work largely follows what PMs call the “product life cycle.” Think of the product life cycle as the stages that a feature goes through from inception to launch.

The product life cycle deserves its own article. But, for the sake of brevity, here’s a sketch of how I think about it, and some potential PM tasks associated with each stage.

(1) Listen/Learn

Stage: listening to users, data, partners to identify what your users want most

PM tasks: looking at metrics, talking to users, meeting with partners

(2) Amass

Stage: generating tons of ideas to address the top pain points identified in (1)

PM tasks: holding / driving brainstorms with the team, getting inspired by other products (especially but not exclusively competitors)

(3) Define

Stage: getting crisp on the feature's pros, cons, requirements, success criteria etc.

PM tasks: meeting with engineers and design partners to scope work, prioritizing requirements based on expected user value divided by team effort + other factors, writing and refining spec, iterating on it with partners

(4) Build

Stage: building the thing

PM tasks: writing JIRA tickets, unblocking the team, holding stand ups / meetings

(5) Launch

Stage: getting your feature in front of users

PM tasks: setting up A/B tests and tracking, alerting partner teams, coordinating go-to-market (GTM) plan if larger project

(6) Listen/Learn (aka 1, it's a loop)

Stage: evaluating whether or not your feature worked, identifying next steps

PM tasks: looking at metrics, talking to users, meeting with partners

Caveats and exceptions abound.

All this varies by product, company, scope, PM career stage (individual contributor vs manager) etc. And, this doesn’t include all the extra admin work PMs do to keep the lights on.

The job is often romanticized with unhelpful analogies like “mini-CEO.” In my experience, most of the time as a PM, you’re just trying to keep all the balls in the air — making your meetings, keeping up with emails, pushing your projects forward — without things getting too out of hand.

The outline above also makes the work sound more linear than it is. As a PM, you’re always driving multiple projects, meaning you’re doing work from three or four of the above stages at the same time.

Nonetheless, as rough approximations go, the outline above seems about right. And, as hectic as it can be, the job is (for the right person) extremely gratifying.

Wrap up

Now it’s your turn.

@ aspiring PMs: does that make sense? Does that sound interesting / appealing?

@ other PMs: does that measure up to your experience? What’s right? What’s off?

Let me know in the comments below, and I'll see you next time.

Cheers,

Lachlan