6 Months a Product Manager — Lessons Learnt
In October 2020, I took a big career decision; I made an industry and job function switch. I had spent the last year trying to make the move, so I was elated when I finally got the gig.
6 months in, and I’m glad that I made this decision. It has been the most challenging thing I’ve done— and I had 3 semesters of econometrics. In all, it’s been a wonderful experience, and I have grown a lot, both professionally and personally. As I move on to the next 6 months, I’m documenting my mistakes and lessons learnt, which make me a better PM now than I was in October. Cheers to more learning, unlearning and relearning
- Always saying yes: Seeing people online talk about how regularly PMs said “no” confused me. If someone wanted something and my team could do it, then why not? The issue wasn’t really about saying yes or no. It was about allowing distractions to replace agreed plans (read roadmap), many times without validating the need for these things. I have dropped my “yes man” behaviour and learnt to push back.
People always have ideas — be it management, your team lead, or other stakeholders. It’s up to the PM to decide if any of these things are more important than your current tasks and, if not, which should be discussed later.
2. Not owning my decisions: For the few months, my response every time I was asked “why?” was “Mr. A said so.” I laugh about it now, but it was horrible. A lot was going on at once. I needed to learn about health insurance, product management principles, our product, and tech/engineering jargon all at once. Sometimes I just need someone to make decisions while I tried to catch up.
I got several reminders that “it’s your product” and gradually developed an ownership mindset.
3. Assuming someone else will know: I inherited an existing product, so there was a lot I didn’t know. I thought that since my teammates had been there before me, they would tell me about all the dependencies and other considerations. I would come up with a solution, discuss it with a few people and spend days documenting it only to find out that it wouldn’t work because of some technical reasons. An example was finding out I was to create mobile designs before web since my users are primarily on mobile — it never crossed my mind. I learnt to be more thorough with my requirement gathering and scoping, asking many questions and not assuming people will volunteer information.
4. Bad prioritization: This affected both my features and my daily tasks. When building a complex product, I should have prioritized my MVP features and made updates later, shipping faster and making improvements iteratively. Instead, I waited to build out all features (including nice-to-haves) before going live. At other times, I also directed engineering efforts to low reward fixes instead of focusing on what we were building.
I was doing a lot of work daily but not necessarily moving the needle because I focused on low hanging fruits and tasks solely within my power to complete. The hack here was to keep in mind my target and focus on high impact (low effort preferably) activities that contribute towards my goals.
Activity != Impact.
5. Blanking out during meetings when I got overwhelmed: Meetings were tough initially, especially the ones with engineers. There was so much info flying around at once, and when it got too much for me, I would blank out and allow the other parties to conclude. It’s not like I had anything to contribute anyway. Well, that thinking led me to mistake 2 and 3 stated above.
Meeting after meeting, the knowledge gap grew until I realized it was a problem. I had to learn to follow the conversation then ask a lot of questions later. Also, attempting to multitask during meetings was a terrible idea.
6. Not understanding problems fully: I took problems at face value, which became evident when ideating solutions. I wasn’t researching the root causes of the issues we faced and based some of my solutions on assumptions. The fix here was to engage my users more and find out the underlying reasons behind their actions. I have learnt to ask the 5 whys.
I wonder why we have X problem; let me ask my users VS We have X problem, so I’m going to do Y.
7. Looking for data after launching: Ideally, after launching a new product, one would give some time for users to adopt it and check metrics to see if things were going according to plan and if there was a need for product changes. I had listed out success metrics in my PRD, but not how I would track my users’ interactions with the product or how to get the data I needed. When the time came to review, I had to set up Google Analytics and Clarity afresh and start sourcing for internal data.
The consequence here was that I couldn’t get data from previous user sessions, so some datasets were incomplete. Lesson learnt.
8. Jira Junkie: Lol, this is probably the most ridiculous. I spent hours on Jira monitoring my engineers’ progress. I wanted to be sure that we would complete our sprint tasks, and every morning I would visit the board and try to estimate if they were working fast enough. The irony is that they were working and I was not. Interestingly, I didn’t become a “what’s the update?” PM. At least I hope not.
Knowing that you have made a mistake is the first step to correcting it. At some point, these things seemed natural, but I can share these now because I know what I did wrong, and I have learnt to do better. I’m looking forward to more mistakes and growth. As they say, fail fast learn faster.
