We tend to think of PMs as jacks of all trades… of great product idea people… of having constant meetings and never-ending to-do lists. And yeah… ok so that’s true… but that’s not the most important part of the job.  Even if you’re starting off as a PM and you know all the things you’re supposed to do, you still might be overwhelmed by the sheer volume. How do you know how to prioritize all of these things that seem equally important? It’s a lot.

But, it’s actually pretty simple if you pare it down to the basic things you, as a PM, should be doing.

1. Know your Customer

2. Motivate & Inspire your Team

3. Empower your Team

4. Remove Obstacles for your Team

5. Know your Customer

Know Your Customer

I’m not going to spend a lot of time here. That doesn’t mean, however, that you shouldn’t spend a lot of time doing this.

You must talk to customers.

When you’re talking about a problem you’re trying to solve to, well, pretty much anyone, you should be able to name the humans you’ve spoken to that have experienced that problem. Without any prep. You should be able to say, “Oh, yeah I was just talking about this exact problem with Hillary from [famous person’s] team!” or, “Wes described his experience with [feature y] last week on the forums.”

Good politicians do this all the time. Candidates are always talking about [insert first name] from [insert city or state] and their challenges. They use these stories to show that they are in touch with real people and real problems. They use these stories to inspire their teams to help them canvas. These constituent stories are nothing more that customer stories. You, as a PM, should talk about your customer stories just as effortlessly as a candidate running for office.

Motivate & Inspire Your Team

All good PMs should be systematically trying to work themselves out of a job.

Seriously. Great PMs should use every moment as an opportunity to inspire their team. They should be so passionate about the problem their team needs to solve that the team cannot help but care about the problem. The motivation should spread like a god-damned virus. You should hear engineers talking to each other in the hallways about the problems your users are facing.

What do you think the productivity differential is between an engineer who cares about the problem they’re solving and an engineer that is simply writing code to a spec?

I don’t know and, to be honest, I don’t particularly care, because it’s enough for me that humans are enjoying their jobs. Then again we’re PMs, and no matter how human-focused we want to be, at the end of the day there is a company who needs us to get shit done. It’s a rhetorical question. Obviously motivated engineers are way better for a company, as long as you do not exploit that motivation*.

*An aside about Caring and Exploitation

That last bit is important. You want your engineers to be productive while they’re coding… you don’t necessarily want them coding more or for longer hours. And if you find that that’s happening, go stop it. In general, your engineers are probably only coding for maybe 3 hours a day (depending on the day). You should NOT see engineers coding all day every day, because they should also be doing all of this:

• Thinking deeply about the problem they’ve solving

• Thinking deeply about technical design

• Doing code reviews

• Interviewing to help your company grow

• Cross-pollinating with other engineering teams

• Pairing with other engineers

• Taking a walk or grabbing a coffee to let their brains marinate

• Prioritizing technical debt

• Testing the stuff they build

• Shit I don’t know… I’m not an engineer. But like… they’ve got stuff to do. Respect it and Get out of their way.

Anyway. Thou shalt not exploit caring.

Empower Your Team

Over time, your product-engineering team will develop its own ability to practically PM itself. A team that works together consistently over time on particular problem spaces builds up domain knowledge in those areas.

• Teams become more familiar with the code base for the product areas they work on

• Teams begin to see and understand trends in the problems they solve for their users

• Teams experience user feedback to the products they ship

A team like this has hit their stride, and all of that “slowing down” from being a part of the solution process is paying off. A PM for an empowered team will still prioritize problems and present those problems. But when it comes to defining a solution, they will simply become a resource.

An empowered team doesn’t even need a PM in the room to work on a solution.

The engineers and designers know enough and have enough experience in the domain to make a kickass product.

Remove Obstacles for Your Team

So you’ve lead a team and they’re empowered and cranking out wonderful products. Don’t get too complacent, because your job has now shifted. Your primary responsibilities are:

1. Unblock your team

2. Continue talking to customers

3. Continue iterating on the long-term vision

4. Unblock your damned team

Occasionally you may onboard a new face to your team, and during some dark times you may still need to inspire or give a pep talk or two. Your main, day-to-day responsibilities, however, will mostly be making sure the train stays on the rails.

Often PMs are inundated with emails or Slack notifications or whatever the current hotness in productivity is. No matter the tool, prioritize your inbox/notifications/whatever to focus on unblocking your teams first. Is there a comment or question on a JIRA story or github PR? First order of business. Do all the support tickets assigned to your team have appropriate replication steps? Is there a backlog of at least two weeks’ worth of stories written and prepped?

Unblock your team first thing in the morning before you do anything else.

That’s your mission. Choose to accept it.

That’s it. That’s the job. Know your customer, inspire your team, empower your team, then get (everything) out of their way.

Glamorous? Nah. Satisfying to sit back and watch the team do its thing? You’re god-damned right.