I’ve just finished my first 30 days as a Product Manager moving from my previous Frontend Developer role in the Oberlo Growth team. I decided it’s also a good time to pause and reflect on all that has happened in my first month. Why product management? I’ve been asked this question lately by different people. It’s a hard question to answer because there was not one major reason that steered me towards product management. Rather, a mulitude of smaller reasons combined with the right opportunity at the right time prompted me to take the leap. In the typical software development process, product managers concern themselves with what gets built, while software engineers fuss over how it gets built. Over time, I came to realise that I was really much more passionate about the what as opposed to the how. I also knew I was not exactly too excited about the software engineering career path. I still enjoyed writing code a lot, but I was even more interested in leveraging technology and code to solve business problems. This was also what pushed me to starting a company as a technical co-founder previously. Without going into too specific details, an opportunity opened up toward the end of last year as a new team was planned to be formed. It also happened that the problem space that this new team would be operating in is one that I’ve had prior experiences in. My manager was also very supportive of this decision. First 30 days: expectations vs reality I was already aware that software engineering is very different from product management. As a software engineer, your work is mostly “serial”. You mostly work on one ticket at a time before moving to the next and you get to work most of the time in deep-work mode. I knew that this is the direct opposite for a product manager, but what I did not expect was the intensity of this opposite nature. A product happens with the combined input of engineering, UX, data, and marketing. In a typical work day, I would need to keep track of two, three different streams of work simultaneously. On top of that because of the vast differences in everyone’s schedules, an additional layer of context switching gets added on top that makes it harder. It was common for me to be talking to engineering one moment, and then attending a review meeting with marketing the next, and then having to work on a new feature with UX. This has left me overwhelmed at times initially. I have found two things to be the most helpful: being utterly ruthless in prioritisation, and blocking time for deep work. Ruthless prioritization As a product manager, you will have multiple stakeholders and they will have ideas, requests, bug reports that they will come to you with. It also doesn’t help that usually they will stress that their issue is of utmost importance. With only so limited time in a day and limited resources available (engineers, designers), you as a PM need to prioritise what to work on next for the biggest impact. There are two frameworks that I tend to reach out for: RICE and the Eisenhower matrix. Blocking time for deep work As a software engineer, I got to see how big of a difference having uninterrupted time to focus on would do to my producitivty. Two badly timed meetings in the afternoon was enough to bring productivity down to its knees for the day. Blocking out chunks of time in the day to work uninterrupted lets me focus on the hard but impactful stuff. Having hours to work uninterrupted on data analysis allows me to dig deeper and develop a better mental model of my product. This in turn helps me prioritise better and faster, creating a positive feedback loop. Product management is a non-prescriptive job. There are always so many things you can do at a given moment that it can be overwhelming sometimes. You have bug reports and feature requests coming from different sources and of course, each request is to the reporter, the most important and urgent issue that you need to solve yesterday. Leading without authority This is one aspect of being a product manager that stands out for me and one I enjoy. Unlike an actual manager where you have some default degree of authority over your subdordinates, the engineers and designers in your team are your equals. Engineers and designers are very smart people. If your idea is terrible, they are not going to be on board with your idea. Benefits of having a technical background First, I must say that a technical background is not required for the majority of PM roles. There are many product managers out there who came from the MBA route or transitioned from a UX designer. Transitioning to a product management role can be a pretty daunting change, and my own experience has told me that a technical background can help soften the blow and smoothen the transition. There are many smaller “quality-of-life” benefits coming from a technical background. I was no stranger to the software development process, and it also was easier for me to T-shirt size the engineering effort required a work. I was always most thankful for my technical background especially when I had to speak with senior engineering leadership. Initially, I went the route of talking from a high-level, product perspective. I did not want to come across as being too un-PM and stuck in my previovus role as an engineer. I left those conversations always feeling that we were not fully aligned. Later, I decided to vary my approach and dived deep into the technical details when I felt necessary. The conversations improved a lot as we were able to have a deeper degree of common understanding. Downsides of having a technical background A technical background can also have downsides for a product manager. You know how a product gets built and this know-how can end up setting limiting boundaries. I remember fondly a couple of times as a developer where I balked really hard from a crazy, hard-to-develop idea proposed by a product manager but that turned out to be impactful in the end. I’ve caught myself a few times talking myself out of a potentially awesome idea because it seemed almost impossible or was extremely troublesome to execute engineering-wise. When I brought such ideas up to our engineering counterparts, they either had a much better way to build than I could think of, or through discussion we were able to scope it down to a more acceptable minimal viable product. How I handled my first 30 days Before I officially started my new role, I came up with a rough list of goals that I wanted to achieve in my first 30 days: Understand the environment around my team, the role our team played in terms of the entire company’s strategy, and the role of other stakeholders and teams.A long term vision and strategy of my team and product, and establishing the position of our team.Get the ball rolling on some quick-wins as well as a moon-shot idea. Overall, I’m pretty satisfied with my end result after 30 days. There are certainly areas that I could have done better on. In my next post, I will touch more on this, as well as go deeper into the things I did for my first 30 days as a product manager. This post first appeared on my blog — . bryanleetc.com
