🔢

Welcome to Product Management

It can be so fulfilling, and also so frustrating.

So… you want to be a product manager? (a “PM”)

Yay, welcome!

This article is for someone who is just getting into digital Product Management — especially folks who haven’t worked on an agile tech team before.

I wrote this based on my own experience: I’ve worked on digital products (web/mobile) in both government and private sector. I’ve also worked across many roles in tech: product manager, UX researcher, frontend engineer, and engineering manager.

What I Wish I Knew

I’ll cover the most common questions I get, some confusing language you’ll have to learn to work with, and a lot about managing your own expectations of yourself. Including:

• Where do PMs come from? What backgrounds?
• There are many different subtypes of PMs.
• Two big goals all PMs should have.
• There is a huge difference between Product Manager (PdM) and Project Manager (PjM).
• Not all PdMs are truly PdMs — many are treated as PjMs.
• How to keep sane as a PM (support!).
• What activities PMs actually do day to day.
• Product Discovery and other PM Skills.

Where do PMs come from?

In my experience, PMs come from roughly one of three backgrounds:

1. 1/3 come from a tech background (like software developer, etc)
2. 1/3 come from a management background (like an MBA program, etc)
3. 1/3 come from other fields/ backgrounds (education, etc)

And here are many awesome PMs from all of these backgrounds! There is no one best background.

Your background is like your “starting stats,” and you’ll skill up in these other areas with time.

Your background gives you unique advantages:

• Tech background folks bring more experience working with developers and technical limitations
• Management background folks bring more experience focusing on business value
• ”Other” background folks bring more experience from other domains, including more creative/lateral thinking, and bringing in best practices.

It can be hard to value your own advantages! Especially when you’re (naturally) very focused on what other people bring and what you “lack”. Try to focus on what you uniquely bring — your background, mindset, motivation, and potential.

Many Subtypes of PMs

You can’t have every skill maxed out! No PM has all the skills equally developed — nor should they. I find this concept very comforting: PMs specialize into subtypes.

How many types are there, and what are they? That depends on who you ask!

• The 6 Types of PM (my favorite one!)
• The 10 Types of PM
• The 4 Types of PM
• The 4 Types of PM (a different one)
• The 5 Types of PM
• The 8 Dimensions of a PM (PMwheel)

One thing everyone seems to agree on — the title “Product Manager” alone does NOT tell you what a given PM is truly responsible for. It varies!

Two Big Goals

Across these, there are two things that I believe are core to the PM role.

As a PM, you prioritize and motivate.

1. You are responsible for prioritizing (focusing on impact, etc, by bringing together many points of view)
2. You are responsible for aligning and motivating everyone (team members, stakeholders, etc)

PdM vs PjM

People do generally agree that a Product Manager (with a d) is NOT the same as a Project Manager (with a j). Not the same!

Whoever decided that we would have the same acronym (PM) for both of these roles has cast a curse upon us all. It is SO difficult to communicate about these thanks to this inconvenient acronym overlap.

Here are my simplified definitions:

• Product Manager (PdM)
  • Product Managers come up with what to do themselves (within an area of focus / shared vision)
  • Product Managers are responsible for making sure we do the right thing (prioritization)
  • Product Managers are responsible for outcomes (impact), not outputs (tasks).
• Project Manager (PjM)
  • Project Managers do what they’re told. They do their best to complete tasks by deadlines.
  • Project Managers are responsible for making sure we do the thing right (implementation)
  • Project Managers are responsible for outputs (tasks) not outcomes (impact).

I abbreviate these to PdM (product) and PjM (project). These two acronyms are not super widely used, but they’re useful! Once I define these in a conversation, everyone has a much clearer verbal “handle” to distinguish between the two roles.

Sometimes I still say “PM” — but only when I want to be intentionally ambiguous, like when I don’t know which one someone is. It’s like using the “ambiguous they” for someone when you don’t know what pronouns someone prefers (he, she or the increasingly common “specific they”).

When a PM isn’t a PM

This PdM vs PjM stuff is all ESPECIALLY confusing given one more wrench:

It can be hard to tell who’s who!

