What’s a Senior Product Manager’s job?

I found myself inspired recently after reading another outstanding blog post by Julia Evans titled “What’s a Senior Engineer’s job?” If you’re not reading Julia’s blog yet, then… what are you doing? Go open a new tab and check her out. Her blog has really taught me a lot about how software engineers work, and that post above is just one of many examples.

It got me thinking about the natural counterpart on our side – what, exactly, is a Senior Product Manager’s job? In many ways, the Product Management role is much more amorphous than Engineering is, which leads a lot of people to be confused about what they “should” be doing. In that spirit, I’m going to take a crack at this question for folks in our world.

A disclaimer is in order here – as Ben and I say in the introduction to our book, there is no “one true way” to do Product Management. I certainly think some approaches work better in one context or another (such as consumer vs. enterprise, small/large market segments, and so on), but it’s rare that you’ll see a good and senior Product Manager insist that some practice is just utterly, completely wrong and bad in all cases, everywhere. Given that my experience is in enterprise software, my views below are obviously going to be biased in that direction.

In any case, I’m still learning stuff about Product Management all the time, and as always, reserve the right to change my mind at any time.

That said, in my view, here are some of the most important things Senior Product Managers do:

  • Make the product more valuable. Product Managers need to understand, in Clay Christensen’s words, “what problem your customer is hiring your product to solve.” Knowing this, it is Product’s job to strengthen that value proposition over time. Sometimes, customers will tell you exactly how to do this, and other times, they won’t.
    • What this means: coming up with and prioritizing the right features, enhancements, upgrades or whole new products that your team should build. Owning the product development process and roadmap.
  • Understand your product’s users and customers. This is closely related to the point above. Everyone should understand one of these stakeholders, of course (Design, Marketing and Sales especially), but Product needs to understand them both, and how they relate to one another. You need to understand what your users and customers’ jobs (or lives) are like, and how your product fits into them.
    • What this means: customer visits, product usage reviews and lots of market research. Sharing this “customer knowledge” widely within the organization.
  • Be the advocate for the product. In every organization, different business functions are going to lean towards serving their own ends. Sales wants to sell more stuff, Engineering wants perfection and to make things complicated, Marketing wants to say that your product can spin straw into gold. This is all fine and proper – they’re just doing their job! But over-indexing on any of these things is not a long-term strategy for a strong product, let alone a successful business. Keeping them in balance is Product’s job.
    • What this means: when internal decisions are being made about resourcing, scheduling, roadmap or product strategy, it’s the Senior Product Manager’s job to be present and advocate for the product, not a company-specific parochial interest.
  • Evangelization. No one is a better bringer of the good news about your Product (😄) than the PM. By “evangelization,” what I really mean is explaining what your product is and why it’s valuable. This is related, but distinct, from your standard product marketing in the sense that it’s more explanatory than pitch-y. For this reason, evangelization can be incredibly important internally as well as externally, especially if you work in a bigger company. If you explain why your product is so great to just 10 people inside your company, each of whom are then equipped to do the same to 10 others, you’ve just scaled your message dramatically.
    • What this means: Prepare demos. Walk-thrus. Beginners’ Guides. Connect with relevant communities for your product outside the company.
  • Most everything that falls through the cracks. A thing about PM is that we’re often batting cleanup for other teams. Nothing is “beneath” the Senior PM, and if needs getting done, then – tag, you’re it! That said, if you find that you’re running into too much of this “other stuff” on a regular basis, that might be a signal to re-evaluate how your team is working together and routing tasks.

This is a short list, but I think it effectively encompasses a lot of what a Senior Product Manager does.

Something that I did not include here, which you usually see on lists like this, is “Define the product vision.” That “Vision stuff” is important, of course, but in my opinion, it gets way too much attention in a lot of PM reads like this. “Defining the product vision” is to Product Management what “create a strategy to win the World Series” is to a baseball team. That is to say – it’s really important! Perhaps it’s even foundational. But what actually wins games is steady, disciplined execution of a plan – not a vision. No one cares about your Big Vision on Tuesday at 3PM, any more than a baseball team cares about the 162-game strategy in the bottom of the 3rd inning of Game 41 with two outs remaining and a guy on second.

I’ll take Planning over Vision, and Execution over Strategy, seven days a week, with a double helping on Sunday.

