A Long Road to Product Management

Problem

I started out as an engineer but always wanted to understand the bigger picture. As an engineer, all I was concerned about was how to build my application to be efficient, fast, and beautiful. How customers will use it or what impact it could have -- was beyond my scope of work and I couldn’t tell if a few seconds of delay would matter in a particular context.

But I was curious to understand things beyond engineering. I did my M.A. in product management and product analytics because I wanted to understand why engineers do things in a particular way. Though I wanted to get into product management back then, I felt there was a gap I was not yet ready to bridge.

Actions taken

I joined Twitter and later Slack, working at both places initially as a software engineer but transitioning, first to data science and then product analytics where I analyzed users’ behavior. I was mostly dealing with the drop-off rates, user engagement in a particular onboarding flow, the user experience of a newly introduced feature, etc. That helped me understand why a particular feature has to be changed or implemented. Effectively, I acted in my role as a think-tank for a product manager -- I was helping a product manager, but I myself was not a product manager.

When I joined my last company I was initially hired as a product analyst only to transition later to a product management role. I was able to apply both my engineering and analytic experience in my new role. When working with Engineering I was able to use precise language and gain their respect by being knowledgeable about technology and architecture. At the same time, I was able to understand customers’ pain points and corroborate my insights with data. For example, if there was a drop-off I would talk to customers and to the sales team and find what were the reasons behind that. Then, I would communicate that to the engineering team through user stories.

One of the things that I had to learn in my role as a PM was to communicate differently with different stakeholders. As an engineer by training, I would tell something once and that would be it. As a PM I had to ensure that all different stakeholders clearly understood the message; therefore, I would have to adjust that message to their understanding of things. A PM role is a very holistic one, consisting of multiple components, all equally important. I would use my background in engineering, data, and analytics to approach a particular project, unlike for example, a PM who has a design background and who is focused on UX.

I think that anyone who really wants can jump into a PM role -- an engineer, salesperson, solutions architect, etc. However, no one will arrive at it with the complete knowledge and all skills necessary without working in this role for a while. Your past skills matter and will influence your performance and understanding of the role. My fellow PM who has a design background would frequently ask me to come along with her to architectural discussions and translate their conversations to layman’s terms. That helps me too as I have an opportunity to improve my designing skills.

Taking courses along the way is always helpful. I took a course on product management a few years before I decided to go into it. What you learn at university and at a more practically oriented course is vastly different and it helped me gain practical skills, for example, how to do user interviews.

Also, in my previous company which was a small startup, I had to wear multiple hats and I was effectually dealing with product management and project management. As a product manager, I had to write user stories and had things implemented and launched, while as a project manager I had to run Scrums, do backlog grooming, run planning and daily standups, etc. To be able to do that I took a Scrum certification and I also became a certified Scrum master. These courses, in addition to formal education and work experience, would be highly beneficial to any prospective PM.

Lessons learned

• There are many paths to product management. Career paths usually resemble long-distance running rather than a sprint and you need to plan yours long in advance. Sometimes you will need to move two steps back to move one step forward. This is especially true for product management that has its own detours, but each of them has its own value. It took me some time to arrive where I am today but it was a journey of learning and growing.
• Taking courses and being in the midst of a dynamic working environment are two different things. You should always aspire to learn more, exploring all available sources, and updating your knowledge and skills regularly. As an engineer who needs to learn new languages and technologies, a PM also needs to constantly hone their skills.
• Read through all available documentation, especially when transitioning to the new role. While documentation is often incomplete it is your best shot to familiarize yourself with new processes or product(s). In addition, it is your opportunity to enhance it by updating it.