Over HALF of the “product managers” that I know are essentially project managers in their current role. The title and duties don’t match for them. The job title may be “Product Manager,” but the “duties as required” part of the job are entirely Project Management tasks. The company treats them as PjMs. Many of them have even internalized this as “how PMs are supposed to work.” And, at least in their context, that’s true!

Many PdMs in this awkward position try SO hard to be true PdMs — and yet they are thwarted. They are treated like PjMs by their company or leadership or peers etc — all while being told to BE a true PdM. Sometimes it’s even to the level of gaslighting. This is THE biggest, most common reason for PM burnout.

I believe this happens for two reasons:

1. It IS inherently confusing! PM and PM are two different things?? And some people are even somewhere in the middle, only partially empowered.
2. It is virtue signaling. The company wants to make a less attractive role (PjM) seem more attractive (PdM) and is willing to “pretend.” Weirdly, this might even benefit a “PdM” because people care about titles (but that’s another topic).

Project Management can be valuable — but different

I don’t mean to suggest that PjMs are worse than PdMs. PjMs can add a lot of value to teams! Having someone on the team do project management is helpful.

For example:

• On some teams one individual can successfully be both a PdM and a PjM
• On other teams the Tech Lead (lead developer) wears the PjM hat for the developer task backlog.

The problem is when someone has the title Product Manager but is then treated like a Project Manager, without the ability to prioritize things — and without being allowed (culturally) to delegate project management tasks.

This mismatch of title and expectations causes a ton of undue strife for Product Managers.

Are you treated as a PdM or PjM?

It is VERY important to figure out how your company treats your role. Are you an empowered PdM, or a disempowered PjM, or somewhere in the middle?

Some example scenarios to illustrate the levels of empowerment:

• Company A: Nobody in particular is responsible for strategy. A roadmap is given to the team by the CEO without much input. The PM is a PjM, just implementing the CEO’s vision as micromanaged by the CEO. (full disempowerment)
• Company B: The PM is empowered to come up with their own strategy, and they must also get the team to act on it. They are both PdM and PjM at the same time (alternating maybe). They are tired, and stretched thin. (partial empowerment).
• Company C: The PM is a true PdM, with the ability to prioritize what to work on (within the vision). They are allowed to delegate project management tasks to someone else: a Tech Lead or a junior “PM” who is effectively a PjM. (full empowerment)

In my experience, here’s the breakdown:

• MOST companies are fully disempowered, and they only hire PjMs
• MANY companies are partially empowered, where PdMs are also PjMs
• SOME companies are fully empowered, where the PdM can even delegate PjM tasks to others as appropriate

Product Managers love to quote Marty Cagan (author of the book Inspired) about “what a PdM should/shouldn’t do.” Company B here most closely resembles Cagan’s platonic ideal of a PdM.

I disagree that B is best — I’ve been on teams where PMs were forced to do certain PjM tasks instead of delegating them to a perfectly capabale Tech Lead. To me, C is the most empowered!

B might be a more realistic target, sure. Perhaps it’s more rare to find a team that works together this well as Company C. I’ve been fortunate.

In any case — we want empowered PMs! For your happiness AND for the company’s outcomes to be their most effective.

I hope you can find a company that really empowers you.

Sanity for PMs

You need peer support no matter what — but especially if you find yourself caught between PdM and PjM expectations pulling you apart. Here are some ways to find more support as a PM:

• Coworkers. Make time to talk with PM coworkers one on one (if you’re lucky enough to have some!)
• Community. Join local meetup groups (like DC Product and Pastries — or if you don’t have a local one, make one! I’ll even help, sharing organizing tips etc 🙂)
• Peers. Find some peers/mentors through your network. Check-in with them regularly. Many PMs want this sort of support!
• PM Coaching. If you don’t have mentorship from within your company (most people I know don’t!), get some! You can probably even get your company to pay for a PM coach. There are a bunch of us PM coaches out there (I’m one!).
• Independent Learning. Reading books, taking online courses, etc. These can all help you feel more grounded. It can be very comforting and grounding to hear about PMs facing similar isues to you.

The Trio

Another source of support is the “trio.” “The Trio” is a pattern on software development teams, these three people co-lead the team together:

