Guest Post by: Hannah Kim (Mentee, Session 9, The Product Mentor) [Paired with Mentor, Patrick Hoffman]
Before my first year of product management, I had lots of preconceived notions about product management. These came from watching other product managers, reading books, attending meetups, and talking to other people in the tech industry about what product managers did. However, nothing could have really prepared me for the reality of actually being in the position. Once I landed in my first PM role, I learned a lot of unexpected lessons that helped me really understand the PM role and what a product manager could do to drive the product forward successfully.
There is a difference between being a reactive PM and proactive PM, which will make the difference in taking the team the extra mile. A reactive PM will set up/maintain all the necessary processes, ensure that product development is flowing along at a good pace, and respond to bugs/requests as they come along. Basically, they’ll check off all the boxes. However, a proactive PM will question and re-examine everything constantly to see if there is anything that could be improved or changed. They will always try to make processes more efficient, go out of their way to learn more about the industry and product, and constantly think about what they could do to improve the product for the users. They will challenge themselves and the team to work in smarter ways, ask more questions, and think about code improvement. It is important not to fall into the trap of being a reactive PM, which is very easy—especially with the many projects and tasks that a PM is usually involved in. The PM must stay focused on not just moving things along, but moving things along the right way, in ever-improving ways, considering the direction of the product, changing size of the team, tool/environment changes, etc.
Some might say that flexibility and juggling many tasks would be helpful, but the truth is, they are absolutely necessary to be a good PM. With shareholders’ requests, not everything can be carried through. There is never enough time for that. This is the reason that a PM must understand how to hear people out, fully understand pain points, and know when to grant, wait, or reject requests. With product development, things are rarely built exactly as estimated. Bugs come up, tests take a long time, code reviews are needed, merge conflicts occur, reviews from multiple shareholders might be required, etc. Being flexible with these factors and learning that nothing is ever completely final or set in stone—this is key to planning and factoring into decision making and timeline creations. PMs must be comfortable with ambiguity and juggling tricky situations. Prioritizing the product roadmap is a responsibility that is often cited, but a PM must keep in mind that they must prioritize many different tasks and projects for themselves on any given day. A PM must learn to be prepared for all kinds of stormy situations and march the product (and all connected teams!) forward, despite these factors.
I expected that it would take a few months to learn about a company’s product(s) as a PM. Little did I know that the learning would never really stop. In the first month, I learned a little bit about the industry and how to use the product. In the next two months, I learned more about the industry and some of the edge cases. But as the months went on, new information about the product kept coming up, which astonished me. I asked lots of questions in the beginning, but I started to slow down, slightly embarrassed by the fact that I didn’t know everything. This was a big mistake—no one ever knows everything about the product, especially when it’s changing all the time! It’s always in motion and I learned that it is impossible to know a product 100%. The best a PM can do, is to be the person who knows the most about the product and always strive to stay that person. The more interest and knowledge a PM has about the product and industry, the more information they will have to weigh in on product decisions. It is a mistake to think that learning about a product can ever stop. To help the team and be a good PM, one must continue to keep learning and asking questions about the product and industry.
Before starting as a PM, I assumed that developers and designers communicated solely through design programs with pixel perfect mockups and flows. I anticipated that they would never have issues with translating requirements, as everything would be laid out through apps like Zeplin. Little did I know, communication between the two parties was much more challenging and complex than what I had imagined. Firstly, mockups would never represent all of the nuances and details that the actual product would show. Conversations and presentations needed to come with or before the mockups. Second, it was key for the two teams to have discussions about the design decisions and reasoning. That way, if edge cases or alternative solutions had to be devised, the two teams could work together more fluidly. This would reduce the back and forth, save time, and ease the flow between the two teams.
From working with developers and designers, I learned that as a PM, it is key to facilitate the communication between the teams, and bridge any existing gaps. This makes the development and communication process more smooth and even. It also wastes less time—if all the kinks are ironed out early in the process, the actual product development runs more smoothly. In any case, PMs must become good at facilitating conversations and processes around the product, and not just focus on the product development itself. The better these go, the better the relationships between the teams. Plus, the development itself will be much smoother! Not to mention that the PM will be much more appreciated.
Though I had taken some programming courses, I didn’t have a full grasp of how complicated a product could be until partaking in all of the discussions behind a feature. This includes discussions about the business value, prioritization, edge cases, architecture, testing, etc. If every single shareholder were updated about all of these, they would drown in information. It is the PM’s role to carefully select the information that goes out to each of stakeholders, and communicate it in a way that makes it easy for them to understand it. Updating everyone regularly is an extremely important part of the PM role, because it not only unifies the teams, but it sets realistic expectations for releases and keeps the teams connected and involved in the development process. Also, everyone is able to better understand their team’s impact on the product, other team’s requests and logic, timelines, etc. By updating frequently and regularly, the PM is keeping everyone centered on the product and moving all the teams forward, together.
To be a successful PM, one must keep all of these things in mind. Communicating across teams effectively, being proactive and flexible, learning constantly about the product—it took me a year of managing a product to learn these lessons. I could never have learned them without actually being in the position, and now I understand how valuable they are.
Hannah Kim is a product professional with experience in the healthcare, finance, and nonprofit sectors. She is passionate about innovative design and product development. In her spare time, she loves to read, swim, practice yoga, and travel.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Check out the Mentors & Enjoy!
The Product Guy