5 Lessons From My First Year as a Google APM
During my first year as an APM, my goal was to learn as much as I could about how to be a great product manager. Here are 5 key lessons I learned.
#1 Don’t be too proud to ask for help 🙋
“If you want something done right do it yourself” is a common refrain. But for a PM, at least, that could not be more wrong. Your job as a PM is not to do everything yourself. Your job is to work with your team, who are far more capable than you at what they do, to ship a great product. That means knowing when to delegate responsibility and ask for help.
One of the hardest things for me to do was, and frankly still is, admitting I need help. Call it pride, naive optimism, or reckless arrogance but I had this attitude that I could do anything I put my mind to. Unfortunately, that led to situations where work took far longer than necessary, or worse, was not as good as it could have been.
For instance, there was the project where I spent weeks trying to come up with UX mocks, painstakingly brainstorming and iterating, only have our team lead suggest a UX designer take a stab at it. Lo and behold, they were create something far better than anything I had in only a fraction of the time.
Then there was the project where I spent a couple of weeks trying to get a senior engineer to give us their approval. After sending multiple emails, I offhandedly mentioned how long it was taking to my manager. They then pinged the engineer and the project was approved that same day. I could have saved myself a lot of time and stress if I had just escalated sooner.
So rather than “if you want something done right, do it yourself” a much better approach for PMs would be “if you want something done right, ask an expert to do it”.
#2 You need to tell a compelling story 📖
One of the first things you learn about being a good PM is that you need to be data-driven. But I’ve found that it’s not enough to just analyze data and make decisions based on it. To be a truly great PM, you need to tell a compelling story too.
Throughout my first year I struggled, and often failed, to get buy-in on my ideas. Wondering what I was doing wrong, I started observing senior people I worked with and analyzing their approach. I found that they had they had perfected the pithy elevator pitch and delivered it with deft consistency.
That’s not to say a great PM is a snake-oil salesman. They still do all of the data analysis needed to make informed decisions. But once they’ve done that they craft a story on top that helps pull it all together in a short, understandable, and convincing package.
Take a look at how Steve Jobs introduced the iPhone. He didn’t didn’t start with data about predicted sales numbers or a 2x2 matrix breaking down the market and showing how Apple was “uniquely differentiated”. He started by telling a story — a story about how Apple was combining three products into one.
#3 Don’t kill an idea while it’s still developing 🧠
A few months into my role, I was in a meeting with some of my team where we were discussing plans for an upcoming project. Ideas were flowing and one of the engineers suggested a new approach. Doubtful that’d result in a successful product, I spoke up and raised my concern.
After the meeting had ended, the engineer sent me a message asking me to “avoid giving negative feedback on new ideas” since it “stifled creativity unnecessarily”. At first I was defensive, explaining that my job as a PM was to help decide what we should we building. But the more I thought about it, the more I realized he was right. After I had spoken, our creative momentum was stalled and the flow of ideas came to a halt.
Reflecting on that experience, I’ve realized that there were actually numerous times where I had prematurely written off an idea that was still in its infancy. If it were up to me, those ideas would have been killed off then and there. But thanks to the fact that I worked with people more adept than myself, who gave the ideas space to develop, they actually ended up growing into successful projects.
So while part of the job of a PM is deciding what not to build, a great PM will first give an idea the space necessary for it to fully develop and not prematurely constrain it and impede the creative process.
#4 Own your calendar 📅
When you sign up to be a PM, you sign up for a lot of meetings. This isn’t about avoiding meetings altogether since they’re a great way to collaborate when run well. Rather, it’s about recognizing that there’s more to being a PM than attending meetings and carving out time to do those things.
When I first started as a PM my calendar was a free-for-all, with meetings scattered throughout the entire workday. Unfortunately a day full of fragmented meetings left little time for deep work like writing PRDs, analyzing data, or thinking about strategy. As a result, I found myself either unable to do that work or having to tackle it after everyone else went home for the day. Even then, I wasn’t very productive as my natural rhythm did not align with focussed work in the evenings.
Over time I learned that I needed to take control of my calendar and schedule my day so that it’ll be the most productive it can be. For me, that meant two things:
- Blocking out time for deep work in the mornings that I very rarely let anyone (myself or otherwise) schedule over.
- Scheduling meetings back to back to minimize the unproductive 30 minute gaps between them.
As a result of taking ownership of my calendar, I’m now able to get more done while working fewer hours.
#5 Being organized is powerful 📁
Something I learned over time during my first year is just how powerful being organized is. In my previous article, I described part of a PM’s job as “ensuring the product/feature is successful”. One important way a PM can do so is is by bringing organization, structure, and efficiency to the team.
Simple things like setting meeting agendas and taking notes, following up on action items, and documenting important decisions can have an outsized impact on a team’s ability to launch great products.
There was one project, for example, where my only contribution was running our weekly meeting. I didn’t really feel like I was adding much value until a few weeks in, when one of the engineers messaged me saying “thank you for your help with on the project. It’s been so much smoother since you joined”.
Perhaps even more importantly, having strong organizational skills helped me build credibility with the team. Towards the end of my first year, for example, it got to the point where our engineering lead would mention a document or presentation and then follow it up with “Rahul probably has the link”.
