A 'day' in my life as a product manager

Sneak peek into the life of an individual contributor PM

Hello Hello 👋

Welcome to this another edition of the ✨ Pragmatism ✨ newsletter.

Each week (almost 😅) I tackle reader questions about hiring, interviewing, careers in tech, breaking into product management or anything else that’s stressing you out about finding your next product role. Send me your questions and in return I’ll humbly offer you practical and actionable advice based on my experience and job hunting stories. No fluff, I promise :)

If you’re new here, subscribe to the newsletter so that you never miss a story from me!

In this post I am back with another one of the most frequently asked question:

How does your day look like as a product manager?

I have been asked this question many many times and every time I try to answer this question, I struggle to articulate and describe my day tangibly. I feel like I am doing so much and yet it feels like nothing when you try and reflect on any given day. There is really no typical day for me. The balance keeps shifting from one type of work to the other depending on the time of the year as well. Keep in mind that the type of company (enterprise vs consumer), stage of the company, and seniority level impact the PM workflows and routine as well.

My current team at work! (I am the one holding the food packet on right)

To set some context, I am currently a Product Manager with a fintech enterprise post-acquisition mid-sized company and this is what my work looks like as an individual contributor PM. Let’s start with the most frequent and recurring things first!

Daily and weekly stand-ups 📅

I meet with my engineers daily and my peer product managers on a weekly basis to discuss progress on different feature initiatives, lay down key deliverables for the week, identifying any roadblocks, and dependencies. I try to keep my engineers in the clean air, jump in to move things around or talk to external teams in case there are upcoming dependencies. My goal for each sprint is to ensure that each engineer on the team is executing seamlessly and independently. 🏎

Sprint planning 🏃‍♂️

I like to plan 3 or 4 sprints in advance! I do not wait till the end of the current sprint to start planning the next one. Throughout the week, I keep adding and/or moving Jira tickets around depending on the needs from the customers, internal stakeholders or reprioritization due to dependencies. If I am aware that there is something that cannot be started until 2 sprints from now, I will go ahead and add it to that particular sprint. When it is time to start our next sprint, I will have 95% of tickets in place and the sprint would require only minor changes. This helps me with continuous prioritization and staying ahead in the game 😎 It makes it a little easier to work with cross-functional teams as I have visibility at least 3 sprints down the line.

Working with engineers and designers 🛠✏️

Engineers - I spend time providing customer and business context, clarifying product requirements, brainstorming solutions to customer problems, planning sprints and deliverables. I also collaborate on reviewing spike documents, technical design documents, answering product questions to help engineers do the most in a sprint. With all these interactions and collaboration, my goal is to help the engineers build the right thing in the shortest amount of time.

Designers - I participate in design sprints facilitated by designers to translate product requirements into high fidelity wireframes over a period of 2-3 days before engineers can start executing. This is also the time when ambiguity in product requirements are surfaced and subsequently ironed out. Later in the product execution lifecycle, I work with designers to iteratively improve the product designs based on the feedback from internal stakeholders and customers.

Talking to customers 🎙

This is one of the most important phases for me during the product development lifecycle and this is where I like to spend most time on. In one of my previous posts, I write about my customer discovery toolkit and my process around it. Check it out here 👇

How I stay 'close' to my customers

Though, keep in mind that customer discovery is not a one-time transactional activity but a continuous process.

Writing product requirements 📝

Once I have gathered all the customer needs, pain points and feedback from different sources, I’ll spend 2-3 days writing down the product requirements document. I’ll block a few hours on my calendar each day to complete a first draft. I then take the PRD to engineers, designers, and other stakeholders for comments and feedback. I keep iterating over the PRD until I have buy-in from everyone involved and being impacted by the feature being built. This can take anywhere from 2-3 weeks. Keep in mind that PRD is a living document and evolves as the needs of the customers evolve!

P.S. - If you’d like me to write a newsletter post on writing a great PRD, feel free to shoot me a reply to this email!

Competitor and market research 🔬

I actively spend time reading about and analyzing competitor products. This helps me in 2 ways:

1. If a customer is showing interest in migrating from one of our competitors, I try and understand the pain points of the customer with the competitor product, so that those insights can be leveraged to invest resources in areas that the product is better at and improve it even further. It also helps me to better position the product against the competitors.

2. If a customer is requesting for features that might not be supported as compared to a competitor, it helps me influence the product roadmap and be cognizant of product capabilities that will make the company lose customers and/or reduce customer satisfaction.

Measuring and monitoring 📊

I define and monitor metrics for the product areas and features that I launch or currently own. I work with the engineering to setup and/or refine reporting dashboards that I need to measure the defined metrics. Once the insights are setup, the next step is to make them available to the team for visibility into the health, performance, and usage of the product to enable decision making. These insights can lead to a number of decisions being taken on the product such as launching a new feature, improving an existing feature, improving the infrastructure, and sometimes even getting rid of a feature.

