The Three Most Important Lessons Learned From my First Year of Being a Product Manager
March 2016 marked my one-year anniversary at Google as an Associate Product Manager. This first year has absolutely flown by and I wanted to take some time to reflect on what I had learned. It was almost four years ago when I stumbled upon a job posting for an APM internship. I remember a specific line vividly:
“As part of the Product Management team, you bridge technical and business worlds as you design technologies with creative and prolific engineers and then zoom out to lead matrix teams such as Sales, Marketing and Finance, to name a few”
Instantly I knew this would be a perfect fit. As a self-proclaimed generalist, I like writing code, designing UIs, and thinking about business strategy. Being an APM seemed like an amazing opportunity to get to partake in all of these functions in some capacity. Now that I am an APM, I know that it’s true! The generalist notion of being a PM is great, but it can also make being a PM very hard. There’s no formal schooling for it - like myself, most of my APM colleagues have CS degrees. In order to learn how to be a PM, you actually need to be a PM.
So after a year of being a PM - what have I learned? A ton. I look back on my first few months and I feel embarrassed - there was so much I didn’t know. There is still so much I don’t know - however I feel that I am learning every day and continuing to get better. In order to save my fellow and future new PMs some pain, I wanted to share what I felt were the three biggest lessons that I learned from my first year. They are:
- Ruthless Prioritization
- The Unmeasured Product is Not Worth Building
- Build Relationships - Not Just Products
In this post, I’m just going to focus on the first lesson: Ruthless Prioritization.
Lesson One: Ruthless Prioritization
Everything you do as a PM needs ruthless prioritization. How you spend your time, what you put on your roadmap, the granular features in a product — all of it needs to be examined and optimized so that the input produces the maximum outcome. Would you rather spend one hour on something that would affect 10 users or 1000 users? No brainer. However it’s easy to forget this mindset and get caught up with a lot of trivialities and spend time (your time or even worse — your team’s) on tasks that won’t drive that much impact.
Prioritizing Your Own Time
I think that one of the hardest areas to prioritize is your own time. As a new PM, it is easy to freak out once you realize you have a seemingly infinite list of tasks that you feel responsible for. How the heck are you supposed to get this all done in a day / week / quarter? It’s common to hear PMs joke “I wish everyone else would go on vacation for a week so I could get all this done”. As a PM things are constantly being added to your queue. When I first started it was a First In First Out queue — I would work through my tasks in the order that I became aware of them. Then I went through a period of being obsessed about replying back to email quickly (that needs a separate post-mortem) and it become a Last In First Out queue — I tried to tackle the most recent tasks as quickly as possible. Both are unhealthy.
How did I fix this? I switched to a priority queue:
In computer science, a priority queue is an abstract data type which is like a regular queue or stack data structure, but where additionally each element has a “priority” associated with it. In a priority queue, an element with high priority is served before an element with low priority. If two elements have the same priority, they are served according to their order in the queue.
I now keep a list (first in Google Sheets, then in Google Keep) pinned to a tab in Chrome and any time I become aware of a task, I add it to this list with a priority (0–3) based on time sensitivity, effort and overall impact. At the beginning of a week or day, I examine this list and block out time on my calendar to get the high priority tasks done.
Note that this will make it feel like you are dropping the ball at times — there will be a task on your plate for weeks that hasn’t gotten done. In situations like this — it is important to over-communicate and set expectations. If you get asked to do something that will take you an hour and is lower impact — set the expectation that you can’t do it immediately but will try to get it done by a target date. Don’t keep people relying on you blind.
Prioritizing Product Features
When it comes to actually building your product, ruthless prioritization is a must. Just like the seemingly infinite amount of tasks that get put on your plate — there are a seemingly infinite amount of combinations of features that could go into your product. Building a product is all about trade-offs — there are a finite amount of engineering hours. Will your team spend five of those hours to fix an edge case or on starting the infrastructure for a new feature? The answer is: it depends.
I worked on Google Search for my first rotation and I ran into this conundrum often. Working on UI in Google Search is like being a kid in a candy store if you’re the type of person who just loves edge cases (I’m not judging). The reach of the product is quite literally the entire world which means different devices, languages, network connections, etc. Imagine designing a feature that needs to work across all of these perfectly — crazy right? There are of course going to be edge cases such as buttons overlapping or text being truncated or adult-film stars being classified as movie stars which makes for some awkward product cases. It’s important not to get too bogged down in these edge cases — however as a PM you need to make that decision.
A good way to help make this decision is to ask yourself the following questions:
1. How is the user affected by this issue — does it block them from using the product? Is it a minor annoyance?
2. How many users are affected by this issue?
3. What is the engineering effort required to fix this issue?
4. What task would not be worked on if the team tackled this?
I use this framework all the time, especially in my new role on the Google Photos team. I’m working on a highly visible user feature (the search functionality) and have to make sure our features work well across our iOS, Android, and Web clients. In one of our latest releases, we redesigned a large part of the search experience and there was an issue that was raised for iOS where a part of the view that a user sees when they tap the search box was not quite to the UX spec (an element’s spacing was incorrect). I evaluated the issue with my framework:
- Minor pure UI issue that would not likely be noticed by users
- Affects all iOS users
- Would take a few days end to end to get out the door
- A high priority new feature
Taking these observations into account, I decided that although it affected all iOS users, it was a minor issue that was unlikely to be noticed and would not hinder users from using the product. It was not worth someone stopping work on the high priority new feature in order to fix it. I made the call to wait until we had more bandwidth at the end of the quarter before tackling it.
Note that building an excellent product is a balancing act. If you neglect to ever fix or prioritize small issues - they will build up over time and your product will suffer. One way to help with this is to have “fix-it” weeks where you keep track of all of these minor bugs over time and then have a dedicated “fix-it” week where the whole team works on just these small fixes”. The danger here is punting every bug to “fix-it” week or prioritizing too many things as a P4 which is PM speak for “our ETA for this fix is never”. Do your best to catch these bugs before they get out (and not just having a QA team take a pass - you yourself should be verifying and checking!) and be honest with the impact that they would have on your product and team once they are identified.
Getting into a mindset of ruthless prioritization is one of the most important things that you can learn when you first become a PM. Always be asking yourself: is this the most important thing that you or your team could be doing? When you’re new, you’re likely to have a hard time judging this. Make sure to involve your manager and engineering lead counterparts. Over time, your intuition will develop and you will be able to judge this for yourself. Always seek to be impactful - not busy.
My next post will touch on the second lesson I learned: The Unmeasured Product is Not Worth Building.
Thanks to Jeff Grimes, Michael Hopkins, Dan “DK” Kang, and Matt Sheets for reading drafts of this.