This post is one in a series about the different relationships that a product manager has within their organization. Whether it be working alongside the product designer or engineer, or liaising with customer success and feeding information to the marketing team. This post looks at the relationship between a product manager and a software engineer.
For the purposes of this post, I am grouping all members of the engineering team under the one title of engineer. Within this you'll find software engineers (who write product focused code), infrastructure engineers (who oversee the platform the product sits on), engineering managers, software architects, front end developers and a whole host of other subdivisions. Collectively they are the techies, who do the technical bits to make sure that software products operate effectively and efficiently.
I once had a boss tell me to never use the phrase "a perfect world", because it just doesn't exist. And it definitely doesn't exist in software development, which means the people putting the inputs into the product development process (the product managers) and those who are delivering the outputs (the engineers) need to work closely in order to handle all of the challenges that they will face. Good engineer / PM relationships deliver good products. Poor relationships will deliver poor products. It is that simple.
It starts with a well written user story, that considers all the different scenarios that the engineer is going to come up against when they try to develop your product feature.
They don't expect product managers to know everything, but if you've thought about the different use cases and how they should be handled, you'll be forgiven for missing one obscure one. Miss five and they'll wonder what the point of you is if they have to do all the work.
Product managers protect the engineers from the business and it's ever changing direction. PMs will listen to stakeholders through 360 degree conversations, and only put work in front of the engineering team when a path toward feature value has been confirmed. Nothing worse than starting to build something only for the goal to change.
As with designers, engineers also like to problem solve and so as with designers you need to come to them with instructions on what to build that are detailed enough to give context and vision, whilst not being too prescriptive. Even engineers are creative and like to contribute to the end vision, rather than churn out exactly what they're told to.
PMs should also show an interest and ask questions. Don't be afraid to ask "what does X mean" when you hear something you don't recognise. Software engineering is full of abbreviations, third party tools, and processes that can be daunting to outsiders, but ask and nine times out of ten the engineer will be happy to share their knowledge with you. Engineers love knowledge sharing.
And most importantly, don't throw them under the bus. Don't over promise and then point fingers. Trust goes a long way, and for the engineers to trust the product manager they need to know that you've got their back and you're all part of the same team.
Ultimately, product managers are looking for a quality product, delivered on time, with minimal fuss, however software development doesn't work like that.
As such, most PMs will settle for good communication and solutions not problems. If something will take longer than anticipated then say something. If something is discovered to no longer work then tell us and suggest ways in which we can get around.
PMs need to communicate to the stakeholders so they need something to work with. Don't know what and don't know when won't cut it.
Depending on your PM, they might also need the engineer to speak in a language that they understand. As mentioned above, the PM will be looking to communicate out to customers or business owners, so they need to understand the challenges and solutions, but can only do so if they understand what's being said to them. Find a common language to speak so everyone knows what's being discussed.
This post is a short summary of the roles and relationships mentioned. It does not cover every element involved in product development and is intended to give an indication of how the roles might interact.