Firefighting and troubleshooting 🚒

I wish we lived in a perfect world but unfortunately, we don’t! Software products are seldom perfect and there are days when products or processes break. As a product manager, I have to immediately jump on to putting off those fires and de-prioritize everything else. This can involve dealing with angry customer emails, a bug that breaks a critical workflow for the customer, outages in production environment, missed deadlines, communication failures etc.

Yearly roadmap planning 🎯

In the final quarter of the year, I spend time thinking about the big rocks that I need to move based on the customer feedback, competitive landscape, and company goals. I then define a roadmap for the entire next year with a goal to reach a certain product state. I work with the leadership to get buy-in for the initiatives and other product counterparts to refine the roadmap based on the resources and constraints. This entire process can take anywhere from 1-2 months and goes hand-in-hand with all the other work that I do on a day-to-day basis.

Quarterly roadmap planning 🛣

In the middle of every quarter, I engage with my peer PMs and engineers to breakdown the large initiatives on a yearly roadmap into more granular milestones and objectives for the upcoming quarter. Once the milestones have been created, I have to socialize the milestones within my own engineering team and other engineering teams if I need their support with execution for the milestones.

The engineering teams receive similar requests from other PMs and product teams as well. Based on the resources available, they allocate a certain number of sprints to my milestone. If there is more work and less resources, I’d have to work with other PMs to prioritize or de-prioritize work, reduce scope, or make a call to hire additional resources and take that request to the leadership.

For my own engineering team of 5-6 engineers, I just need to prioritize and stack rank my own initiatives to get the work done.

Feature commercialization and go-to-market 💼

I work closely with the sales, customer success, marketing, solution engineering, and implementation teams during each phase of the product/feature lifecycle.

1. Initially once the PRD is complete, I’d work with these functions to commercialize the feature, gather feedback, and share tentative timelines.

2. Once the feature is out of design phase, I’d demo working prototypes to gather early feedback from internal users before the feature goes into development. This is the first time when people can actually visualize how the experience is going to be for the end customers.

3. Towards the end of feature development, I’d demo the working feature internally with aim to gather alpha users and help customer facing teams get hands-on with the feature before it is put into the hands of the customer.

4. While the engineers are finishing up the feature and gathering feedback from the UAT team, I’d work with different functions to help them create necessary collateral around the feature. For e.g. I might work with sales for feature pitch deck, work with customer success for a help desk article etc.

5. Finally, I work with sales and implementation teams to plan a rollout and ramp strategy. Based on this strategy, we start rolling out the feature to the determined customer base.

Product manager interviews 🗣

As the company, product, and customer base grows, you also need to keep hiring continuously to support that growth. I conduct 3-4 product manager interviews per week on an average to support hiring needs for different product verticals.

Product advocacy and process improvements ⚙️

Product development processes at a startup vs a FAANG company are not the same. Product management culture evolves (and it needs to!) as the company and products grow and it does not happen on its own. There are people within these companies who actively drive this change to make products and processes more scalable. I play an active role in identifying gaps in the product management and development processes, developing new and refining existing process, introducing methods to build better products, and finally commercializing those in the entire product vertical.

Ad-hoc meetings 🤝

Apart from everything that I have described above, there are meetings that you need to attend as a PM to just run-the-business. There is really no definition to these meetings and do not fall in any other bucket. My goal is always try and minimize such meetings, resolve things over Slack or Email, or have documentation ready to point people in the right direction.

---

My workflow 👨‍💻

Let’s now take a look at what my workflow looks like to get things done.

1. My week starts on Friday afternoon, where I start planning deliverables for the upcoming week and people whom I need to meet with. I have been maintaining a running document where I note this down for each week. Fun fact: My current document is more than a year old, 30 pages long (as of when this post gets published), and contains a record of everything that I have done in the last 1 year. Sick, right?

2. I prioritize my objectives and meetings for the upcoming week in that document.

3. I make a note of all the follow-ups that I need to do in an upcoming week from the current week. If possible, I schedule emails and Slack messages for appropriate days to relieve myself from the cognitive load of completing those tasks.

4. I put time on people’s calendar on Friday itself and not wait for the next week to get the earliest possible slots.

5. I reserve Monday mornings for deep work.

6. I put time on my calendar even for things that I need to work on individually to ensure that I have time for all the planned action items on my list.

7. I take most of my meetings on Tuesday, Wednesday, and Thursday.

8. I reserve my Fridays again for deep work, usually take no meetings unless something is important and start wrapping up my work by afternoon to repeat the cycle from #1.

I hope you enjoyed reading this and found it insightful💡

---

Questions? Just reply to this email and ask!

See you all next week,

Tanay 👋