post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

How to build a companion product and win user trust

mission statement

Deep dive: Crafting your product vision and mission

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Simón is a passionate product manager from Spain, with an entrepreneurship background, software engineering education, and broad management experience acquired working on different tech companies for more than 20 years. His last gig was on Flywire, which recently went public, and currently working at Voicemod, embarked on a mission to give every person its own Sonic Identity.

Principal Product Manager

Simón Muñoz

If I had to highlight one quality that can influence the success or failure of a product manager, communicating effectively with your engineering team would be high on my list.
In today&#8217;s article, we will see some tips that I have been learning throughout my career and that I think can be helpful to get the most out of that relationship.
Are you interested? Well, let&#8217;s get to it!
<h2>Understand your position</h2>
The first step in communicating effectively with your engineering team is understanding your position as a Product Manager. Engineers don&#8217;t work for you; they work with you. 
Engineering is not there to blindly comply with your demands. They are there to conceive and implement the best possible solutions to the problems and opportunities that you present to them.
You are a guide, not a foreman.
Read Simón’s previous article on how <a href="https://www.mindtheproduct.com/overengineering-can-kill-your-product/" target="_blank" rel="noopener">Overengineering can kill your product</a>.
<h2>Understand your situation</h2>
Your engineers have their own problems, aspirations, and fears. Sit down with them, together and individually, and make an effort to get to know and bond with them.
The information you get from that relationship will help you understand the team&#8217;s level of maturity, which will help you find the best way to interact with them and show where you will probably have to focus your time.
For example, with a junior product team, you may have to spend more time than desirable on the execution side. In contrast, a senior team can perfectly organize itself, which should free you up to focus on the more strategic part.
<h2>Start with the problem</h2>
This point may be the most important one in the whole article. You don&#8217;t present a solution to an engineering team; you bring them a problem to solve.
The best engineers won&#8217;t willingly accept implementing a solution if they have not participated in defining it. The engineers who do it are usually in consulting firms, not in product companies. And if you treat them like in a consulting firm, they will soon stop being your engineers.
<h2>Do your homework</h2>
Your mission as a Product Manager is to understand the problem so profoundly that you can introduce it to the team as clearly as if you suffer from it.
Do your homework. Get loaded with qualitative and quantitative information. Engineers have a sixth sense for detecting bullshit. If they feel that you don&#8217;t understand the problem, you will lose their confidence and involvement in the initiative.
<h2>Explain the why</h2>
At the beginning of the 20th century, Carl Braun was a successful engineer running a 6000 people company.
In a Farnam Street post, <a href="https://fs.blog/carl-braun-communicating/" target="_blank" rel="noopener">Carl Braun on communicating like a grown-up</a>, we read how he could fire you on the spot if he found out you had given an order without explaining why.
Starting with the problem is not enough. You have to demonstrate how solving this problem fits with the vision and strategy of the company. Your team also has to understand why you want to solve this particular problem and not any other.
Your team will do a better job the more they believe in it. Make sure you can argue your decision and create an inspiring narrative.
<h2>Define success</h2>
Your engineers want to know if their work impacts the organization. A huge smell that they are working in a feature factory rather than as product engineers is when you don&#8217;t define how to measure the success of an initiative.
We don&#8217;t measure success by the number of story points that the team manages to get each sprint or the number of functionalities that go out the door. We measure success by moving the needle on the metrics that matter to the business.
If you don&#8217;t obsessively communicate the importance of these and can&#8217;t get your team interested in them, you&#8217;re losing much of their value.
<a href="https://www.mindtheproduct.com/collaboration-across-large-product-organisations/" target="_blank" rel="noopener">Read A case study: Cultivating collaboration across large product organisations</a>
<h2>Get them involved early</h2>
Invite your engineers to phases of discovery that can be useful to understand the problem we want to solve. Keep them abreast of your ideas and listen to their opinions about them.
If your engineers hear first about an initiative when it is 100% defined, you are not doing a good job. The sooner you involve them in the problem, the easier for them to build the best possible solution.
<h2>Don&#8217;t isolate them from the outside world</h2>
We may think that part of our job as Product Managers is to protect the team from outside influences. It is not.
Facilitate meetings with the stakeholders involved in the initiative so that the team can do the best job possible. Avoid becoming the bottleneck that everything has to go through.
If an engineer needs to speak to User Research, let her do so. If a member of the organization interested in the initiative wants to talk directly with an engineer working on it, let her do so.
If you&#8217;ve done your job explaining the problem and why it&#8217;s important to solve it, your team should be able to manage itself and decide which meetings are essential and which are not. Only intervene if they ask you to do it.
<h2>Respect their time</h2>
Like you, engineers need long periods of uninterrupted work to be effective. Don&#8217;t interrupt them if it&#8217;s not strictly necessary.
If you work in an Agile environment, you probably have a daily meeting to meet and catch up. It will be strange that something is so urgent that it can&#8217;t wait until the next day.
In the same way, don&#8217;t create meetings from one hour to another unless it is to attack a fire. It is a strong smell of improvisation and not knowing what you are doing very well.
Take the time to think about whether it makes sense to bother the team. Many times these types of meetings come because someone above your rank has had a happy idea, and you want to be proactive in responding to it.
Your job is not to make managers happy. It is to make the team&#8217;s work impact the business.
<h2>Don&#8217;t hide anything from them</h2>
Sometimes plans go awry and don&#8217;t go as we would like. When that happens, we can urge to try to sweeten the situation and protect the team, trying to keep motivation high.
But people are not idiots and are perfectly capable of intuiting when something isn&#8217;t going well. If your team perceives it, but you act as if nothing is wrong, you will lose their confidence.
<h2>Be humble</h2>
Remember, your engineers don&#8217;t work for you; they work with you. Listen carefully to their opinions and consider their point of view.
You start with the advantage that you have been able to dedicate much more time to the problem than they have, but that does not give you the power to dismiss their ideas automatically. Furthermore, your team has a lot more context of how your product works internally and what is possible and what is not.
Listen, process the information, and argue why an idea may or may not work. Time spent listening to the team and answering their questions is well spent.
<h2>Conclusions</h2>
Learning to communicate effectively with your engineering team is undoubtedly one of the skills that you will get the most out of in your career as a Product Manager.
In today&#8217;s article, we have seen up to 11 different tips that you can apply to grease this communication:
<ol>
<li>Understand your position</li>
<li>Understand your situation</li>
<li>Start with the problem</li>
<li>Do your homework</li>
<li>Explain the why</li>
<li>Define success</li>
<li>Get them involved early</li>
<li>Don&#8217;t isolate them from the outside world</li>
<li>Respect their time</li>
<li>Don&#8217;t hide anything from them</li>
<li>Be humble</li>
</ol>
And not just with software engineers. We can apply any tips we discussed here to engage with other organization members.
From here on, it is up to you. Apply them and be successful, or ignore them and suffer the consequences.
<a href="https://www.mindtheproduct.com/tag/team-alignment/" target="_blank" rel="noopener">Discover more content on Team Alignment. </a>

Effective communication with software engineers

Simón Muñoz

Read more

Comments