Four things every Product Manager does

Recently I was chatting with a new PM who’d just joined my Facebook. Six weeks in, she felt she was struggling. 

PM at FB isn’t like PM at some other companies. We don’t fully ‘own’ the roadmap (in the sense of having fiat control over it). We don’t always run planning sessions and retrospectives (tech leads, designers and researchers are often amazing at these set pieces). We don’t always set the goals (our data science colleagues are often best placed to concoct metrics that are the best proxies to the outcomes we want).

So, she asked, what does a PM do here?

1. Identify the most important problems.

There are many problems; large or small, pervasive or niche. The critical word here is “important”. Not all problems are worth solving – by which I mean the effort expended in solving them isn’t worth the payoff of doing so (dependent, of course, on how your organisation/business values that payoff).

In the common case that there are several problems worth solving, the PM’s role is to understand and articulate the relative value of these problems such that the team can prioritise them and focus on the most important things.

This generally means synthesising input from many sources: data, research, customer feedback, market news and moves, industry trends, and, yes, one’s own experience. Then using these inputs to make a compelling argument as to how the team should spend their time…

2. Get people excited about solving those problems.

When people understand the context of what they’re working on, how this creates value for people/customers, and how they themselves can affect said change: they’re going to do better work. 

After deeply understanding the problem space, good PMs are able to infect their team with this information, and create interest and excitement around building solutions; creating value for customers and the business in the process.

Tech teams (engineers, designers et al) are a rightly skeptical constituency. Convincing them that this (whatever it is) should be the focus of their working/waking moments for the next weeks/months/years is non-trivial.

PMs need to be able to present a compelling case using a range of persuasive tactics: selling a vision, compiling data, sharing examples from customers, illuminating the RoI — and do so using a number of techniques: a formal presentation, in 1:1 or small-group conversations, in team meetings, over dinner or in the pub.

To understand the importance of this, consider a counter scenario where a team has been told to focus on something they don’t understand, or don’t see the value of. In this situation, every distraction is enticing, every decision an opportunity to prevaricate. The team is less likely to succeed.

Put simply, a good PM will create a well-lit-path toward success that a team naturally want to follow.

3. Help people organise around solving those problems.

OK cool, you’ve identified a problem worth solving, and got people excited about solving it. Without this next step, the team may career off in different directions, ship features and code that don’t work together, and not solve the problem at all.

As the PM, your job is to help break the problem down into it’s constituent parts so the team can 

You might divide the problem into streams that can be tackled in parallel. You might define milestones which represent the meaningful moments on the progress to solving the problem. You might build charts that track the team’s progress (I don’t meant burn-down charts – they only track the team’s motion, not their progress).

4. Anticipate and remove blockers

This is the least glamorous but arguably the most important operational function a PM performs. Blockers are anything that might get in the way of the team’s smooth execution. It might be working with legal/privacy/policy to ensure what you’re building is safe for the world to see and use. It might be ensuring your support/operations teams know what’s about to ship so they can handle customer questions. It might be framing up the teams work to their leadership so as to preserve and extend the product team’s mandate to exist. 

In short, it means doing whatever it takes to maximise the probability of the product’s success in the market.

And the rest.

Those aren’t the only functions a PM can or does perform, but in my experience, they’re at the root of why PMs exist and how they help teams succeed.

Leave a Reply

%d bloggers like this: