What I Learned When Moving From Engineering to Product Management.

Photo by Matthew Henry

About 2.5 years years ago I left my backend engineering role to become a product manager. I developed several learnings along the way, that, over the past year, I’ve had the opportunity to share with colleagues and friends who wanted to make a similar transition.

In this post, I’ll share some of these learnings, which I hope will be helpful for aspiring product managers, who lack sufficient insight about the role itself, or are unsure about pursuing product management in the longer term.

My background

Prior to becoming a product manager, I was working as an engineer in the Core Infrastructure team at Booking.com. My day-to-day responsibilities involved a mix of software development, reliability engineering, and DevOps work. Before that, I had gained experience in multiple new product development (NPD) initiatives, in both B2B and B2C spaces.

Why did I move to product management?

Exposure to NPD projects had helped me develop a habit of thinking about engineering a product in steps (repeating the feedback and development cycles).

During my time in Core Infra, I was developing the new images infrastructure as an engineer. However, part of my job required me to constantly interface with other internal teams, and understand their requirements. Effectively, internal teams were our “customers” in this case.

I decided to move to product management when I realised that I enjoyed engaging with customers, understanding their psychology, and iterating on the product, more than simply writing a part of the backend code.

Reality check after 3-months of being a PM

3-months into my new role, I realised that there’s more to being a PM than I had originally anticipated. As a former engineer, I had only been exposed to the part of a PM’s job that involved me directly.

Behind the scenes, however, PMs have to navigate significant uncertainty, work on abstract problems, and do plenty of leg-work to plan the product months ahead of engineering timelines.

The reality check didn’t really deter me from becoming a PM, but rather gave me a sense of the learning curve that lay ahead of me. Furthermore, my technical background gave me the anchor (or spike in my skill set) around which I needed to develop my PM skills.

What skills do PMs need?

Below is a list of seven attributes that I’ve identified in some of the best PMs I’ve worked with. For anyone aspiring to move to product management, I’d recommend using the below list to also get a sense of the day-to-day responsibilities of a PM, and assess whether you would actually be interested in shouldering all of these:

1. Being close to customers: The single point I want to emphasise the most. PMs need to constantly communicate with customers. Frequent customer input (qualitative or quantitative) will drive your product development in the right direction. Oftentimes, new PMs are so deeply embedded in the product development process that the customer needs and the product features diverge by the time of delivery. Remember, the right product is not the one with most features or fewest bugs, it’s the one which solves the customer’s problems at the right time.
2. Hypotheses testing and working in iterations: As opposed to core engineering work, product development is an iterative process. It’s common for PMs to ship a MVP (minimum viable product) fast, collect feedback, and then iterate (or pivot). While this approach may sound like common sense to most, I’ve noticed engineers, who became PMs, have a hard time adapting to this cycle. As engineers we are used to building things right — for example thinking ahead about all edge cases when writing a piece of software. This practice is necessary for engineering but doesn’t translate directly to product management. It’s more efficient to iterate in small releases rather than launching one big product all at once.
3. Big picture understanding: Overseeing the product development process is only a part of the PMs responsibilities. PMs need to be visionaries, and think about where the product is headed in the long term. This means, evaluating the competition, understanding the needs of the customer 6-months/1-year from now, and also how solving those needs will bring value to the business. Connecting these dots, and building a cohesive picture is mostly done by Senior PMs and Product Leaders, but participating in this process can be an amazing exercise in strategic thinking.
4. Stakeholder management: PMs interact with a range of stakeholders — senior management, engineers, designers, other PMs, and sometimes even specialised (non-tech) roles such as Finance/Legal/Privacy. Communicating across such a diverse group means that you should be comfortable speaking the lingo of each function. This will help you mitigate blockers, negotiate dependencies, and establish a consistent vision for your product across the board. For example — you should be comfortable discussing API details with an engineer, but also be able to explain (in simple terms) to a privacy counsel, how your product really works.
5. Understand how to read your product using metrics: Being a PM puts you in the driver’s seat for your product. But because you’re hands-off from the actual engineering/design processes, the only way to objectively understand the customer experience is by measuring it. Getting that big picture view of your product and making decisions becomes far more easy when you quantify the customer’s experience. As an example, most PMs regularly look at user engagement metrics for each stage of their product’s funnel to identify where things can be improved.
6. Leadership: In most organisations PMs do not directly manage their engineering team. However, the success of the product (and the team eventually) depends largely on the decisions and capabilities of the PM. Being strategic and planning ahead typically helps to give your teams a sense of confidence in the long term vision. Additionally, it’s immensely helpful for PMs to develop a bottom-up leadership style. While not stated on paper, the responsibility for team’s engagement and success is directly tied to the leadership role played by a PM.
7. Internal team op-mechs: Depending on the organisation, PMs may or may not have to manage the team’s backlog and sprints. But regardless of the actual work, PMs are responsible for the delivery of the product. I’m personally not a huge fan of complex roadmaps and nested feature tickets, but at the very least, PMs should be comfortable breaking a vision down to actionable steps, and effectively communicate them to stakeholders.

These learnings are my own, but I hope they helped you gain a little more clarity about life as a product manager, and the kind of learnings you can expect when transitioning from a different function.

If you’re looking to understand whether you should move to product management or not, I would recommend reading - Should I transition to Product Management?