How to Transition From a Software Engineer to a Product Manager  by@danilafetisov

How to Transition From a Software Engineer to a Product Manager

image
Daniel Fetisov HackerNoon profile picture

Daniel Fetisov

Product manager with a software engineer soul

Intro

Until autumn 2019, my main focuses at work were:

  • Building software engineering teams.
  • Optimizing development workflows.
  • Finding the best technical architecture for products (especially for mobile apps).
  • Other cool dev stuff leading to help company and product managers create the best services in the market.

But that day X happened — at one moment, questions like "what we should build?" and "why?" started to appear in my head more and more often.

It was the eager feeling when you not only want to get the answer - you want to dig deeper and understand the essence, the genuine customer/company problem, and rigorously figure out a solution for it (in terms of product, not only engineering things).

Of course, it seemed so intriguing for me as I was passionate about leveraging my technical skills to help folks around solve their issues. I initially was questioning my colleagues (product managers) about things from their area.

But, unfortunately, answers couldn't saturate my curiosity. All details that I was getting were good, but I knew something was hiding in this abyss of product creation.

So finally, I made it - decided to change my career path and turn it into a product management function. Long story short, I got a technical product manager position at Yandex (Russia), Payment & Billing team (subscriptions and films).

Writing this topic, I want to send a letter to the version of me from the autumn of 2019 (and to everybody who’s experiencing similar feelings right now). This information should help you form realistic expectations of what you can face in the next couple of years.

Transition

In the beginning, you ought to be patient that you (again) get into the condition where you do not know many things: customer development, stakeholder management, qualitative & quantitive testing, strategy, feature prioritization, and so forth.

But it's only the peak of the iceberg. The most challenging thing would be wandering in uncertainty. Because there is no more way like "imagine how data streams would look like, work out an architecture, learn some frameworks and сode your thoughts."

Now you’re facing situations when you do not know precisely where to move. It's all about testing and reading market responses.

But such work is exciting, to be honest. After you get used to the new reality, where you work at the forefront with customers and their pain points, where you are responsible for business performance, you will catch the second wind and feel that it's exactly what you were looking for a long time.

Your Best Question

As a software engineer, you're familiar with the fact that the sooner you notice a bug in your solution, the cheaper it would cost to fix. Usually, it's related to solution architecture and code quality.

And for now, as a product manager, moving a few steps earlier in the software production cycle, the influence of your decisions on the final cost is much stronger! I think you already know what I want to say :)

Sure! Always ask the "WHY" question! We can also mention something like, "how can I validate my theory as cheapest as possible?". But the first one is more important — forget about "nice to have" features — dig into the essence of customers' needs and habits. And only after getting confident in causes, move to the next step - thesis validation.

You would definitely desire to build a solution as fast as possible, launch it to the production environment, and look after metrics and other data. But remember, it would cost you and your company a lot of resources. So initially, find an answer to the question "WHY," and keep moving to theory validation only after it.

Teamwork

I'm confident you’re used to having pretty long continuous work hours devoting yourself to writing the best architecture, optimizing app performance, and polishing a final solution. It will be better if you forget about such luxurious things of having work without interruptions.

Now "3D rule" is your best friend: do, delegate, or die. I mean, now you're driving a train and building rails for it simultaneously. And you're no more able to do it only by yourself, but it's OK! You have a great team around:

  • Marketing managers who can help you with defining product position among competitors and bring you to the market.

  • Data analysts are just wizards сasting spells to help you know everything about current customers. And remember, if you have some concerns in work questions about users, future features - you name it - data is one of the strongest arguments.

  • UX/UI designers - best friends, listen to them carefully, because after being a software engineer, in most cases UI decisions are your weaknesses. That's why you should ask designers whether they can share their work principles, it's worth it!

  • The engineering team, it's a two-sided coin. On the one side, you want to help folks perform better by leveraging your technical skills. On another - such interventions may even worsen the whole output result. So it’ll be better for everyone if you keep some distance. Use your skills to precisely determine the final point, not the way.

  • Your product managers - colleagues and superiors are just a treasure of knowledge. But questions matter. The best way here is to imagine where you want to be, what you want to do solving particular issues (acquiring a new set of customers, increasing some metrics, or just conducting user research), and share the plan asking for pointing the spots for growth. The result will inspire you.

To summarize this section, deep teamwork is one of the best things you will face moving to a product management career path.

Do Not Hesitate

As I said earlier, now you're driving a train and building rails for it simultaneously.

Company strategy allows you to understand in which direction you ought to be heading, OKR or such stuff - how to align with it, but you are the driver and the main responsible person for a dedicated product area!

