Day in the life of a product manager

Day in the life of a product manager was originally published on RocketBlocks.

Day in the life of a product manager

Kenton Kivestu, ex-Google, ex-BCG, Founder at RocketBlocksUpdated: June 15, 2022

A day in the life of a product manager is 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!

Product manager daily routine

Since the daily routine of a product managers can cover a wide spectrum of activities like writing specs, working with the engineering and design teams, or interacting with customers, the best way to think about the breakdown of tasks is zooming out to a weekly view like below.

Typical weekly calendar of a product manager

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.

PM task types:

  • Blue: core product activities (e.g., writing specs/PRDs or tickets)
  • Orange: interacting with customers or customer-facing teams
  • Green: working with engineering (e.g., stand-ups)
  • Purple: collaborating with the design team (e.g., reviewing wireframes)
  • Red: updating executives (e.g., product reviews)
  • Grey: other misc meetings (e.g., weekly all-hands)

Let’s walk through each of them.

Core product activities

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.

Working with engineering

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.

Interfacing with customers

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.

Collaborating with design

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.

Updating executives

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.

PM tasks that shake things up

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:

  • Production issue: a major production bug is discovered that becomes a priority zero for you and team to resolve.
  • User research / customer meetings: you spend the majority of the week in customer interviews, research sessions or on the road at sales meetings
  • Industry conferences: you attend an industry conference (or maybe participate or speak at one) that ties you up in travel and meetings for the week
  • Roadmap planning: you spend the bulk of week brainstorming, prioritizing and finalizing the roadmap for the upcoming quarter

Atypical calendar: quarterly planning week

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.

Variance in PM workflow

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.

  • Consumer vs. enterprise: Enterprise PMs tend to spend more time interacting directly with major customers while consumer PMs are more likely to rely on insights from customer support tickets, anecdotal one-off discussions with users and analysis of user data.
  • Product lifecycle: PMs for mature products tend to allocate more time to analysis of existing users and engagement data to understand what to build next. On the flip side, PMs for early or new products might spend the bulk of their time working with engineering to build the product or figuring out distribution.
  • Seniority: More junior PMs will spend more time bug triaging, writing PRDs and focusing on core product activities. The more senior a PM becomes, the more time gets allocated to cross-team coordination and managing PMs doing core work.


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.

BackNext: PM interviews