A Day in the Life of an APM


Morning routines are important, and mine currently involves reading for half an hour before going on my morning run. Reading and running are exercise for my mind and body, and it’s satisfying getting them both out of the way early to avoid having to find time for them later.


I start my day around 10am. I’m on the east cost while the engineering team is in SF, so I have a couple relatively quiet hours before everyone else comes online.

The first thing I do is figure out what needs to happen today. I’ll reference the weekly goals I set for myself on Monday (2-3 high-level priorities to keep projects on track) and any tasks left over from the previous day that I didn’t finish. I’ll also take a quick look at Slack and email for urgent items that have come in while I was away. All of these tasks get added to my personal todo list (right now, just pen and paper), which forms the basis of my day.


By now, my “startup sequence” is usually complete, and I’ll get to work on the tasks I identified. Because uninterrupted focus time is so precious (especially for product managers), I try to keep Slack/email closed unless I need to find something specific.

This time is best spent writing (tickets, PRDs, slide decks, meeting notes), planning (thinking through what I need to do for a specific project), or making decisions (reviewing and giving feedback on designs, experiment results, development builds, prototypes, etc.).

If I’m lucky, this block extends all the way until …


Lunchtime! I’ve put a recurring event in my calendar so I don’t forget to eat, and so I eat at a fairly consistent time every day.

My calendar is open (meaning everyone can see the names of my events) so sometimes lunch gets scheduled over — no biggie, I can easily move it around to accommodate.

Cultures around open calendars differ from company to company and even people to people, but I prefer open calendars for the sole reason that it makes scheduling easier — some people’s calendars are cluttered with optional events that they don’t ever attend, but without seeing what the events are, it’s hard to know what can be scheduled over.


The rest of the company is online by now, so we have our daily standups for the iOS and Android teams (10am on the west coast). Standups are fairly standard events so I won’t go into them here.

The timing works well for everyone, since it frames the day for the engineering team, while I’ll have had time to review any messages that have come in since I signed off yesterday, so we’re all on the same page.


Afternoons are typically filled with meetings. After lunch, I shift my mindset from doing focused work to “being responsive.” That means attending meetings and responding quickly on Slack. Sometimes I can spend entire afternoons solely in Slack, discussing problems and making decisions with the broader team. That’s one of the advantages of remote-work — parallel conversations!

I typically have a 1:1 with someone every day, though I try to group them on Tuesday/Thursday so I can have more uninterrupted time on Monday/Wednesday. Some slip through though, since part of a product manager’s job is to operate on a manager’s schedule.

I have recurring 1:1s with fellow APMs, my manager, and basically everyone I work with (engineering managers, engineers on the team, fellow PMs working on adjacent projects). The conversation is typically a mix of personal chatting, which is great for building rapport and just bringing in some fun and humanity into the workplace, and discussing and reflecting on work matters. With the engineering team especially, it’s a great time to get insight on how the team is operating, and identify places where you can help out the team as the product manager.


Similar to 1:1s, there’s usually a “big group” meeting or two every day. These include team planning/retro/grooming, design reviews, and product team sync-ups.

These are usually an hour long, both because there’s more stuff to get through, and also because meetings with more people tend to have a lower information bandwidth than those with fewer people.

In the meta-spirit of product management, the product organization I’m a part of is always experimenting with meeting formats, frequencies, and topics to optimize for the best blend of meeting length and information sharing.


Another type of meeting! A lot of the time my todo-list is filled with decisions I have to make or plans that need to be formed. I’m not always the most qualified person to make these decisions, so I’ll call a one-off, specifically purposed meeting with the relevant stakeholders.

These topics range wildly. Some recent meetings I’ve had include:

  • Planning for how to run an experiment that needs to be coordinated across two different infrastructures
  • A post-mortum on a recent incident
  • Aligning roadmaps with a partner PM and establishing buy-in on shared tasks that our teams can collaborate on
  • Re-working a feature with an engineer to make tradeoffs in light of unexpected technical challenges

In these meetings, my role is often primarily in the setup. My responsibility is to identify the right group of people and share the context ahead of time so everyone knows what the meeting is for. When the meeting actually starts, I give a quick intro, then get out of the way and focus on taking notes, nudging the conversation along and providing product input when necessary. Product managers aren’t expected to personally solve every problem; your job is to make sure every problem is solved, and sometimes that means finding the right people to handle the problem.


Sometimes my meeting schedule stretches on until I sign off for the day, but when I’m lucky, I’ll have some time in the afternoon where I can knock out some smaller tasks, such as:

  • Finishing documents I was working on in the morning
  • Mechanical tasks, like checking on experiments, sending out meeting notes, and scheduling followup meetings
  • Responding to more Slack messages to help unblock issues that have arisen throughout the day


I sign off at 6pm for dinner, then work on personal tasks, like writing for PMTL 🙂

Inspiration for this post comes for Slack’s series of “A Day In The Life Of …” posts from their engineering blog. Check them out!


I put together a 9-part course on algorithms designed for non-technical readers that's a great, gentle introduction to thinking like a programmer. Get the course for only $5, or download the first chapter.