TLDR
In this article, I would like to emphasize the importance of good communication with a product manager (PM). Drawing from my own experience, I provide some methods that have helped me in communicating with PMs. These methods include:
Understanding the context behind requirements.
Controlling the level of detail in communication.
Discussing various trade-offs during development with the PM.
Paying attention to details during communication.
Intended Audience
I wrote this article with the following readers in mind:
Engineers frequently need to communicate with non-engineering roles in their work.
Professionals who frequently interact with project managers in their work.
Individuals who believe that engineers should not be in opposition to PMs and want to change this perception.
Disclaimer
Most of the PMs I have encountered have been exceptional individuals who have left a deep impression on me with their abilities in product direction, prioritization, and stakeholder management. Occasionally, they make decisions that I cannot comprehend, but it is likely because I lacked the background information or they faced unreasonable demands, such as being responsible for multiple projects or even business-related tasks. Therefore, if your situation is different, the content of this article may not apply to you.
Why Communication with PMs is Important
For me, the importance of communicating effectively with PMs can be summarized in the following points:
Resource support: PMs usually have access to many resources that can assist you in achieving your work goals, such as releasing new features or solving problems. Through effective communication with PMs, you can obtain the necessary support to improve work efficiency and outcomes.
Career development: PMs provide valuable feedback from their perspective during performance evaluations, which is crucial for career development. They can observe and assess your work performance, providing useful advice and guidance to enhance your skills and professional growth.
Learning opportunities: PMs possess extensive knowledge and experience from collaborating with different departments and stakeholders. By engaging in communication with PMs, you can learn valuable knowledge and skills from them, understanding the planning, execution, and delivery processes of entire projects, thereby enhancing your professional competence.
Building trust relationships: Establishing a strong foundation of trust with PMs is vital for your work and career development. When there is a basis of trust between you and the PM, they are more likely to prioritize sharing problems and opportunities with you, working collaboratively to overcome challenges and achieve goals.
In summary, effective communication with PMs is crucial for your work outcomes, career development, and personal growth. By building a relationship based on trust, you can gain more support, learning opportunities, and advancement in your career, while also laying a solid foundation for future collaborations.
Practical Methods
If you also agree that good communication with PMs is important, here are some insights and practical methods I have found useful in communicating effectively with PMs:
Always ask about the reasons behind the requirements.
At the beginning of the book "What's Your Problem?: To Solve Your Toughest Problems, Change the Problems You Solve," there is a story:
The residents of the building often complained about the slow speed of the elevator. Suppose you are the person in charge of maintenance, how would you handle it?
You might choose to work on speeding up the elevator to meet the residents' needs.
However, the person responsible for maintenance, who possesses the ability to investigate problems, carefully observed and discovered that the real issue was not "the elevator is too slow," but rather "passengers feel bored inside the elevator."
Therefore, he decided to add mirrors inside the elevator. Since then, the residents have been satisfied with the speed of the elevator.
I believe a good engineer, in addition to passively receiving requirements from the project manager, should also ask about the reasons behind the requirements or what problems the requirements are intended to solve. I have also noticed in my daily work that we occasionally encounter seemingly unreasonable requirements, and naturally, we would ask for more reasons behind those requirements.
But when facing some seemingly reasonable requirements, we may accept them more naturally without immediately questioning why. However, regardless of the reasonableness of the request, exploring the reasons behind the requirements is equally important. Because even reasonable requirements may not be the best solution to the problem the project manager wants to solve. For the product manager, engineers like tools, and the project manager's job is essentially to coordinate the smooth operation of various tools to achieve a certain goal. But what exactly this tool can do is known best by the tool, which is the engineer themselves.
Controlling the details of communication
When we engage in communication, controlling the details is highly important. I believe that using a top-down approach to convey information is very helpful in controlling the details. That is, when delivering a message, we should first provide an overall concept, then mention the key points, and gradually delve into the details as needed.
In addition, during communication with PMs, we need to pay close attention to their reactions. Doing so allows us to better understand their level of understanding and background knowledge. If they show a lack of understanding of certain details, we can provide relevant background knowledge, explain using specific examples, or, if necessary, try to abstract the details and describe them conceptually.
Lastly, if we feel that the other person may need more details to understand our content, the best way to respond to this situation is always to ask directly. By doing so, we can determine their knowledge level on the relevant topic and decide whether it is necessary to provide more details.
Involve your users in the trade-off
This argument comes from the book "The Pragmatic Programmer." During the software development process, we often need to make various decisions, and in this process, I believe it is important to constantly confirm trade-offs with the PMs.
First, the relationship between code quality and development time is not a straightforward straight line. Going from 0% to 60% completion may take a week, from 60% to 90% may take another two weeks, and finally, from 90% to 100%, it may take another four weeks. In communication with the PM, we should clearly express this relationship so that the PM can understand the importance of making trade-offs between time and quality. Allowing the PM to have more context about the desired level of detail for the project ensures a suitable balance during its progression.
This consideration also stems from the fact that most of the time, we don't need to achieve software development perfection; being good enough is sufficient.
Great software today is often preferable to perfect software tomorrow.
Furthermore, if possible, when communicating with the PM, it is beneficial to list multiple options and analyze the advantages and disadvantages of each. This provides more comprehensive information, enabling the PM to make informed decisions. Additionally, listing multiple options helps stimulate innovative thinking and find better solutions. Finally, I have also found that listing multiple solutions helps both parties have a clear understanding during communication.
For example, let's say I receive a requirement to "sort a list of products." In this case, I would start with the simplest solution and list at least two or three options to discuss with the PM. The options could include:
Sorting based on the product's purchase count. This solution lacks personalization and may result in a suboptimal user experience, but its benefits are evident. Also, results, in this case, can be easily cached at various stages.
In this scenario, there could be more options available. For instance, the following two options may differ in terms of future development flexibility (although it's also possible that we won't revisit this project in the short term):
Implementing the sorting logic directly in SQL.
Implementing the sorting logic in the backend.
Based on historical user data, use data analysis methods to identify the data most relevant to conversion rates and use that data for sorting.
Constructing a recommendation system using machine learning techniques.
- Here, more options could arise, such as using managed service recommendation systems (e.g., GCP Vertex AI, Miso.ai, or Appier) or building our recommendation system. The benefit of building our system is having more customization options in the future, but it may come with a higher time and cost investment compared to other options.
Details to pay attention to in communication
Similarly, "The Pragmatic Programmer" also mentions several details to pay attention to in communication:
First, we should plan the content we want to express. Write an outline and ask ourselves, "Does this convey what I want to express?" This helps organize our thoughts and ensures smooth and clear communication. Secondly, we need to understand our audience. Different people have different needs and interests. Before communicating, it's important to understand their background and level of expertise to tailor our message to their needs. Finally, choose the appropriate timing for communication. You wouldn't want to send a long message that requires careful thought to reply to right before the end of work on a Friday.
Choose the right time and place based on the context and the recipient's state. Ensure that the recipient has sufficient attention and focus to listen to your information.
Additionally, the WISDOM principle can be used as a guide for communication. WISDOM stands for:
What do you want them to learn?
What is their interest in what you've got to say?
How sophisticated are they?
How much detail do they want?
Whom do you want to own the information?
How can you motivate them to listen to you?
As part of communication, we also need to dedicate 50% of our time to being good listener. The simplest principle is: if you don't listen to others, they won't listen to you either. We should pay attention to others' requests and listen to their questions. This helps establish a good communication atmosphere and increases trust, understanding, and cooperation between parties.
But More Importantly
Ultimately, empathy is key.
In the end, I believe empathy is crucial when communicating with a project manager (PM). Those who possess empathy naturally learn how to communicate effectively with the PM in every discussion.
And keep in mind that nobody wants to be a lunatic. This is one of the most important lessons I learned from "The Psychology of Money." Whether it's in investing or collaborating with others, we often fall into the trap of black-and-white thinking, viewing people who have different opinions as wrong. However, in most cases, it's simply because our background knowledge, prioritization, or goals have not aligned yet. Based on my experience, if we can clearly express our needs and expectations, the other party (PM) often tries to understand our perspective and seek mutually beneficial solutions.
However, I want to emphasize specifically that as engineers, we should avoid using emotions as a means of communication. In my personal experience, I've seen that software engineers hold certain privileges within a company. These privileges often lead them to use emotions to force other collaborators to comply with their demands. However, this behavior is not right. We should avoid using emotions as a tool and instead strive to understand what we truly need and how to express it rationally and clearly. Conclusion
Conclusion
I believe effective communication with a PM is important for an engineer's work output, career development, and personal growth. I also believe that I have benefited greatly from maintaining a good relationship with PMs throughout my career. However, I must admit that communication errors can still occur at times, despite my efforts to maintain information transparency. Even though I make multiple written confirmations of what needs to be conveyed, there may still be instances where some details are overlooked. Nevertheless, I have confidence that my ability to communicate with project managers continues to improve, and this progress will contribute to becoming a better software engineer.
Acknowledgment
Cover Photo by Lala Azizli on Unsplash
Photo by Morgan Housel on Unsplash