• A tech lead (developer) focused on what’s feasible
• A product manager focused on business value
• A user experience researcher/designer focused on user value

As a PM you’ll (hopefully!) spend a lot of time with these peers. You can be a lot of support for each other. You each have some “pieces of the puzzle” we have to bring together to make the best decisions.

A Week in the Life

Okay okay, but what do PMs actually DO? In my experience, these sorts of things:

• definitely
  • planning with your “trio” (this is your “first team,” your most direct teammates)
  • coordinating with stakeholders and other teams (since you have the context)
  • explaining the “why” of the plan; incorporating feedback (to share/get context)
• hopefully
  • attending user/customer interviews (to get context)
  • weekly scrum ceremonies like stand-ups, retros, etc. (to get context)
  • supporting the team (especially developers) as needed (since you have the context)
• maybe
  • writing “stories” which are programming tasks (but other people could do this instead)
• hopefully not
  • management of direct reports (a misconception that “manager” means you should manage people. This is a very different kind of managing!)

Agile Ceremonies

Many new PMs ask me about agile ceremonies as their first questions — as if that’s the core of their job. On the one hand it makes sense to be curious about something unfamiliar like these ceremonies. On the other hand, it shouldn’t be one of the PM’s main jobs to run meetings.

So many companies fall into the pitfall of assigning all meeting-running duties to the person with “manager” in their title. “A manager is a manager!”

To me, that is an anti-pattern.

Agile ceremonies can be done by anyone! Anyone can run standup. Anyone can run a retrospective. Anyone can share-out progress/updates. And many people are interested in this even.

And it can even be good experience for people too. It would be rude to deprive others of learning/growth potential.

I hope you are allowed to delegate things as appropriate for your team. Or if not, I hope that these social expectations are at least clearly communicated to you.

PdM Skills

Here are a few of my favorite places to learn more:

• Book Lean UX — an adaptation of The Lean Startup focused on technology companies. When I read this it was “boring” to me because it was everything I was already doing — which means it’s a great book for new PMs! It’s the things I find myself doing a lot
• Book Inspired — This is the #1 most recommended product management book. Even though I agree with a lot of it, something about the tone really irritates me. I still do recommend it!
• Tools Websites — My favorite is PD Methods by NYTimes, it has a great description of all of the common techniques I use. Another I like is more general-purpose Untools.co, which has some that PD Methods is missing. One more: when I worked in government, I often referenced 18F Methods (so I could say “other parts of the government do this! see!“)
• PM Influencers — Product Management is still so new that a lot of concepts haven’t gelled into terminology yet. Sometimes these “PM Influencers” coin terms or come up with great visualizations for things. Three of my favorites: John Cutler (blog posts), Shreyas Doshi (twitter), and Jason Knight (podcast)
• Peers — learn from your peers! Start a community of practice at your work, or join a local community group, or an online community.

Product Discovery

There are a ton of named skills PMs use in the resources above. (Many PMs don’t know the names and that’s okay too!).

One high-level idea I want to call out in particular: Product Discovery.

Product Discovery is the process of figuring out what users truly need, beyond what they say. This is especially powerful when you focus on figuring it out early, quickly, and cheaply — instead of waiting 12 months to learn what they DON’T want. 12 months of software development is so expensive!!

This involves spending time in BOTH the problem space AND the solution space. Many teams skip the problem space and go straight to the solution space. Here’s how I draw it:

This diagram is inspried by the double diamonds diagram from Stanford d.school’s “Design Thinking” model. I often reference the one on the front page of PDMethods, it’s very close.

It is your job as a PdM to make sure the team doesn’t skip product discovery, especially the problem space.

Thank-yous

Thank you Dana Lee for “reverse interviewing” this article out of my head, helping me get all of this into a coherent narrative.

Thank you to my PM friends who reviewed this article, too! This post is much stronger and clearer thanks to your feedback 👏🏻

• Dan Rinzel
• Christoph Steinlehner
• Hellen Kozel

You can do it!

I may not know you, but I bet you’ll be great as a PM! I believe in you 🙂

Especially if you can keep the right headspace for this role. Think clearly, communicate clearly, find support, and motivate others.