Working with Engineers For Product Manager — ‘Decoded’
If you are reading this, then don’t think you are alone trying to de-code how to work with engineers/ developers. Most Product Managers (PM) struggle with the same. Not that the engineers are difficult to work with but because engineering teams do not directly report into PMs. Also, they are the ones actually executing on PM’s vision that is why it is PM’s responsibility to have Engineering team on your side to execute your product ideas efficiently. You will keep going back on forth on estimates, timelines and bug fixing. When you spend a considerable amount of time working with them and they also contribute to the success of the product, you have to learn the best possible way to work with them.
A lot of times PMs do not have technical background. I have seen these PMs getting either intimidated or frustrated working with engineers. Whereas are some technical PMs get too much involved at programming level that makes engineers feel frustrated. Finding a way to work with engineers is a skill. From my experience, here are 5 things which have worked for me.
1. Empathize not only with your Users but also with your Engineers
As a PM, you practice empathy with your Users every time you try to solve problems for them. Use that same skill to understand how you can solve your developer’s problems to help him work better on your product. Connect with your best and not so good engineers often and understand what their work style is. Focus on following questions
· How they worked in the past
· What they liked or disliked in the past
· What worked for them
· What could be better
· What is their preferred method/tools of working
· What inputs they want before coding
The aim is to find an approach that will suit you and engineers to work efficiently.
2. Devil is in details
Developer’s time is gold. You have to provide as many details as possible to them so that they do not spend any time figuring out things. They should spend all their time in programming and finding best ways to implement product requirements. As a rule of thumb, try not to keep anything open ended in requirements (unless it has to). Write happy case scenario as well as elaborate on all possible corner cases. Specify error handing and all possible entry and exit flows. Along with detailed user stories, attach mockup / wireframes for functional requirements. You don’t need high fidelity wireframes always; you can use basic mockups also. Visual references control the individual interpretations of the text.
3. Let Jira be the source of truth: Beauty of agile is to keep accommodating changes until the actual delivery. We all use bunch of tools to communicate within the team. Change requests can come from other teams or stakeholders via meetings, mails etc. Similarly clarifications are provided over mails/ Slack / Jabber/ Webex Teams / in person. If the requirement has gone to product backlog and made it to the Jira / Rally board then make it a point to keep that as a source of thruth. Every time you receive a change request or clarification, you update it on Jira / Rally. Try to make that as a primary channel of all communication on requirements. This will give engineers the most updated ask and make sure all clarifications are found in one place itself.
4. Share the big picture with them early / Victor Vroom theory: Engineers are expert in their own world of coding. But having a context to what they are working for or the impact of what they have worked on will only get them more committed to the work. Share product vision with so that they know what future for the product is is and how they can code for the future keeping in mind. Share usage insights with them so that they know how the code that they wrote is being used and how it is helping Users. Invite them to design discussion and involve them while reviewing mockups to understand implementation challenges early in the game.
5. Coffee meeting: Remember that they are responsible to deliver the features you design. Create a collaborative relation with engineers not because you have to but they are closer to code and you will learn from about making your product technically sound. Be friends with Technical Program Manager / Engineer Manager (who is responsible for estimation / capacity in your teams). Don’t always connect with them for meetings with agenda and action items etc. Connect over a nice cup of coffee once a month and then you will find yourself enjoying collaborating with them soon enough (hopefully that feeling will be mutual!)
Cross- collaboration is an important skill for product managers to hone and it takes time. There are bunch of material available online (some courses also) to learn this skill. But I strongly believe that this skill needs to be developed. It takes time. You have to try and figure out how you can leverage your strengths to connect with your engineering team, find out what ticks them. Is it involvement in design sessions, is it knowing the product vision, is it data, no meetings at all or detailed user stories. This takes time and patience but just like your product, have an iterative approach. Have an approach of collaborative and test it, collect feedback on it and try again with improved approach. Every team is different, and every product is different. But there is always a better way to make things work.