So, don't hesitate, remember the cycle "build -> measure -> learn," discover how to be a leader without authority, and aim to a better future! You are on the right track!


Intro

Until autumn 2019, my main focuses at work were:

  • Building software engineering teams.
  • Optimizing development workflows.
  • Finding the best technical architecture for products (especially for mobile apps).
  • Other cool dev stuff leading to help company and product managers create the best services in the market.

But that day X happened — at one moment, questions like "what we should build?" and "why?" started to appear in my head more and more often.

It was the eager feeling when you not only want to get the answer - you want to dig deeper and understand the essence, the genuine customer/company problem, and rigorously figure out a solution for it (in terms of product, not only engineering things).

Of course, it seemed so intriguing for me as I was passionate about leveraging my technical skills to help folks around solve their issues. I initially was questioning my colleagues (product managers) about things from their area.

But, unfortunately, answers couldn't saturate my curiosity. All details that I was getting were good, but I knew something was hiding in this abyss of product creation.

So finally, I made it - decided to change my career path and turn it into a product management function. Long story short, I got a technical product manager position at Yandex (Russia), Payment & Billing team (subscriptions and films).

Writing this topic, I want to send a letter to the version of me from the autumn of 2019 (and to everybody who’s experiencing similar feelings right now). This information should help you form realistic expectations of what you can face in the next couple of years.

Transition

In the beginning, you ought to be patient that you (again) get into the condition where you do not know many things: customer development, stakeholder management, qualitative & quantitive testing, strategy, feature prioritization, and so forth.

But it's only the peak of the iceberg. The most challenging thing would be wandering in uncertainty. Because there is no more way like "imagine how data streams would look like, work out an architecture, learn some frameworks and сode your thoughts."

Now you’re facing situations when you do not know precisely where to move. It's all about testing and reading market responses.

But such work is exciting, to be honest. After you get used to the new reality, where you work at the forefront with customers and their pain points, where you are responsible for business performance, you will catch the second wind and feel that it's exactly what you were looking for a long time.

Your Best Question

As a software engineer, you're familiar with the fact that the sooner you notice a bug in your solution, the cheaper it would cost to fix. Usually, it's related to solution architecture and code quality.

And for now, as a product manager, moving a few steps earlier in the software production cycle, the influence of your decisions on the final cost is much stronger! I think you already know what I want to say :)

Sure! Always ask the "WHY" question! We can also mention something like, "how can I validate my theory as cheapest as possible?". But the first one is more important — forget about "nice to have" features — dig into the essence of customers' needs and habits. And only after getting confident in causes, move to the next step - thesis validation.

You would definitely desire to build a solution as fast as possible, launch it to the production environment, and look after metrics and other data. But remember, it would cost you and your company a lot of resources. So initially, find an answer to the question "WHY," and keep moving to theory validation only after it.

Teamwork

I'm confident you’re used to having pretty long continuous work hours devoting yourself to writing the best architecture, optimizing app performance, and polishing a final solution. It will be better if you forget about such luxurious things of having work without interruptions.

Now "3D rule" is your best friend: do, delegate, or die. I mean, now you're driving a train and building rails for it simultaneously. And you're no more able to do it only by yourself, but it's OK! You have a great team around:

  • Marketing managers who can help you with defining product position among competitors and bring you to the market.

  • Data analysts are just wizards сasting spells to help you know everything about current customers. And remember, if you have some concerns in work questions about users, future features - you name it - data is one of the strongest arguments.

  • UX/UI designers - best friends, listen to them carefully, because after being a software engineer, in most cases UI decisions are your weaknesses. That's why you should ask designers whether they can share their work principles, it's worth it!

  • The engineering team, it's a two-sided coin. On the one side, you want to help folks perform better by leveraging your technical skills. On another - such interventions may even worsen the whole output result. So it’ll be better for everyone if you keep some distance. Use your skills to precisely determine the final point, not the way.

  • Your product managers - colleagues and superiors are just a treasure of knowledge. But questions matter. The best way here is to imagine where you want to be, what you want to do solving particular issues (acquiring a new set of customers, increasing some metrics, or just conducting user research), and share the plan asking for pointing the spots for growth. The result will inspire you.

To summarize this section, deep teamwork is one of the best things you will face moving to a product management career path.

Do Not Hesitate

As I said earlier, now you're driving a train and building rails for it simultaneously.

Company strategy allows you to understand in which direction you ought to be heading, OKR or such stuff - how to align with it, but you are the driver and the main responsible person for a dedicated product area!

So, don't hesitate, remember the cycle "build -> measure -> learn," discover how to be a leader without authority, and aim to a better future! You are on the right track!

Comments

Signup or Login to Join the Discussion

Tags

Related Stories