The day to day different between product manager and technical lead really start to show as I embarked on the product manager journey. Before I moved, I am always curious about what a typical day of a product manager. Surely product manager wouldn’t be planning roadmap daily, writing user stories daily or prioritizing feature daily. So what exactly does a product manager do daily?
50 days ago, I wrote about my transition from technical lead to a product manager. 100 days into my new role as a product manager, I thought that it will be interesting to write about my day to day tasks of being a product manager and what is the greatest difference as compared to a technical lead.
A Typical No Drama Day
This is the usual no drama day where we don’t have to firefight issue and has no major upcoming event like a product launch or marketing execution.
7:30am – Wake up and Breakfast
I usually wake up on the first alarm ring. Breakfast plus a cup of black coffee and I start planning my days. This is not a to-do list but rather a chunk of larger tasks that I need some hours or required working with another team to clear. I usually have a to-do list for smaller tasks that I plan yesterday before leaving work. I will also pull out my calendar and make a note to avoid certain timing if I have an upcoming meeting scheduled.
9:00am – Traveling to work
I travel to work at my MRT and usually take 30min to commute. Most of the time I will be listening to podcast or audiobook. Currently, I am on the #AskGaryVee audiobook and must say that it is better than what I have expected. There are very few businessmen like him who went through the different era of the internet and still be so adaptable and always preparing for changes.
9.30am – Early bird catch the most worm
Since this is a startup, I am usually the first one to reach office. Most people tend to come in slightly later and leave work late. I often enjoy this period of time because I don’t get distracted and is able to focus fully on my tasks. I usually look at Slack, JIRA and email to look for tasks that required my immediate attention. Basically, I aim to resolve any issues and answer questions that are a blocker to someone else work. This way, when they start working, they can immediately tackle items that bring value.
Next, I review any new build feature on our staging server, test out bug fixes and any other item base on the ticket that required review. At this stage, the most ticket should be a move to completed or just required some minor changes. However, on some occasion, it has to be totally reworked. I treat ticket that required a total rework very seriously because I feel that it is wasted time and effort. I will do my best to find out what’s wrong and ensure that it will not happen again.
11.30am – Checking in with Others
By this time, everyone should already be in office and settled down with their own individual morning routine. Usually, I would schedule a short call or catch up with a colleague. It could be asking for feedback on features, what problem are they having or just generally how things are going for them. These chat usually give me a great understanding of each individual thoughts and also understand what other problems they are having while carrying out their daily tasks.
12.00pm – Tackling the important tasks
Somehow, I am most productive this time. I aim to tackle the important tasks here. I usually look at the upcoming features that we have in mind. Understand about what problem this feature is trying to solve. Then I will move on to wireframing (if needed), spec writing or a brainstorm session with myself about how to solve this problem in a different way. Many time, feature suggested are base on their individual perception that it will solve a given problem. Most people are okay with changing the way this feature is designed as long as it solves their problem.
13.15pm – Lunch Time
I prefer to go for a late lunch to avoid the crowd. Sometimes I am too deep into working at the 12.00pm block that I go even later. Most of the time I grab lunch alone. Occasional with my boss if he feels like grabbing lunch too. I also use the time to read an article that I have saved in Medium or catch up with the IndieHacker interview.
14.15pm – Check Metrics / Reply to question / More Reviews
At this time, I usually clear out my planned to-do list tasks. Replying to question or pending email. I also look at different metrics that I have set up to get a feel about our product health. If I have time to spare, I will check back on JIRA and clear any tasks that required review.
4.00pm – Meetings / Demo
I do my best to schedule meetings or demo at the latter part of the days. This session usually involves more people and tend to take most of my energy away. Recently I run a demo session at this block of time with the whole team to show them how to use Metabase.
Metabase is an open source analytics tool that I have set up to extract key analytics from our read-only production database. We also able to set up some user information panel using a variable so that our customer support can handle customer question and request better.
5:45pm — 6.30pm – Ending the day
By this time, I usually drain out. I use the remaining work time to reply to questions that are less urgent and also plan out my todo list for the next day. This to-do list is usually small tasks like replying to question, checking in with who or replying the pending text/email.
Difference between Technical Lead and Product Manager
I found out that the greatest difference in the day I spent as a technical lead and product manager is the people that I am talking to and the problems that I am helping to solve.
Being a technical lead, most of my time is spent working on designing a technical solution, helping my fellow developers on their work and only occasionally attend meetings that involve many other colleagues from other operations.
Being a product manager, most of my time is spent on understanding the problem from different operations. Brainstorm with them possible solutions and then work with the tech team to come out with a feasible technical solution.
In short, I get to truly understand the whole picture of how the company is functioning. I have a chance to work with different people that each has their own daily operation to perform.
Whenever there is a problem that comes up, I will usually be the first person to work with them to come out with a temporary solution to alleviate the problem. If it is something that happened often, we then work together and come out with a more scalable solution that usually required a longer time to design and build.