Discussing with Product Managers (PMs) who are ready to go on vacation today, I realized the wide variety of tasks that a PM must handle. Below is a generalized, domain-agnostic list, including tasks that may occur within a typical day of a Product Manager:
Disclaimer: The following list include activities where the PM is solely responsible to deliver them and other activities that he is part of the team that works on it. Also, not all activities happen in a daily basis.
[Discovery] Understand domain's performance
Every PM has Key Performance Indicators (KPIs). It's essential to check them daily to understand how they are performing, recognize patterns, and identify seasonal variations. Generally, the best way to gauge progress is to monitor it closely. KPIs are useful indicators of what has occurred.
Ideally, you should document what happened and why it occurred in your knowledge base. This information can be useful the next time you need answers for your KPIs.
[Discovery] Review customer feedback
You should establish processes to regularly gather feedback from your customers. This can be through methods like Net Promoter Score (NPS), sentiment analysis, surveys, interviews, or other sources that provide context about how your customers feel about your product.
Though we may have KPIs and numbers, qualitative data is essential to understand why something happened.
After all, your customer is the most important stakeholder.
[Discovery] Problem understanding
Understanding the problems you're trying to solve is core to your daily responsibilities. Sometimes, you may be able to tackle problems without technical implementation, such as by collaborating with another department or avoiding quick fixes that only alleviate the problem and create technical or design debt.
[Discovery] Work on solution with designers
PM sit along with designer to draft the solution space. Depending on the challenge, developers are also involved. There are cases where stakeholders are involved as well.
[Discovery] Work on an analysis with analysts
PM should initiate an analysis, most usually to measure the impact of a product change we developed in the last sprint.
[Discovery] Competition check & benchmarking
Do not forget the competition. Study them, subscribe to their newsletter, use their product. You should always be informed regarding their best features, what are you missing, what are they missing and how can you outperform them.
[Planning] Daily standup
Daily standup meetings are a common ritual where PMs gather with their team to discuss:
- What did I do yesterday?
- What will I do today?
- Are there any blockers? If yes, how can I overcome them?
We use Geekbot for our daily standups and highly recommend it.
[Planning] Product Planning
We plan our work in a weekly basis. Although technical sprints occur every 2 weeks, there is a weekly product alignment where we discuss both downstream & upstream stories across the department. When it comes to upstream and weekly planning, there are 3 statuses:
PRODUCT INPUT: Tasks that are under product discovery.
TECHNICAL REFINEMENT: After discovery is completed, stories get detailed technical feedback.
READY FOR IMPLEMENTATION: Stories that are ready for implementation.
[Planning] PRD writing
We create PRDs for main features. These documents require time and alignment with business and tech teams, but they serve as a reliable information source for all teams.
A well-written PRD can reduce the number of necessary meetings and accelerate development and story writing & splitting.
[Planning] OKR planning
Objectives and Key Results (OKR) planning requires monthly input for updates or creation of new OKRs for the upcoming quarter.
We spend a lot of hours on meetings. There are a lot of meeting types, alignment for a new feature, planning rituals, feedback meetings etc.
[Planning] Stakeholders management
Stakeholders may have needs, problems, or ideas that they would like to discuss with you.
[Planning] Communication & collaboration
Every PM spends time on communication and collaboration, engaging with:
- Stakeholders for updates.
- Other departments for input and collaboration (e.g., Marketing).
- Other PMs for input or feedback.
- Design and analytics teams.
- Operations for training & documentation.
- Tech for problem-solving & QA.
[Delivery] A/B testing review
PMs should access and evaluate active A/B tests, as it's their responsibility to decide how to proceed.
[Delivery] QA contribution
Often, PMs contribute to Quality Assurance (QA). There might be specific features or flows where the PM must approve before going live.
[Delivery] Epic split & story Writing
After completing the PRD, we need to break down the epic into tasks (stories) and assign them to respective teams.
[Delivery] Monitor technical releases (Production)
Stay informed about what your team or connected teams have released into production. This information helps you understand your current product development cycle and provides context for what has happened.
Many PMs check releases through tools like JIRA or Slack.
You may be involved in sourcing, evaluating assessments, and conducting interviews to expand your team with suitable candidates.
Decisions must often be made quickly.
[Team] Problem solving & feedback
Problems requiring your contribution may arise. Examples include:
- Missing information in tasks.
- Complexity that requires additional details.
- Stakeholders needing training on new features.
Do I miss any other important PM activity?