“What is your typical day like?”
There is clearly no way to answer this question concisely while giving an accurate view into what is actually going on day-to-day. And that’s part of the fun!
Overall shape of a PM’s schedule
This will vary by industry, company, geography, team composition, team processes, etc. etc. But speaking in generalities, PMs probably have a decent amount of flexibility in their work schedules, in the sense that they can shape their hours and routines. It is very likely that others will put some pressures on your schedule: since the job is so dependent on working with others, a PM will be making scheduling compromises for meetings. But, she can also probably compensate for any unfortunate hours by cutting back at other times. The generally liberal work cultures at tech firms also helps with this.
Tech companies tend to have reasonable hours. The earlier-stage the company, the more likely that people will work longer hours, as there’s a greater sense of urgency in moving projects forward to survive. At the largest tech companies though, hours tend towards the typical 9-6 or 10-7 workdays, though again, flexibility in hours is a key selling point of the tech culture.
What is a PM doing all day?
One potentially useful framework for thinking about a PM’s day is to divide it up into three categories of activities:
- Reactionary, “short-burst” work
- More thoughtful, “long-stretch” work
Some joke that all a PM ever does is go to meetings. This is probably not far from the truth, especially the larger the company gets. Since a PM has to accomplish tasks through others, meetings become a key way to catch up, make sure people are (still?) aligned, resolve any open questions, and determine next steps that need to be set in motion.
There’s a whole range of meetings. There are the regularly scheduled ones, like weekly working team syncs, or biweekly 1-on-1s. These are meetings where people catch up on what they’ve been working on and what’s on their minds. The PM might loosely determine what gets discussed during these meetings, but they’re usually more collaborative, and a chance for others to bring questions or topics to the PM’s attention. There will be some recurring topics of discussion around regular sync meetings: how often to have them, what the right types of agenda items are, and how to effectively capture any action items (“AIs”).
There are also the periodic meetings for larger teams. These might be meetings where leaders of the team (the PM being one of them) present on projects or topics that are ongoing, so that everyone is caught up with the latest developments, and feels more bought into their work. If the PM is running one of these meetings, he is probably making a slightly more formal presentation, and needs to think about what and how to communicate.
And then there are the one-off meetings. These are scheduled as needed, and since the PM is the one who is trying to move projects forward whatever it takes, she is probably the one scheduling a lot of these one-off meetings. Sometimes the meeting is for resolving a small roadblock for one of the parties. Others of these are fact-finding missions, where the PM tries to learn more about a certain topic or situation. It’s amazing what can be learned and accomplished in a quick 30 minute face-to-face meeting, especially when the PM goes into it knowing what she wants.
Many tasks of a PM are rather reactionary or fairly “burst”y in nature – they are relatively small tasks that can be accomplished with a quick action. The challenge here is not so much doing any individual one of these tasks, but rather remembering what needs to be done and sustaining endurance while trying to work through a long list of these tasks.
It’s hard to understate how much of a PM’s job is dependent on email. (Some tech companies, especially startups, use Slack instead of email, but the effect for a PM is similar.) A PM will be getting a lot of emails of all kinds – status updates, questions about specs, requests for information, etc. A PM will also be sending a lot of emails to try to make progress on tasks. There is generally an art to figuring out what you need to reply to, when to send that reply, and how much detail to get into in an email. And though its asynchronous nature makes it very tempting to try to resolve everything over email, talking face-to-face about a topic of any slight complexity is probably more efficient.
Most PMs would consider that there’s an “SLA” (Service Level Agreement, or maximum time it takes to turnaround something) for their responses to emails. Emails vary in terms of importance and complexity, but in general PMs seem to respond to the average email within a business day.
Other than email, there could be a number of smaller tasks that fall into this bucket as well. These are generally parts of processes that fall to the PM, things like updating project management trackers, providing sign-off on something, scheduling meetings, or even organizing something fun for team bonding (yes, as a PM, you might be running out to buy cupcakes for your team celebrations).
All in all, no individual activity in this bucket likely takes up that much time, but in aggregate they really do fill in most of the cracks between scheduled meetings.
PMs generally complain that they don’t have long enough chunks of time to tackle this kind of work. This bucket is where we see some of the more prominent and clear “outputs” that a PM could produce.
One example of a “long-stretch” task might be to write the spec for a feature. A spec is a long(-ish) document that describes a feature. It could contain information ranging from why the feature is desirable, to descriptions of what the feature does, to plans around the rollout of the feature and beyond. These specs are what other functions usually refer to as guides for their own work in designing, building, and marketing a feature. Aside from specs, a PM might also be writing longer documents to capture institutional knowledge and explain something. Later, when the PM is asked about a certain topic, it’s much more expedient to point towards an existing document. In general, documents are more formal artifacts for ideas that a PM wants to spread and/or get feedback on.
Slide presentations are another major output for PMs. Slides are usually made in the context of some kind of presentation at a meeting, and are great for communicating ideas more quickly and guiding conversations where you need them to go. Slides are great for upward management, since they usually present ideas much more concisely than a document. Unfortunately, this means that a lot more time is usually spent on crafting a slide deck to make sure that the right message is conveyed in the right way. Presentations can also be great for spreading and getting feedback on the UX team’s mocks.
Another major output might be some kind of data analysis. Companies of a certain size who rely on data for decision-making might have people dedicated to data analysis or data science, but otherwise these tasks fall to a PM. A PM is generally expected to know baseline and important metrics. If a company has fairly established systems for collecting data, then that data becomes a treasure trove of insights that the PM can mine for. Quantitative data is great for backing up proposals and troubleshooting what’s wrong, but is certainly not infallible nor a complete picture of what’s going on. It’s up to the PM to figure out what’s missing and what information is needed.
“Long-stretch” tasks generally require longer stretches of (relatively) uninterrupted time, so that the PM can think more deeply about a topic and put together some kind of appropriate artifact for it. This might be for something as specific as a small feature, to something as broad as the overall strategy and vision for the product. Because these kinds of tasks take time, and ideally uninterrupted time, they might have to be scheduled on the PM’s calendar as if they were meetings.
Variety is the name of the game
If it seems like there’s no clear answer to this chapter’s title question, it’s because there isn’t! A PM has to do whatever it takes to make progress on his projects, and that will mean a very different set of activities depending on what’s needed at the time.
One thing which is guaranteed though, is that there will be a decent amount of context switching in a typical day for a PM. This means switching between projects from one meeting to another. This means thinking at a very high level and then immediately getting into the weeds in the next meeting. This means dealing with a very short-term need and then addressing something for the longer-term health of the product. This means being strategic one moment and then maybe ruthlessly executing on a plan the next.
And this is what makes the PM job fun. The role inherently requires flexibility, a healthy amount of mental pliability, probably a dose of extroversion, and perhaps even a bit of ADD. There’s rarely monotony, which drives some people crazy, but provides never-ending excitement and motivation for others.