The day-to-day life of a PM is hard to pin down.
Specific roles, seniority levels, company type (consumer vs. enterprise) and myriad other variables drive significant variance.
But, there are many common themes that dictate most PMs daily workflows. In this post, we'll explore those common themes, illustrate them with example calendars and talk through how each of the key variance drivers can shift things this way or that.
Everything below is modeled after the schedule of an entry-level, individual contributor at a large tech company like Google, Facebook or Amazon. Let's jump in!
A helpful starting point is a PM's weekly schedule.
Since day-to-day variation is significant, zooming out to a weekly view provides insight into the ebb and flow of a PM day.
Below, you'll see a snapshot of a "typical" week. To help illustrate the cross-functional nature of the PM role, we've color coded the different types of activities.
Let's walk through each of them.
These are the tasks people associate most with the PM job. And in many ways, they're the fun part of the PM job.
Writing project requirement documents (PRDs), meeting with the engineering and marketing leads to set product direction, analyzing user data, planning the roadmap and meeting with execs all fall into this bucket.
While it's unlikely you'll do all those things in a given day, most PMs will have a healthy smattering of those across the course of any typical week.
Sample activity: Writing a PRD
You block off 3-hours on your calendar, go into "do-not-disturb" mode on your phone and sequester yourself in a small conference room to write a PRD for a feature you'd like to start building in the next sprint.
PMs work hand-in-hand with engineers - so the typical PM schedule will include a healthy amount of direct interaction.
Activities like daily stand-ups, engineering syncs, bug triaging, sprint planning and overall roadmap planning will involve your engineering counterparts in some fashion.
For many PMs, a daily stand-up will be a key part of their interaction with engineering where they keep a pulse on how things are progressing. But collaborating with engineering also involves lots of ad hoc, unscheduled check-ins on various topics. For example, an engineer might ask to chat for 5-minutes you about a point of clarification on a product spec or through various approaches to a problem.
Sample activity: Feature scoping
You, your engineering counterpart and the key engineer that will work on a particular feature will sit down for an 1-hour and hash out the technical approach to building this particular feature. There are two main approaches to consider and, ultimately, you'll have to make a call on which way to go based off the long term implications and product trade-offs.
Knowing your customers inside and out is critical and thus PMs often spend a decent amount of time trying to "get smart" on their users and potential users.
This includes things like 1-on-1 with customers, analyzing customer surveys, sitting in on user research sessions, reviewing customer support tickets and/or joining sales calls. In addition, if you're working with a salesforce that sells your product, you might be involved in helping train and educate them on the product.
The biggest driver in variance here is whether you're working on a consumer or enterprise product. If you're working on a consumer product, interaction with customers likely happens in user research sessions, survey reviews and occasional 1-on-1 feedback sessions to get anecdotal insight into how consumers use your product.
On the other hand, if you're in an enterprise role, this will likely manifest itself in terms of meetings with key customers to understand their needs and pain points, helping train sales and marketing teams on the product so they can effectively sell and potentially joining sales meetings for important clients.
Sample activity: sales call
You join the VP of Sales on 1-hour pitch call to an important new client. While you won't lead the meeting, you'll be expected to jump in and provide additional color on your product, answer client questions and instill confidence in the product itself.
Without the design team, the look and feel of the world's best products would be bleak.
As a PM, you'll spend a good chunk of time collaborating and iterating on designs and the type of work can run the gamut. For big projects, you might be working on an entire re-design of a sign-up flow or launch of a brand new product. For smaller projects, it might be akin to redesigning a single modal window or call to action.
Regardless of the scope, typical forms of interaction are things like design reviews and individual working sessions with designers who are translating ideas from PRDs into fully fleshed out mocks that the engineering teams will implement.
Sample activity: Mock review
By the end of the quarter, you'll be launching a 100% revamped sign-up flow for new users and the design team wants to show you the current iteration of the new mocks. While you're not an expert designer yourself, you'll weigh in with respect to your goals for the re-design: how should the sign-up feel, what pieces of info must be collected, etc.
Another common part of the PM schedule is interacting with the executive management. Depending on your perpspective, this might be anxiety inducing or exciting or both!
In many companies, a common medium for discussion will be some sort of product review meeting where executives are updated on progress, big launches, challenges and the upcoming roadmap.
But executive interaction isn't just limited to a meeting or two. It's not uncommon for execs to swing by your desk or shoot off an email to you with product questions, feature suggestions or feedback they'd like to see addressed. And, of course, if there is a critical fire drill going on you might find yourself getting lots of ad hoc executive interaction as you problem solve with your team and keep the execs updated on progress.
Sample activity: Product review session
You'll be presenting an update on your product to the VP of Product, who is your boss's boss. In the meeting, you'll present the key adoption and monetization metrics for your product, talk about big wins in the last 2-months and what the roadmap looks like moving forward. In addition, you'll likely get asked a lot of questions about a new competitor, so you'll make sure to have a slide that speaks to the strengths and weaknesses.
Finally, in any given week, a PM will have plenty of one-off meetings, fire drills and other company meetings that pop-up.
This might include things like lunches with people on your team (or others) to build relationships, ah hoc meetings about an urgent bug that was just found or recurring, non-team meetings like the company all-hands.
Sample activity: Company all-hands
You'll likely attend the all hands but find a seat at the back of the room where you can bring your laptop and plow through some of the emails / chats piling up in your inbox. It'd be easier to do this at your desk, but as a PM you believe it's important to stay current with everything going on at the company.
Of course, everything we spoke about above is for a "normal" PM week, to the extent that exists.
However, any PM will tell you that "normal" feels like an anomaly in this type of job. Many weeks won't look anything like the one we outlined above. Why? Well, a bunch of large-block items will periodically come up and suck up the majority of time in a given week. Here are a few examples:
Using the roadmap planning example, here's how that same PM's schedule might get adjusted in a week where he/she is focused on quarterly planning.
A few key things to point out: the vast majority of time is now dedicated to roadmap planning! In addition, you'll notice that a release happens Wednesday night, which shows you that even though the upcoming quarter needs to be planned, everything else is still moving ahead full speed. This is part of the reason why the PM job is so challenging, while the engineering team will largely be focused on getting that release out, the PM will have to help get the release out (bug triaging, testing, answering questions, coordinating with x-functional teams) and simultaneously drive the quarterly planning. In short: that's a tough week.
Finally, every PM role is different. As a result, the day-to-day calendars of PMs will reflect the different realities of the job.
While we can't cover every nuance, a few key vectors tend to drive a lot of the variance.
John Gronberg, a Director of Product at Okta, walks through a typical day in the life on a PM and contrasts some of the deltas between consumer and enterprise PM workflows.
As you can see from the schedules above, boredom is seldom a problem for product managers! In fact, usually the opposite is true: there is so much going on at any one time that PMs are just trying to catch their breath.
Finally, it's important to note that the weekly schedule of a PM illuminates a defining reality of the job: it's truly an inter-disciplinary role. A PM can't just sequester him/herself away and ruminate on product. They need to proactively act as the clearinghouse for the whole team, driving the product forward and leading the interaction with engineering, design, sales, marketing, operations and executives.
It can be exhausting but it's also exhilirating, especially when launch day rolls around and you see the positive impact your product has on customers.