Product Manager’s Life by Former Software Engineer
Being a product manager for 8 months, I would like to share my experiences on how it went. Hopefully, this blog can be useful for software engineers who are seeking for product manager roles.
What did I do before becoming a product manager?
Simple answer. I wrote a lot of iOS/Android/API code. Besides that, I have some team lead, SCRUM Master, and Product Owner experiences.
What are my new responsibilities?
It took me a while to comfortably talk about what I do as a product manager. Here is my definition. A product manager is responsible for:
- Understanding customers’ problems
- Working with cross-functional teams to build products/features
- Making sure the products/features are solving the problem
I will share my experiences and learnings from those three areas.
#1 Understanding Customers’ Problems — Make sure to ask ‘WHY’
This is the area that I am most inexperienced at. My job is to figure out problems in the finance industry. To make it worse, I had almost zero knowledge on finance industry before starting my current job. So, how did I find out what the customers problems are?
I had multiple face-to-face chat or conference call with our customers. In the beginning, I almost had zero clue what they were talking about. I was so clueless that I couldn’t even come up with questions to ask. Luckily, our company hired industry experts to help the team understand finance industry. As I was gaining more knowledge through more customer facing meetings & experts advices, I was able to pick things up, and get more active in those meetings.
A key thing I noticed here was to ask ‘Why’. The customers are usually good at talking about what they are doing. They don’t usually talk about their problems. Once I am done listening, I follow up with this question: “Why are you doing that XYZ task?”. You may think that this could be rude or make yourself stupid. However, the thing that most customers said after hearing that question was “Oh. That is a good question.”
By asking ‘Why’, you can get people to talk about actual problems. Then, you can easily follow up with the some other questions that will get more insights out of customers’ problems.
#2 Working with Cross-functional Teams to Build Product/Features — Promise & meet the delivery date
I was pretty confident in this area. As a software engineer, I got to work with UX/UI design, product management, marketing, and any other teams who are involved in the same product.
My company is running SCRUM. Most of teams I previously worked with did not really finish sprints, except for the one team that I led many years ago and current product engineering team in the company. The main problem I saw was that the most companies/teams did not really have motivation to meet the scope. Why do you have to run SCRUM if you don’t have to deliver anything?
However, my company’s vision was clear. When we meet the delivery date, we build trust to our customers. Basically, before we delivered features, we promised customers with delivery dates after doing rough estimations. This helped product development team to set clear expectations on what we are delivering.
It definitely took a while for the team to get the habit of actually delivering everything planned for a sprint. However, we now have constantly delivered features on time for more than 6 weekly sprints. As a result, our business team made a significant progress on making deals with our first pool of customers.
#3 Making Sure the Products/Fetaures Are Solving the Problems — Get the feedback ASAP (before building anything, if possible)
As a software engineer, I pushed out features, and looked into user analytics to make sure users are actually engaging with the new features. That was one (out of million) way of knowing if the features are actually solving users problems.
However, I found out that there are better ways of doing this in earlier stage. My current company has few customers who are willing to provide us direct feedback on our product. We used prototype to get feedback if we had a chance. Our customers were able to grasp what we were trying to build, and we improved features based on the feedback.
Using prototype of get feedback definitely help us save time. We were able to improve product before we even started development of features. When features were ready to build, I was pretty sure that it would provide values to our customers. This could also be a key things for any startup. It will help a lot of development time for small resources.
Obviously, this wouldn’t be possible if we did not have those engaging customers. However, there are many different ways to get feedback early.
Conclusion
It was not an easy decision to switch my role after working as a software engineer for more than 10 years. However, I am glad that I took this role. I wanted to become a software engineer because I wanted to build awesome products. As a product manager, the goal remains the same. I am just building more skills that will help me build even better products.
I hope this helped for current software engineers who want to become product managers.