First 30 Days From Software Engineer to Product Manager
I’ve just finished my first 30 days as a product manager, moving from my previous front-end 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 toward product management. Rather, a multitude 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 realize 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 previously to start a company as a technical co-founder.
Without going into too many specific details, an opportunity opened up toward the end of last year, as a new team was being formed. It happened that the problem space this new team would be operating in is one in which I’ve had prior experiences. My manager was also very supportive of this decision.
First 30 days: expectations vs. reality
I was already aware software engineering is very different from product management. As a software engineer, your work is mostly “serial.” You usually 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 this was 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 or 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, which makes it harder. It was common for me to be talking to engineering one moment, then attending a review meeting with marketing the next, then having to work on a new feature with UX.
Initially, this has left me overwhelmed at times. I have found two things to be the most helpful: being utterly ruthless in prioritization and blocking time for deep work.
Ruthless prioritization
As a product manager, you will have multiple stakeholders, and they will have ideas, requests and bug reports they will come to you with. It also doesn’t help that they usually will stress their issue is of utmost importance. With only limited time in a day and limited resources available (engineers, designers), you, as a PM, need to prioritize what to work on next for the biggest impact. There are two frameworks 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 a difference having uninterrupted time to focus on would be for my productivity. Two badly timed meetings in the afternoon was enough to bring productivity to its knees for the day. Blocking out chunks of time 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 prioritize 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.
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 subordinates, the engineers and designers on 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
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 UX design. 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 smooth 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 amount of engineering effort needed for a feature. I was always most thankful for my technical background whenever 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 previous role as an engineer. I left those conversations always feeling we were not fully aligned. Later, I decided to vary my approach and dove deep into the technical details when I felt it was 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 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 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 on which I could have done better. 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.
