Warning: May contain traces of subjective personal experience.
I moved from Software Engineering to Product Management within my existing organization. This is not a ‘how to get into product management’ post. I don’t believe that you can teach that and I will explain why below. This is for anyone considering a move from Software Engineering to Product Management and wondering how it is on the other side. It is quite possible that you might have already made the switch. In which case, read on.
I was recently asked by someone for advice on how to get into Product Management. The person I talked to thought that what I said was helpful to them. So, I tried to remember what I had said and jotted down a few points, which I present here, in the hope that someone else might find them helpful.
You have to be okay with a certain lack of control.
As an engineer, your focus is mostly on technical outcomes and solving problems with technology. As a product manager, you rely on your team to solve problems.
In the initial days, you might feel this quite deeply. As an engineer, you might be used to immediate validation of the consequences (output) of your actions (code). As a product manager, you won’t see the effect of your actions until a lot later.
It might be tempting to prioritize a short-term quick fix to see the results sooner but you always need to weigh the cost of this decision against the long-term objectives and outcomes.
Your key deliverable is communication.
Most of your job now is communicating and/or facilitating communication. Product managers must know how to target the limited resources they have to the innumerable problems they are expected to solve. This involves making decisions from identifying problems to launching solutions.
Focus on answering questions for your developers, review documentation and specifications they produce, talk to people. You are now part of a company wide effort to make problem-solving processes more efficient. You are now part of the company’s infrastructure that enables the company to move faster.
You don’t have to solve all problems.
As an engineer, you were trained to recognize patterns. This will help you be a good product manager. As an engineer, you were also trained to solve problems using the patterns you detect. This could be a double-edged sword.
You will want to solve each problem but your role is to identify and validate if the problem is even worth solving. Sometimes, what you are attempting to solve is a symptom of the problem. Try to find the upstream cause instead of jumping to what comes naturally, solving.
You have to work with people.
Product management in a company of a certain size works on relationships. You need to build relationships with your collaborators and work across functions to achieve your product goals. Figuring out not just how to communicate with people but what motivates them will be an important way to influence decision making.
With code, it is much easier and quicker to demonstrate how your decisions will actually play out. As a product manager, you will need to collect data, build hypotheses, influence and persuade people to support your decisions. Just being right is not the magic bullet you might think it to be.
Learn to be comfortable with ambiguity
If you are a product manager or aim to be one, you have seen the following Venn diagram.
It is a popular simplification of the role because it is easy to read and easy to share. But, inherently, the diagram is an attempt at distillation and due to over-use, it has become a reduction.
You will almost never color each circle equally. You will often solve problems by focusing breadth-first, not depth-first.
I have done all three of the things in the diagram above with varying levels of incompetence. I have known enough about all three to make it work but I have not been an expert in any of them.
This level of multidisciplinary understanding helps you communicate across the different groups that help build a product. It also helps you see changes in one area and understand how they might ripple across the entire system. This is doubly important in a fast-paced environment because ultimately, it is your job as product manager to drive decisions that will help your product move forward.
This is also why I have come to believe that you can’t teach product management. You can’t teach someone to be breadth-first. You can’t teach someone to embrace ambiguity. A lot of the secret sauce of good product management is learned by application.
And that’s it. In this post, I have tried to summarize what I have observed in my move from Engineering to Product.
You can’t solve all problems and you can’t solve them on your own.
Your new key deliverables are communication and documentation.
Remember to take a step back from the problem solving phase itself.
Be comfortable with ambiguity.
Thanks for reading. Leave a comment if you found this useful or you want to share your experience or you just really want to tell me that I am very wrong.