Day in the Life of a Platform Product Manager
This article is a sequel to our popular post, Day in the Life of a Product Manager.
There are many different flavors of product management, especially since product manager responsibilities depend greatly on the industry, company, business model, and product.
Due to this variability, there is a wide range of day-to-day activities, but ultimately a product manager is still responsible for doing whatever it takes to collaborate with multiple teams and move different conversations towards closure.
That being said, there are a few general buckets of product managers, mostly based on business model and product ownership.
Below, we’ve provided an example of day-to-day activities for a platform product manager.
Generally speaking, a platform product manager works on products that are internally used by the business or used by other product managers. Some examples include Customer Relationship Management platforms, a.k.a. CRMs (e.g. Salesforce, HubSpot) and administrative products (e.g. user permissioning systems, internal microservices).
That being said, the only constant in a product manager’s life is change, so take our example as only a slice of time rather than an exact set of activities that happens every single day.
These may change for different platform product managers; you can ask other product experts in the PMHQ community if you’re looking for a more precise answer.
6:00AM: Wake up and check email for bug reports and automated alerts. Since we’ve got users on the East Coast and I’m on the West Coast, it’s important to see anything that might have broken over the night.
We have a few error emails that came in. I write an email to myself on what to test, as well as hypotheses for what might have gone wrong. As the Platform PM, it’s my duty to ensure we have as much uptime and reliability as possible.
I decide not to wake up any engineers early. The impact is not that bad yet.
7:00 AM: Arrive at the office and execute the test plan, which takes a little more than an hour to cover.
Create a couple of tickets to write up reproduction steps and hypotheses that were eliminated, then assign them to the Engineering Lead. I’ll sync with her once she arrives at 9 AM.
8:30 AM: Grab breakfast. Review performance dashboards. There’s a worrying spike in how long it’s taking for a particular back-end function to run. Log a ticket with that observation and assign to the Engineering Lead as well.
Check to see that the Engineering Lead isn’t overloaded. Whoops, there are too many tickets for her to tackle; I move some of her lower priority tickets to be done at a later time.
9:00 AM: Catch up with the Engineering Lead. Review priorities for the day and for the sprint. She will reassign the tickets I gave her once she’s taken an initial look and figured out which engineer is best for each task.
We decide to release tonight with the bugfixes; even though the current impact is low, it has a high risk of crippling the business if we let it sit until the next scheduled release, which is 1.5 weeks away.
9:30 AM: Stand up with the development team. Highlight the new tickets that came in, and ask them to re-prioritize those over all others. After all, if they’re not done, we can’t release tonight.
We also check to make sure that if we release tonight, that we won’t release any half-complete code. Since our engineers did not yet merge to the master branch, we’re good to go.
Merging means to synchronize all of the work that you did to a centralized place. The master branch is where we store all of the code that we will be releasing to production soon. Since their changes are on their computers as of now, it won’t impact the release tonight.
9:45 AM: Review technical specifications for a new vendor that we’re integrating with. The goal is for our internal platform users to sync their outstanding tasks with their email and their calendars.
Notice that some of the specs don’t make sense. Write up a draft of my concerns and send it to my Engineering Lead for her review too. Schedule a call with the vendor in a couple of days, so that we have time to align on our questions and our requests.
11:00 AM: Meet with head of Operations, who is using our internal platform to drive our sales cycle. Review all outstanding tickets submitted by her team, and reprioritize them appropriately.
12:00 PM: Eat. Read emails. Log to-do’s into Trello, which is a free personal task tracker. Find out there’s a webinar from another potential vendor next week, and block out my calendar so that I attend. I need to make sure I know what we’re currently using, and how that compares vs. what they’re offering.
If needed, I’ll make the business case to Operations, Finance, and Engineering that we need to switch vendors.
1:00 PM: Meeting with internal platform users. Gather feedback on their wish list, and show them how we’ve prioritized the backlog of feature requests from them so far.
1:30 PM: Receive urgent email that an integration broke. Reschedule my 1:1 with my manager so that I have time to fix this problem.
Begin debugging just like I did this morning. Find out it’s a outage from the provider. Send email to the customer success representative from the provider to determine how long it will be broken.
2:00 PM: Integration is back up and running. scheduling 1:1 meetings with department heads on their goals for the next quarter.
When serving internal stakeholders, it’s important to get their set of priorities. I’ll take what I learn from meetings and synthesize into quarterly priorities by department, then sit down with the entire management team together and determine the force-ranked order of priorities.
Internal platforms must deliver the highest absolute impact for the business, regardless of department, and some features and priorities can deliver impact for multiple departments at once.
I decide to highlight scalability for the next quarter. Too many data jobs are shuttling redundant data between multiple systems in real time, which is slowing down performance.
One of my priorities is to determine what our single source of truth is, but I need stakeholders to agree which system is the source of truth. Once agreed, I’ll need to sit with the Engineering Lead to architect different solution stacks, and determine which one will be best for the business.
2:30 PM: Write up slide deck on progress made this quarter vs. roadmap. Highlight learnings and retrospectives. Pull stats on product performance, time saved, and conversion rates in the funnel.
4:00 PM: Meet with lead automation tester. Discuss which test cases have been automated, and what the next priorities are. Determine ramp up plan for newly hired tester who will next week. I will give the business overview, and the lead tester will conduct knowledge transfer.
5:00 PM: Dive into configuration for an existing integration on a staging environment.
Staging environments are copies of code where you do your testing, before you let a new feature go into the world. Live users use a copy of the code called the “production environment”, and it’s important not to develop new features on production directly, since it can cause those users to run into bugs.
Set up a demo for a new workflow, since we’re testing out a new way to communicate between customers and the Operations team. Schedule time with a couple of users and their managers to run the demo and gather feedback.
If the demo goes well, I will write up the documentation on the new workflow, and coordinate training with operations managers. My set of documentation is meant for the engineers, but it will help the operations managers create their own slide decks with screenshots on how to use the new workflow.
6:30 PM: Check in with Engineering Lead on release status. We should be good to go. Just in case, we have our rollback set up.
Rollbacks are how you “reset” your production environment to a previous state; essentially, they are a set of instructions on how to reverse all of the code changes that were recently made. This is important when users spend every working hour on your product; if it breaks, no one works.
7:00 PM: Monitor the release. Ensure no critical error emails come in. Mark bugfix tickets as done.
Afterwards, I head out for dinner with my Engineering Lead to unwind and catch up on our personal lives. Another job well done by the team!
Curious what the day-to-day looks like for other product managers? See what other product managers are working on in our Product HQ Community.
