As important as strong Product Management can be for the success of tech company, the undeniable truth remains that Product as a discipline is nothing without its Engineering counterpart. I often say to PMs (only half-jokingly) that, outside of their family, there is no more special or critical relationship.

The ideal prod/eng dynamic is a cooperative, push/pull, yin-yang type thing -- two unique skill sets coming together, focusing on respective strengths, and cranking out useful tech. But that's the ideal.

Similar to Sales v. Marketing, or Architect v. Contractor, the Prod/Eng dynamic is one that is frequently fraught with negativity. This negativity, often the result of lack of respect, mistrust, or an imbalance of competency between roles/teams, can be the undoing of even the best conceived vision.

For that reason, fostering and maintaining a healthy interaction between the two is always one of my top priorities. While I can't boast of a 100% success rate, I can say with confidence my efforts were always worthwhile, making for a more positive working environment, happier people, and consequently, better software. Since people are involved, every situation has its unique dynamics and gnarly things to work through, but I think there are some core tenets that pay off universally.

1) Build a rapport.

Like I said, people are involved. Good product managers recognize this and act accordingly, getting to know their counterparts and connecting on a level other than the work at hand. If you're doing it right, you work together A LOT. Mind you, I'm not suggesting the need to besties, but having a personal bond does grease the wheels.

2) Do your homework.

Product managers often get dinged for not being technical enough, lacking the context for what is technically feasible, and/or asking for the moon and wanting it yesterday. While good PMs leave the technical aspects to the experts (read: Eng), they can talk tech intelligently, and have a feel for what can be done and when. This can only come by doing some digging, asking pointed questions (once, not more than once!), and generally immersing oneself in the (necessary) details. 

3) Bring 'em into the tent.

The relationship is prone to taking on a "sh*t rolling down hill" character, with engineers feeling like worker bees doing the bidding of the Almighty Product Owner. This is not only bad for morale, but it usually means the work suffers. With a healthy dose of discretion, good PMs involve and consult engineers at every phase of the software development lifecycle (SDLC) to promote a stronger feeling of shared ownership and higher-quality output.

4) Justify your opinions.

Product managers are paid to have opinions. Good ones can back them up. A mix of quantitative and qualitative data can work wonders in assuring stakeholders that the latest feature or change request isn't just a whim. Usage data, performance data, market/business reality, survey responses, recorded user testing, user interviews, etc. -- make a habit of gathering this info and including it in requirements. It's the foundation for trust and credibility.

5) Run efficient meetings.

Show me an engineer who likes meetings, and I'll show you ... one I haven't met yet. Good engineers are doers, and tend to prefer actively solving a problem rather than waxing poetic about it. By the same token, effective communication is paramount in getting things done, and done the right way. Good PMs are conscious of all of the above, only calling meetings when necessary, and making them count. Be prepared, on time, keep the discussion moving, end early if possible, and share recaps.

6) Stay focused.

Context switching kills. While I'm still a believer in an agile approach to most (but not all) development, there is a big difference between agility and volatility. Things break, ground shifts, requests stream in, but good PMs take steps to minimize disruption and number of projects that the dev team takes on at once.

7) Own your mistakes.

Mistakes will invariably be made in discovery, design, development, and delivery. In fact, if you don't make any, you might not be moving fast enough. Good prep and oversight helps identify them, and good PMs own them when they come up. The credibility you earn with your team(s) more often than not outweighs the egg on your face.

8) Celebrate wins big and small.

When in the thick of feature dev, bug fixes, system maintenance, planning, architecting, etc., it's easy to lose sight of the good things coming out the other end. A good PM make a point to recognize the effort and achievement of her team(s), whether it be a full-on release party, team lunch, or a simple shout-out in standup.

9) Let them hear it from the horse's mouth.

While there is often good reason to create a buffer between dev teams and the customer, good PMs make sure that buffer doesn't become a wall with no windows. Sharing unfiltered feedback, good and bad, gives devs critical insight into how what they're building is being used, and potentially provides the additional context they need to fix, enhance, and innovate.

10) Have your team's back.

There are myriad complaints a PM can have about her engineering counterparts (and vice versa, obviously) and I think I've heard (and said) them all. While I'm not suggesting grievances shouldn't be aired, I do think there is a time and place to air them. Good PMs don't bad mouth or blame Engineering in mixed company or in front of clients. They keep it in the family – take up issues with the individual, the team, or worst case, your/their manager.