It’s a little trickier to provide a list of what is not a Senior Product Manager’s job, particularly given that “batting cleanup” role. But here’s my attempt:

  • Being the final arbiter of product strategy. Usually, this is frankly above your pay grade. Senior PMs should certainly have opinions on product strategy, and share them liberally with your leadership. But generally, at least on medium-to-large questions of product strategy, Senior PMs are advisors, not deciders. This is a role where you can learn to help craft broader strategy, but for the most part, are executing on a strategy directed by others.
  • Project management. I’ve seen a lot of companies that hire people with the title Product Manager and then put them in jobs that more closely resemble Project Management. The difference is between deciding “what to do and why” versus “how to do it and when.” Often, especially in small companies, project management may default to Product Managers to cover, which is fine – as long as it doesn’t become the whole job itself. If what your team really needs is a Project Manager, then just hire one. The Senior Product Manager isn’t the scrum master.
  • Product marketing. The reality is that lots of Product Managers wind up being their own Product Marketer, too. Everyone creates some collateral from time to time. But if more and more of your time is being eaten up creating marketing materials, then some pushback is necessary (and you should probably just hire a marketer).
  • Writing code. With few exceptions (mostly for platform/infrastructure roles), most Product Managers shouldn’t be touching code. I don’t care if you used to be an engineer. I find that the PMs most eager to contribute code to their own product are trying to prove themselves to their engineering counterparts (often in a macho way).
  • Stuff that managers do. Perhaps, as a Senior Product Manager, you are also a manager of people, in which case, this does not apply. But assuming not, I think the following things are more “manager” responsibilities:
    • Leading 1:1s and team meetings
    • Standing status meetings with many different teams. Very selectively, these might be appropriate in some situations. But they very easily metastasize into time-wasters.
    • Regular evaluations or organizing others’ work.

What this looks like

In writing this post, I popped open my work email/calendar and thought about what a fairly typical day for me looks like:

  • First thing: scan overnight emails from overseas teams. Some Japanese customers are in cycles with our professional services team and have questions about how something should work, and a seller in Finland has a one-off RFP question that she couldn’t answer. I send off responses.
  • There are a couple of outstanding defects that need my attention. I prioritize them for resolution (high/medium/low) and add my comments about what PM’s expectations are to each ticket.
  • Morning team meeting.
  • There’s a customer migrating from one software version to another, and their project manager has questions about an element of “v2” that they should expect. The email chain is getting too long, so I just call him up and we chat.
  • Story planning. Our next sprint planning meeting isn’t until next week, but there are a few stories I really want to get in, and they’re not fully documented yet. I update them with details about what we need and then tap some colleagues in UX for their input.
  • A colleague has written a new public blog post about a customer case study of use of our platform and wants PM’s input. I read it, contribute comments and some ideas. It’s really good.
  • Engineering has come back with some new commentary on some of those defects. I decide that I don’t really understand one of them, so I go find the supporting engineer and ask him to explain it to me. Turns out, it’s not really that tricky after all.
  • A seller sends me a blank RFP with a note that he really needs to submit this in two days, and can I please fill it out for him. Restraining an eye roll, I immediately reply no, I cannot, but that he’s free to peruse the RFP library we maintain and find the answers himself. I don’t hear back.
  • Another Product Manager has a story, which turns out to be three stories, that she needs my input on because they touch my product. We discuss them for awhile so that I understand what she needs, and then I go in and update them with my detail.
  • We have several customer communications that I’ve written going out soon. A few, Customer Success has follow-up clarifying questions about. Another one, I decide I want Engineering to weigh in on one point. I play gopher getting the right eyes on it first, and then approve its transmission.

This is a highly incomplete list, but hopefully gives you a small “slice of life” of what a gig like this entails. You’ll notice that I wasn’t defining any visions anywhere – not in so many words, anyway. Come annual roadmap planning, we’ll spend some time revisiting that, but for now, I’m in execution mode, which is where any good Product Manager is >90% of their time.

There are a lot of fun parts about this job, but there’s also a lot of really rote block-and-tackle nitty-gritty stuff that’s more about good organization and clear communication than any sort of genius for “product.” After years doing this job, I’ve come to the conclusion that even if “product geniuses” really exist, I would still much prefer working with people who are just good, proven executors than “ideas people.” Too often, both in tech and broadly in society, it seems like ideas themselves are cherished as superior to bread-and-butter implementation of them. I think that’s a mistake.

But maybe that’s just because I’m not a “product visionary.” 😄

 

Related posts:

 

[mc4wp_form id=”185″]

Standard