3 Things I’ve Learned as a Product Manager
I have been working as a product manager for two years. In this article, I want to share my insights and things that I’ve learned as a product manager.
Define responsibilities with tangent role holders
My professional experience includes work as a systems engineer and project manager. When I started work as a product manager, I noticed many overlaps between the three roles.
As a systems engineer, I was responsible for analyzing the system’s requirements and defining how to build the product. Also, I was responsible for determining the system’s design, infrastructure, interfaces between different modules, interface to external systems, and data flow.
I’ve learned that the differences between a system engineer role and the product manager role are:
- The product manager defines “what” needs to be developed. The system engineer describes “how” to develop the product in order to fulfill the requirements that the product manager has defined.
- The product manager defines the product’s vision in terms of the market and the user’s needs. The system engineer is responsible for defining its technical concept, including determining the development methodologies and system structure.
As Project Manager, I was responsible for creating a detailed work plan, defining milestones, allocating resources, managing risks, managing risk mitigation, and coordinating with all stakeholders involved in the project. I’ve learned that the differences between the project manager role and the product manager role are:
- The product manager is responsible for researching the market, the competitors, and the user’s needs. Also, defining the strategic plan for the product and plan the go-to-market. The project manager is responsible for following a specific project from point A to point B within schedules and resources.
- The product manager defines the product’s roadmap (quarterly, semi-annually, or annually), and the project manager builds its detailed work plan.
Of course, there are many more differences. In this part of the article, I want to emphasize my insights on this subject. In practice, I can perform the system engineer and the project manager’s tasks, and even some of the time, I did it. But I realized that any time I work on project management or systems engineering tasks, so it’s a time when I don’t work on my product management tasks that are assigned only to me. Thus, I learned that it is essential to define the product manager’s responsibilities with tangent roles, especially in areas that overlap between the three of us.
Build the vision and strategic plan of the product
I learned that creating the product’s vision and strategic plan assists me in fulfilling my role. The vision and strategic plan are the results of deep and continuous learning. I asked a lot of questions in order to be able to write the strategic plan. Here are some of the questions:
- Who are our current customers? What is our product supposed to provide for these customers in the future?
- Who are our potential customers? What value do we want our product to offer for them?
- What services does our product provide today? What changes in the service model will be in the coming years? What user’s needs does it answer?
- What impact are we interested in producing in the market? How will this affect the user?
- When will we apply new capabilities to the product? How will we do it?
- What are the main risks we anticipate today? How will we deal with them to reduce their impact (reducing the chance of occurrence or reducing their severity)?
My conclusion is that building the product’s vision and the strategic plan, as a product manager, is the best way to learn. Answering the questions formed the foundation of my product understanding, so whenever I had a dilemma and had to prioritize between abilities, I retained the product’s vision. So I could make decisions more intelligently.
Learn the managing product development process
Different organizations manage the product development process differently. At the beginning of my role, I spent time and effort to learn how it operates the development process. This has helped me reduce friction with R&D teams. I knew the methodologies, the daily, weekly, and monthly rituals and easily fit in with them. It created an alignment between us and created trust between the product group and the R&D group. I mention here some insights regarding this subject:
- Knowledge sharing: The product manager is responsible for writing the system requirements and user stories, defining the use cases, characterizing the user’s personas, and more. I learned how to share this knowledge with the development team by using the requirements management tools and perform a sprint planning meeting to share the data optimally.
- Knowledge writing: I have invested a lot of effort into learning the development and QA teams’ work preferences. For example, how much dive into details to write the system requirements and the user stories? How to divide the user stories? What is the scope of development for each user story? What scenarios to write in the acceptance criteria, and what can be given up (and not written)?
- Prioritization: One of the tasks of the product manager is to prioritize everything and all the time. Here I learned that user stories in sprint planning should appear in order of priority so that, first of all, develop what is most important.
- Assimilation of guiding product principles: During the sprint development, when the team members ask me questions, I learned that it is essential to explain to them the guiding principles of each user story. As a result, the development team managed to prioritize its tasks according to product principles.
- Assess impact: After deploying the new feature within the system, untreated bugs or use cases may be discovered. The natural tendency is to fix what is not working and then continue developing the next ability. Here I learned that it is important to estimate what the effect of that bug is? How many users are experiencing it? What part of the product does it affect? I recommend comparing the impact that will be achieved by fixing the bug versus the impact that will be achieved due to the release of a new capability despite the bug’s existence.
In conclusion, I have described here three insights I learned in my first role as Product Manager. I believe this article will be the first in a series of articles that will describe the insights and lessons I learned in the job. I think that we can learn in many and varied ways, and this is one of them.
Written by Maayan Galperin
