Through numerous conversations, I’ve found product management to be an area that confuses people. So this blog post (and probably the few following it) will be an attempt to shine more light onto product management. Think of it as Product Management 101.

So the first lesson is on “What does a product manager actually do?”

There are a few different answers floating around. A popular one is:

The product manager decides what to build (while the engineering team decides how to build it).

While I like this definition, it’s a bit too simple. I like it because the PM does decide what to build. But it’s too simple because it implies that the PM is at arms length from the engineers (which is outdated).

The essence of product management is to prioritize

I would say that the heart of what a product manager does is prioritize. A product manager does a lot of very different tasks and draws on a lot of different skills. But ultimately all of that feeds into what does the team design and build next? Do we fix that bug? Do we tweak that feature? Or do we launch a whole new feature?

Once you strip away all of the noise, the product manager fundamentally decides what’s next. This might be on a grand scale, i.e. over the course of the year. But it’s actually just as important that they do it on a micro scale, i.e. every day.

Product management is a multi-functional field

Saying that the essence of product management is prioritization makes it sound easy. It isn’t. It’s not a matter of sitting around and putting a list of 20 items in a sequence.

To do that prioritization well, a product manager should be pretty good at understanding a number of key inputs:

• Commercial strategy
• Analytics
• Design – user experience, graphic, aesthetic, etc.
• Technical knowledge
• User research
• Sales and marketing
• Operations
• Talents and skills of individual team members
• Project and process management

In other words, what makes prioritization so hard is that the PM has to constantly compare apples and oranges (or more like bowls of mixed fruit) and decide which of them should be done next.

Is fixing a bug that only affects the single biggest customer more urgent than a feature that improves the long-term retention rate by 3%? Are there other ways that we can break down this work, so the choice doesn’t have to be so stark? Is the first iteration of the design good enough or should you delay the next piece of work to do another iteration?

You don’t have to be good at all of it

Too often PMs are used in organizations as glorified project managers, order takers or cost-benefit analysts. That’s a terrible misuse of the PM role. A PM’s skill set should be more diverse than that.

A good PM needs to be able to hold their own in each of the above disciplines. They won’t be the good at all of them. They’ll be great at couple, good at a few and just passably decent in the rest. But the point is that even in the areas that they just pass, they’ll know enough to ask the right questions.

What about vision?

Some might say that the PM should be the guardian of the vision, that inspiration for building what we build, the guiding light. I think a PM could be the guardian of the vision, but it’s not a necessary part of their job. When I think about startups, the CEO or founders will often be the guardian of the vision. The PM should understand it. But they don’t need to own it if someone else does.

---

GS Dun is a product management consultancy. How to build ’em. How to grow ’em. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

The next time you’re in a meeting where someone is throwing out some seemingly spurious results, try our hack-y AB test calculator, cakeAB. Mobile friendly, just punch in the numbers and get a steer on whether there really is a difference between those 2 campaigns. www.cakeab.com