1a. Definition of a PM

What does a product manager actually do?

This is a surprisingly hard question to answer. It’s not because PMs are a rare, uncommon job function – almost every tech company of some size will have them. Rather, it’s because the role of the PM can vary significantly depending on the company, the product, and the particular project.

Fundamentally, a product manager tries to determine what needs to get done, and tries to get it done. (More colloquially, “get shit done”.) We can break this down a bit more:

“…determine what needs to get done…”

This refers to what the company needs to do to achieve its goals – really anything that the company deems is important for the company overall or the product area the PM oversees. Generally, the PM helps shape what the goals of the company should be (although their ability to influence this decreases with the size of the company).

Here are some examples of what goals in a company look like:

  • A startup might want to really ramp up the number of users it has, to demonstrate product-market fit
  • A startup about to raise another round of funding might want to demonstrate higher user engagement or higher lifetime value per user
  • An existing product area within a large company might want to demonstrate that it can be a significant revenue stream, and thus it’ll aim for top-line growth
  • A very mature product area might have high infrastructure costs that it wants to reduce without reducing the quality of the product

(Goals are not always clear, which is a dangerous situation for a PM. A PM could try to set her own goals, but there’s no telling when the company might decide to shift priorities.)

Once the PM has his goals in mind, he then figures out what needs to change about the product or the business to accomplish those goals. Most commonly, this will involve changes to the company’s actual product in the form of a new feature, a new product offering, or a revamp of something existing. In some companies, PMs also have the latitude to influence the business side of things, such as operations, marketing, or business development, in order to pursue the goals.

“…and tries to get it done.”

It’s usually the PM’s job to push projects along to try and actually complete the project (the new feature, the new product offering, the revamp, etc.) and eventually launch it (also called the “go to market” process). This is where it becomes hard to define exactly what the PM does, because different projects require different tasks to get done.

The PM is not working alone, of course. She has to work with engineering, UX, marketing, sales…any other function at the company that has a hand in the project in question. This means that sometimes the PM is playing more of a coordinating function between the different teams at the company. Or, he might even be filling in for a given role if the company hasn’t built out that function yet (like at a startup). But, overall, the other functions will be looking to the PM for guidance on what exactly needs to be built, why it needs to be built, (to some extent) how it should be built, and how it should go to market.


Let’s dig in a little bit more – here are some other things that PMs usually do:

A PM occupies an interdisciplinary space

Building a product requires involvement from a lot of different functions. The PM acts as a hub between all these other functions, making sure everyone’s aligned on the goals and often coordinating any touchpoints. The PM should know what’s going on in every other team, and should be able to answer questions that are outside a team’s particular mandate.

If this sounds familiar, it’s because many other industries will have a role similar to a PM. In some CPG companies, it’s a brand manager. In other companies, it might be labeled marketing or product development. A PM is the tech industry’s version of this role.

A PM is a jack-of-all-trades, master-of-none

Because the PM is the interdisciplinary person, she usually dabbles a bit in all the involved functions. Let’s say a particular feature launch will require marketing support in the form of a blog entry and social media posts. A large company would probably have a marketing team in charge of creating these marketing assets; the PM would coordinate with them to figure out the details of the launch. Even with a marketing team, it’s helpful for the PM to understand how the company’s launch marketing works, and she might even help contribute some of the material for the blog or social media.

In a smaller company, there might not be a marketing team, in which case it’s up to the PM to do that work. The PM is not a marketing specialist, but needs to be the one to figure out what needs to get done, and how to do it. This speaks to the fact that the smaller a company is, the more scrappy and flexible the PM has to be. At a small startup, a PM might even be coding a bit, or doing some of the UX / design work.

A PM can NOT act unilaterally

A PM’s job is all about working with and through others. The larger the company, the less the PM can actually “do”, because there are teams that specialize in the various key activities tied with a launch.

Yet, here’s the paradox of the PM role: even though the PM has to work with and coordinate many other functions on a project, generally the PM has no direct authority over those other functions. Thus, a large part of the PM’s job is to influence change, not mandate it. You might hear that a PM is a “CEO of the product”, but this means that the PM has responsibility for how the product does, not that the PM has the authority of a CEO!

And let’s not forget – people are sometimes hard to influence! Different teams will have their own priorities and are being evaluated on slightly different factors. It’s up to the PM to influence the other teams to work on certain projects in a certain order. Sometimes a company will have very well-oiled processes for the PM to enact this kind of influence. But at other companies, it could be much tougher and laborious to gain the agreement and support of all the functions needed for a project.

A PM tries to understand the user’s need

The goals that guide a PM always tie back to the user – either an existing user or a potential user of the product. The PM is in charge of thinking about what exactly is the “user need”, or the user’s problem that the product is trying to solve. For example…

  • Google Search addresses the user need of trying to find information on the internet
  • Facebook addresses the user need of keeping in touch with friends and family
  • Kayak addresses the user need of finding the right, affordable plane ticket
  • Blue Apron addresses the user need of figuring out what to cook for a meal and how to cook that meal

This is not exclusively the purview of the PM. UX, for example, also cares deeply about the user experience, and will help the PM understand and explore the user need better. But, overall, a PM has to understand and articulate what the user needs or currently finds suboptimal.

Moreover, the user’s need will change over time, as the product and its competitors evolve over time. A new launch or product may address the main user’s need in the short term, but the experience could always be improved, or a related user need might be unearthed. This is what keeps the PM in the job!

A PM thinks about what to build next

The PM should have an opinion about “what comes next”. This is usually based off of some combination of thinking about the user need, collecting quantitative and qualitative data about users, referencing the company’s overall priorities, and a dash of product “intuition”. When ongoing projects launch, people will generally look to the PM for what the next set of projects should be (although hopefully the PM will have signalled this before that point).

A PM develops a vision for the future

A PM not only thinks about what the immediate next step is, but also about what the future might look like. A product “roadmap” is a description of how the product might evolve over a longer-term horizon, usually more than 1-2 years out. It ranges from a series of projects that the team could tackle one after the other, to a view of how the product will fit into the competitive landscape in the future. The vision is usually a grander statement of the potential for the product and company. It should be motivating (perhaps even inspirational), but it should also draw a reasonable link between the present and that future state.

Note that nobody expects this roadmap to be set in stone, nor does every detail about execution need to be figured out today. It’s meant to be a tool to guide and motivate the team in the short- and medium-term future.

A PM prioritizes

Thinking about what to build next and the longer-term vision is all well and good, but at the end of the day, the teams working on a product have to actually build something. And, if all’s well, there will be more ideas about what can be built now than the team has resources for.

The PM’s role in this case is to prioritize the different ideas to figure out the order in which things should be tackled. This is not a unilateral decision – the PM needs to work with all the other involved functions to develop a prioritization that is workable for everyone involved.

A PM is a communicator

By now, you’ll have noticed that influencing others is a large part of what PMs do. Thus, communicating with others is a large part of what PMs do. This usually involves a mix of smaller meetings (eg one-on-ones, team standups) to communications with a wider audience (eg a large presentation). In this area, there seem to be two fundamental truths:

  • It is impossible to overcommunicate – others are never in sync with you as much as you think
  • It never works to go off, do a lot of thinking by yourself, and come back with a fully-baked plan that you then expect others to 100% agree with

That was a long definition of what a PM does, but hopefully it resolves some of the ambiguity around the role. Again, even though all PMs might share the characteristics above, it’s hard to overemphasize the diversity of exactly what different PMs do at different companies – it all depends on the company, the product, and the specific projects in question.