What is the job?
A better job description for product people.
The job description
What is the job of doing product? After last week’s intro, it’s time to get into the heart of the matter.
The answer isn’t as obvious as you expect. Newbie tend to struggle bridging the gap between a job description and real life. And veteran PMs easily fall into old routines that keep them from seriously addressing the fundamental question of “what should I spend my time on?”.
Many job descriptions will list out the rituals you’ll need to perform (I’ve pulled these from live job listings):
You understand the motions that Product Managers must go through when bringing a feature from idea to completion, e.g. grooming & prioritizing a backlog, writing product requirements, preparing work for sprint planning, attending the team standup, etc
Other times they say fuzzy things like:
Be the voice of the customer
Create an inspiring product vision
Act as the connective tissue of the organization
None of these points are inaccurate, but they often train PMs to overweight the importance of activities and process. This thinking turns PMs into project managers or scrum masters instead of nimble, entrepreneurial movers and shakers. Those functions are absolutely critical, but often get mistaken for the job itself.
Hey, that wasn’t in the description!
Another danger of sticking to detailed activity descriptions is that they are inevitably incomplete. If you focus solely on the activities you’re asked to perform (e.g. running metrics, writing tickets) you will inherently miss all the important other stuff that will fall through the cracks.
In their first few releases, PMs tend to miss some key steps. These are the responsibilities that you don’t know you have until you’ve screwed them up. Or they arise at the last minute without any prior consideration, creating a fire drill. Here is a short list of commonly skipped steps:
Stating clear targets before a project starts.
Looping in the marketing team to determine who the audience is, what the value prop is, and how you’ll deliver it to that audience, well before the development is underway. “We have this feature coming out next week” is not a good way to start the go to market conversation.
Setting up pre-defined ways that can report on those goals the second the product launches, and not a week later.
QA’ing the crap out of the feature. In addition to the simple test cases, have you actually tried to use the feature the way a new user will? With no backstory on how and why it was designed the way it was?
Understanding whether the thing you want to ship - which may be a simple ui tweak - will create new problems, increase support tickets, or challenge your ability to run the business.
Clearing plans with legal, logistics, finance or other key parties. This is critical if you are dealing in the movement of money or physical goods.
A simple purpose
This job is complex. There is always a laundry list of things you need to be doing, including all those bullet points above. But without a cohesive purpose, they tend to result in busyness. Or worse, feeling like you are drowning (busyness without going anywhere).
One way to understand your scope is to widen and simplify the job description.
Here’s one excerpt I found that actually describes the job:
Whatever it takes to keep your product team shipping and successful
Putting it into practice
Rather than thinking in terms of day to day responsibilities, you can use whatever it takes to increase your team’s ability to execute. Here are some strategies that will get you thinking along these lines and ensure any project’s success:
Create a (simple) plan
List out all the things that you think need to be done to complete the project on day 1. It’s totally fine to keep a list of possible concerns to tick away once you’ve confirmed they aren’t necessary. You may have an item like: confirm whether we need to make changes to our privacy policy to support this. If the answer is “no, we don’t” cross it off and keep going. This is a muscle you’ll build over time and soon you’ll have a mental template (better yet - create a digital one) that you can rely on repeatedly.
Spend at least half your time on rollout
In your plan, prioritize go to market and how you’ll deliver the product to users. This includes marketing strategy, sales education, training, and all the downstream activities that will make the product successful. Remember that the core “product” work (designing and shipping) is only a small sliver of the team’s success.
Communicate constantly
Share project documents with stakeholders while the designers and developers are still exploring their own solutions. Maintain active relationships and conversations with all the people that need to be involved in some way or another. There is no harm in oversharing or having a quick sync where “we’re good, I’m up to speed and can do what you need me to do on time” is the result. You’ll find that there is always something to be clarified and re-clarified as the project starts to breathe.
Prioritize unblocking work
The ratio of PMs to engineers or other team members is very low. In many cases you’ll be more productive simply by clearing the way for work to proceed than in working on non-blocking items. This includes clarifying key vs. edge cases, core user segments, and what needs to be done now vs. later. Set up times and systems to address open questions before getting into your “personal” work.
So who actually does what?
The actual technical work in your project (testing, writing copy, running ad campaigns) needs to be performed by someone. Depending on the size and maturity of your org, you will need to understand whether you need to run these tasks yourself or partner with other resources to get them done.
On one end of the spectrum: You are a sole PM with no dedicated designers, product marketers, QA testers, ops support, etc.
On the other end: you have dedicated departments to work with and have these roles embedded in your feature team.
The most common case is somewhere between those two extremes - maybe you have a proper designer but no QA resource. Or you may have a product marketer that works with several feature teams.
Your job is to tie all those pieces together into a cohesive whole. You will need to dive in and out of these different roles and keep the whole thing moving, whether you actually perform the duties or not. A large part of leading a collaborative effort is making all the parts of the clock tick smoothly and in rhythm, even if you are acting as most of those parts.
When you do have resources available, you’ll need to learn to delegate properly. The first attempt of this usually has a PM assigning a ton of tasks to other groups and then checking in weeks later to see what happened. This is abdication. A more mature approach requires collaboration. You’ll need working syncs with team members to figure out the best way to handle the work, with a two way give and take. A rule of thumb is that you should never expect someone involved in the problem to “go quiet” for a few weeks and suddenly deliver the task in question. The same goes for your work.
Expanding
To re-state: your role as a product person is everything. While that doesn’t mean you will necessarily do everything, you need to start thinking this way. When people talk about the cross-functional or multi-disciplinary work of product this is what they mean. Once you start envisioning product work holistically, you’ll naturally learn to see things from more angles. It may take time, but each thing you ship will add a new layer of depth to this view.
Roadmap
This post mostly describes the tactical work you’ll need to be doing in product. For younger PMs, this is the core of the job. As you grow in scope and level, you’ll need to focus more on strategy and higher level thinking. We’ll get into those topics in future installments.
Other requested topics I’ll cover in the next few weeks are:
Setting and using metrics
Staying organized (my personal favorite)
Thinking like an owner