Working with Cross-Functional Teams: Engineers

Empathize with the team you're working with

Engineers are essentially creating something from nothing.  They have to be very detailed oriented and think very logically.  They have to consider various implementation details, weighing trade offs, making judgement calls, and coming up with creative solutions to problems. As a PO you want to be technically curious and enjoy what they are doing so you can empathize with their work and you yourself should be working the same way with your work.  You need to be thinking about all the different scenarios and edge cases that might come up.  The goal with writing specs is to not have the engineer come back to ask clarification questions about the spec written.  If/when something isn't developed corrected it should be on the PO to step up and take responsibility because it is the PO's fault for not clarifying that.

Don't micro manage and micro pester

Don't pester devs too much throughout the day.  Pick up skill sets like learning SQL and how to run your own basic data queries and run analysis on said data.  Learn how to change copy on a website or go and find the id of a split test you're running.  These types of things will help you as a PO.  If you do have things try and batch them together to ask them all at once.  Don't check in lots either throughout the day, i.e. 3 times a day.  They know they have code/product they need to push out and if you're constantly checking in while to you it is something you're anxious to get an update on and get to the customer for them they may have another one or two projects they're working on and your ping is just another interruption or context switch that disrupts their flow and eats into their focus.  If you need an emergency solved sure, but status updates can and should be gathered at the very least from the daily stand up.  There you will find out what the team is working on and if there are any blockers/impediments from getting the work done on time within the sprint's time box.

Encourage ownership

Make sure you're making the dev team feel like they have ownership in the project instead of just feeling like they're executing something you're tasking them to do.  Sit down and explain what the product vision is and why you're prioritizing this particular need and solution so that they can provide their own input and ask clarification questions.  Doing this will also help the engineer/dev because while they're working they may see something say during implementation that just wasn't thought of by you and they'll be able to solve it on their own or with minimal outside input.