So, What Do You Actually Do As A Product Manager?

A typical day in the life as a PM


A lot of people have asked me what I do on a day-to-day basis as a software Product Manager, so here’s a schedule from an average day to help draw back the curtain. Product Management activities differ across organizations, titles, and teams. Common variables that will affect your individual experience are: product lifecycle stage, job level, frontend vs backend focus, and stage of the company. I’m currently in the new product development stage, so my “typical day” is likely skewed towards planning and coordination activities.

Much of a Product Manager’s responsibility is to juggle multiple streams of conversation and move them towards closure.

Whether over email or in meetings, you should be resolving uncertainty by gathering all available information (usage data, time constraints, budget constraints, competitor implementation, etc.), discussing the options with everyone, and either making a decision or assigning action items to get to one. People assume that because of the centrality of the role, a PM can tell people what to do — but that’s completely untrue and is a mark of a bad PM. Your role is deeply collaborative and many times you’ll be persuading people to support your decisions.

It’s not your job to have all the answers coming in, but you do need to be able to make defensible decisions from the information at hand.

A Typical Day

This is the average unsexy type of day. You have a ton of emails to respond to and take action items on, meetings to prepare for, and the largest chunk of open time you have is 1.5 hours — not enough to go deep into any one activity.

  1. 6:30AM. Wake up, throw on clothes and head to work. I usually come into the office around 8am to get a nice chunk of quiet time.
  2. 8:00AM. Skim through email inbox, respond to any emails that I can resolve within 2 minutes. The others are more complex questions/requests that I’ll have to research or have conversations with the developer team before I can answer them. Examples include feature requests, technical design conversations, questions about a specific implementation, report requests, etc.
  3. 8:15AM. Read the news. As a PM I need to stay up-to-date on my industry and competitors, looking for any industry regulation, competitor launches, relevant trends and reports— anything that affects our position in the market. I also read “fun” articles for inspiration, about new product/feature launches and general tech trends. For example, I downloaded Facebook’s new Paper app to check out the new mobile interactions.
  4. 8:30AM. Open up HipChat and get ready for the standard communication back and forth of the day. When my team is in the middle of development, I’ll get pinged on HipChat or in person throughout the day with questions to clarify or make a decision on specific product flows or edge cases. Oftentimes the team will bring up specific parts of implementation that would require significant time investment, so I’ll have to discuss (often with our product designer) and compromise on a simpler implementation.
  5. 8:35AM. Review and prioritize my to-do list for the day. If I don’t have a list, I feel a vague (okay, strong) sense of panic.
  6. 9:15AM. Standup. Our developer teams have a 10 minute standup every morning where they report what they did yesterday, what they’ll do today, and any blocks. I usually attend to do on-the-spot triage for unexpected issues or edge cases that arise, answer clarification questions or update the team of any news that affects them.
  7. The rest of the day usually alternates between meetings and short time chunks to do deskwork. Right now I’m on a new product, so we have more meetings than usual to plan out and compromise on features for v1 as well as discuss/assign activities for public launch. There are also developer team meetings to discuss technical design of features, as well as meetings with stakeholders (for example at SendGrid mine are the support, compliance, and account management teams) to run product requirements by them to get input and buy-in. The main results of meetings are action items for the people involved, and usually I leave a meeting with a ton of follow-up items.
  8. Throughout the day I’ll organize and update the backlog in Jira, our project management tool. This is where the result of the emails/research/conversations I have all day come to fruition — it’s my job to take the decisions made and translate them into prioritized “stories” which cover small functional pieces of work the developer team can do to incrementally add value to a product. Oftentimes I’ll write the requirements in terms of a customer use case (e.g. “As a user I want to X so that Y”) and flesh it out with technical details together with the team. I meet with my development teams once a week to go through this backlog and discuss the stories I queue up for them. These stories are probably my most consistent pieces of output as a Product Manager.
  9. Gym time. It’s a good way to break up the day and de-stress.
  10. Stumble home, cook some food and either read a good book or spend some time writing (oh hey!).

Atypical Days

These are the days a Product Manager loves, where you can focus and go deep on one activity, instead of switching contexts all day.

  • Strategy / Planning Days. These should happen at least every few weeks, to get ahead on project planning. Taking a day to think through use cases, edge cases, cross-team dependencies and general logistics for a project pays off in multiples later on when I need the context to answer a specific question in. Common Deliverables: product requirements, product roadmaps, presentations.
  • Big Thinking Days. These differ from strategy/planning days in scope; on big thinking days I’m thinking at the market level. What are big opportunities that we can differentiate ourselves by? What are some rising trends in technology and how will they affect us? What are the areas my company should move into (mobile, international)? Common Deliverables: opinions, meetings to discuss and brainstorm, presentations.
  • Project Management Tool Days. These are the byproducts of meeting days or planning days. Once I have a clear idea of what needs to happen, the next thing is to write a ton of stories and prioritize them in our backlog for the team to discuss. Deliverables: clear stories in a prioritized backlog.
  • Flowchart / Mockup Days. These are my personal favorite. Maybe you’ll have a feature or a user workflow that needs to be fleshed out, and the best way to do so is some flowcharting on Creately or wireframing on Balsamiq. Mapping out the different ways a user can navigate through your feature and cutting down on feature scope based on that is one recent example where a flowchart has helped me. Common Deliverables: product documentation, technical and design decisions, presentations.
  • Data Days. Pulling and analyzing SQL data on usage, going through Google Analytics, creating a report on the effectiveness of a feature, modeling out hypothetical pricing situations, etc. are all examples of activities that help me learn more about our users and how they navigate my product. I’ll also often watch KPIs (key performance indicators) by which my team measures our success, and think up improvements. These types of days usually come before a product is launched or afterwards. Common Deliverables: presentations, reports, technical decisions.
  • Customer Days. A Product Manager has to keep updated on their customers, and scheduling feedback sessions in person or over videochat is a good way to do so. I ask questions to learn more about their workflows, the context in which they use my product, problems/frustrations and get feedback on design mockups. Common Deliverables: presentations, reports, marketing decisions, design decisions.

In Conclusion

Product Management is a challenging role because it requires mastery of a wide skills set (many of which aren’t taught in school). In terms of managing your day-to-day, context switching is an unexpectedly important skill to master as many days will require you to jump between meetings on very different topics. Finally, on the topic of daily schedules it’s important for you to maintain a balance of proactivity and reactivity. You need to be able to make decisions as they come in, but also block off chunks of time for yourself to get ahead in product planning.

The benefits are many, though — you have influence and control over an entire product, and many of the skills you practice prepare you for entrepreneurship if you plan to take that route.

The work you do changes so often that you’ll never get bored, and you are in a unique position to interact with many different types of people across your organization. The daily life of a Product Manager is challenging to say the least, but you probably wouldn’t be attracted to it if you were just looking for something easy.


If you’re a Product Manager, I’d love to know what your day looks like. Here are links to other PMs’ days:


If you enjoyed this article, please recommend and share below.