How to communicate with developers as a Product Manager

developers communicationThe engineers love to have lots of details. So it’s a good idea to be very detailed when talking to engineers or emailing them. The engineers are always thinking about software and how what you’re saying may or may not work. What happens if the app doesn’t have connection to the internet? What would be the error state if something goes wrong on this page? What happens when no data is available to display on this page aka empty state?

The clearer your communication is the better. You’re bound for failure If you’re not detailed or clear enough in communicating with the engineers and sending them feature specifications. They love to get the details to know they are working on the right product. Which features are hard and which are impossible? Set the right expectations and be prepared to answer these questions.

Be a good listener and have empathy to listen to their feedback
Don’t rush the developers without fully understanding the technical challenges and long term impact. Don’t come up with all the concepts yourself or with the designer and then just hand the completed requirements to the engineers to code. Always provide engineers with the opportunity to give you feedback. If they spend the whole day coding doesn’t mean that they don’t have any good ideas or opinions. Actively involve them in day to day discussions. Product perspective not even the engineering one. Is this a good idea? Would users use it? During planning meetings tell what’s coming up next and give them opportunity to tell what they think about it.

Communicate clearly the vision of what expected of them.
Throwing away any work done by developers is extremely painful. Present your ideas with confidence. Make sure your stuff looks beautiful the developers should be proud of what they are making. If something goes wrong on the communication with the dev team it’s your fault. If they developed something incorrectly it’s because you provided the wrong specs.

Be wary of technical debt and be prepared to describe future of the feature
How the feature would look like in its ideal state and how it looks as MVP are two big differences. It will help them to plan out how it’s going to be done technically in the future. It’s something that needs to be reworked or refactored later as a result of not doing it properly/hacking the first time. Impending work. Engineers hate it because they have to deal with it. It’s a good idea to trust the engineers option on how to do the right thing first. Develop something scaled out to not do it later.