How I Moved From Engineering Into Product Management [Mind the Product]
What does it take for an engineer to become a product manager? Certainly, there are many ways to achieve this. Here I’ll explain how I did it, and I’ll share my personal experience of the process so that you can know what to expect from this transition.
If you’re considering changing from engineer to product manager, you’re not alone. Product management isn’t just for business and marketing people. You’ll be a good candidate as a product manager if, for example, you already do some of the following:
- You don’t accept new features or tasks as they come. Rather you question why they’re useful, and try to understand the problem a feature is trying to solve
- You go beyond developing a solution and like to be involved in the definition of the solution itself, giving your perspective and suggesting appropriate changes
- You care about quality. It’s not just about developing a feature, you also make sure that is robust enough, so it doesn’t cause a bad impression
- You like to be aware of what the customers think, and even to be involved in conversations with them in order to get direct feedback
- You’re curious, and you like to know the next feature on the roadmap to be developed
- You don’t mind talking with other stakeholders
- You’re used to aligning with other teams to ensure appropriate timing, and that a good solution is built
Learning the Basics
I used to be a QA engineer. That meant that I was already used to analyzing requirements, understanding problems and thinking about possible corner cases. Of course, product management is much more than these things, so the first thing I did was to look for some training materials.
Since I wasn’t completely sure if this was the next step I wanted to take in my career, I looked for courses that wouldn’t require a big economic investment. I started by looking for on-site courses in my city (Barcelona), but at that time (2017) there were not many available and economically affordable options, so I decided to look for online options. After some research I decided on a couple of them, though there are many other good courses available:
- Coursera: It has a specialized program called Software Product Management. It’s a training course that combines videos and exercises. It allows you to work at your own pace, which is very useful for people with a busy agenda (like it was my case). It doesn’t require any previous experience and you get a diploma once you finish the course.
- LinkedIn Learning: a LinkedIn Subscription gives you access to lots of product management-related videos. These helped to complement what I was learning already from my training program.
Real-Life Experience
The courses helped me to understand the basics of product management. The next logical step was to understand how product management worked in my company (Oracle NetSuite). For me, it was clear that it would be always easier to make the transition to product management within the same company, rather than start from scratch at a different one. I wanted to take advantage of the knowledge I already had about our product.
I asked the product manager on my team for regular meetings so I could get direct feedback about his daily job. As an output of all these meetings, I ended up building a document summarizing the different tasks of a product manager during the product lifecycle. I also managed to attend SuiteWorld, Oracle NetSuite’s annual conference for the NetSuite community, as a note-taker for the product management team.
Lastly, since my company was having a hackathon to explore new ideas (something we try to do every year), I took the opportunity to participate in one as the product manager on my team. During that week we developed an idea using Design Thinking.
Applying for the job
After a year of preparing myself to make the transition, I felt I was ready to start applying for a product management job. I asked human resources if there were any open positions within our company, and luckily for me, there were three of them.
I decided to apply for a product owner role. As you may know, some companies divide product management work into product manager and product owner roles. Usually, in these scenarios, the product manager is more customer-facing, while the product owner is more aligned with the development team. A product owner is in contact with the team and more focused on writing the requirements for them, while a product manager acts as your customer (from whom you gather all the requirements). I thought it would be better, coming from engineering, to start as a product owner. I thought the change would be less disruptive and I’d have a smoother transition.
I remember the interview process was a long one (four interviews over a month and a half). I did some research about the main questions to expect and prepared a document that summarized all of them. And, since the position required some accounting knowledge, I started to take some relevant courses on LinkedIn Learning. These courses, plus preparing the answers to all the questions, plus my own research about the product, helped me to get the job.
First Days: Overcoming Impostor Syndrome
As with every change in life, you need time to adapt to a new role. This is not easy. You need to stop worrying about the development process and start to focus more on the requirements itself. It’s no longer about the HOW. Now it’s about the WHAT and the WHY. Having said this, it’s perfectly normal to feel impostor syndrome during the first days or weeks (or even months).
I remember that my first weeks as a product manager were stressful. Not because of the job itself, but because of all the pressure I put on myself. This was my first opportunity as a product manager, so I wanted to make sure nobody had doubts about me. To overcome this feeling, I started to invest a lot of time in becoming the product’s expert (extra courses, reading documentation, and so on). What did I learn from it? Well, that there is nothing you can achieve in a short period, and becoming the product expert requires time and patience. I stopped pretending I knew it all and started to be more transparent and share all my doubts with my product-manager colleagues and with the team.
After some weeks in the new role, the impostor syndrome feeling just disappeared.
Managing Time and Information
As a product manager, you need to interact with a lot of people (developers, designers, technical writers, other product managers and so on), this means that you have a lot of meetings during the week and that you handle a lot of information. Being organized is crucial.
I was already using some tools to ensure I was making the best use of my time. These are the two tools I use the most:
- To Do: It’s from Microsoft (and previously known as Wunderlist). I use it to write down any new ideas that I have, and also to prioritize the tasks that I need to close. Every morning I put my list of tasks in order, and start going one by one and closing them (or adding new ones). I love it because it is the simplest To-Do list you can to find.
- One Note: Also from Microsoft. I use it to put in order all the information I get from my different meetings. I usually create a Notebook for each person I have contact with and add a new entry for every meeting we have. This way I make sure I make the best of my meetings, and that no information is missing.
Requirements: How Detailed?
Writing requirements for the team can be challenging when you come from engineering. You’ll see that once you start writing your first task, it’s difficult to avoid being too detailed.
In my case, coming from QA, I couldn’t avoid thinking about lots of corner cases. This is “analysis paralysis”, and you should try to avoid overthinking the solution. I’ve found that, to avoid this, it’s crucial to understand the user you’re creating for. Put yourself in your customer’s shoes. You can ask yourself: Is this corner case something that the user can actually end up doing? You’ll see that in most of the cases, that corner case you were thinking of is something that most probably will never happen. And you always have the option to include it in your backlog as a “nice to have”.
When working in Agile, I’ve found it’s beneficial not to get too detailed when defining the acceptance criteria of a user story. This is true in the majority of the cases, but in my experience, it also depends on the expertise your development team. You may find yourself in a situation in which you’re also the expert of the team in terms of the HOW. In this situation, I think it’s okay to be more detailed when defining the acceptance criteria, to make sure nothing is missed. With time, as the team gains expertise, you can start reducing the level of details you provide, so that the team starts owning more and more the HOW.
Conclusions
At the end of the day, the transition from engineering to product management requires you to change your mindset about product development, and see it from a different perspective. It’s not about focusing on developing new features now, but about knowing which ones should be done first (prioritization), how they should look (design), how they should behave (usability), and thinking out of the box to come up with good solutions (creativity)… All of this done always with a customer-centric approach and validating everything you do so that you make sure you create something that will really help to solve a problem. Sounds challenging, doesn’t it? If you’re really considering making this transition, I encourage you to go ahead! You won’t regret it!
The post How I Moved From Engineering Into Product Management appeared first on Mind the Product.
Source: Mind the Product https://www.mindtheproduct.com/how-i-moved-from-engineering-into-product-management/
Post a Comment