In an ideal product development world, communications are seamless, specifications are clear, and product and engineering teams work without friction. Except, we live in the real world where life is messy, responsibilities overlap, specifications change, and the way teams interact can introduce friction.

Delivering the desired product outcomes and experience depends on a number of things going well. However the one attribute that has consistently risen to the top of this list is a healthy and strong partnership between product management and engineering teams. If organization leaders only care about the product launches or revenues or account bookings, they are looking at the “effect” and not the “cause”. Yes those metrics or outcomes (i.e. effects) are important, but what really fuels and drives these outcomes are the teams of product managers and engineers working together as ONE team, ideating, discussing, challenging, experimenting, troubleshooting, and collaborating (i.e. causes).

Product and engineering are 2 sides of the same product development coin. Would you ever use or accept half a coin?

So what can leaders do to positively influence healthy and strong partnership between product and tech? Here is a list of lessons I have learned over my experiences that continue to serve me well with this mission:

Include engineers in product decisions. Ideation and design are not just product management functions. Engineers often contribute valuable and timely inputs on constraints, choices, styles, feasibility that improve the early ideas and approach to building a feature or solving a problem. Product Managers should bring in engineers as early in the planning stages as possible. Collaborate early and often. An engineer with most knowledge in the subject area can lead product direction from the beginning of the product lifecycle. Ask what’s feasible and integrate the engineering team as best you can, because their insight will save arguments down the road. Then create realistic specs that everybody can deliver together.

No finger pointing. The dynamics, the environment, the ground conditions, the expectations are constantly evolving. Product and engineering should embrace this together so that any/all impact analysis and course correction is done jointly, building consensus and confidence across the product development organization. Finger pointing, hunting for scapegoats, sandbagging, unnecessary escalations are all signs of weak partnerships. Your destinies are tied together. You are passengers on the same plane. You are sailors on the same ship. You succeed and fail together.

Tech debt is shared problem. Product should not treat this as a problem created by the engineers. Engineers should not point to product and blame them for not prioritizing tech debt enough or often. The tech landscape (tools, patterns, frameworks) is evolving at a rapid pace and what you built 4-5 years ago is likely not good enough today. Together you must accept that your product or platform’s ability to interoperate with adjacent or external systems is a KPI and this requires you to embrace tech debt as a team.

Hack together. Some organizations and leaders believe that Hackathons are just for engineers. Leaders need to fix this right away! Hackathons (or hack days, hackfest, codefest, etc.) are design-sprint events targeted at creating or improving a product. As such you need all product contributors here: engineers, product managers, designers/architects, and data scientists. Any of these missing from the Hackthon means that you are probably not solving the right problem or not building the right experience or not harvesting the full spectrum of available data.

Support each other’s growth and learning. When an engineer gets an AWS certification, that is a win for the team because they will bring in even more engineering expertise to the mix. When a product manager takes a course in Ethical AI, that is a win for the team because they will bring new best practices and more grounded specs to the mix. Supporting others so that they can take time for learning not just furthers the individual’s skills and knowledge but also lifts the team’s and organization’s performance levels.

Sit together. Get to know each other. I cannot emphasize this point enough. More than a few times I have seen setups where the product and engineering teams are on different floors or different corners of the same floor. The outcome of this is unnecessary email, instant, or phone messaging which can be easily replaced with a rich and real, in-person conversation. Further, there are a variety of signals that a person’s facial and body language can communicate which emojis just can’t do justice to. Insist on video being a part of every conversation when in distributed setups (Zoom is my favorite tool here). For important design, demo, or launch discussions, gather at one location if possible. Sitting together also allows people to get to know each other better, which further increases the quality of relationships and interactions. Finally, lose those ugly cubicles!

Celebrate together. Make time to thank or recognize another team member for everything from helping you troubleshoot your programming error or improving a story’s acceptance criteria or helping you on a production support issue. Plan joint celebrations when you hit important milestones or wins. Tip: Create a “Recognition” slack channel for encouraging and elevating high-fives, fist-bumps, and celebrations.

Finally, ask for and give feedback. Do not assume that no news is good news! Ask each other whether your team is being a good partner. What are we doing well? What can be done better? How can we make it easier, clearer, faster? Share feedback (positives and deltas) with other teams and partners. Team retrospectives (run by your scrum master or Agile coach) are great but nothing works like real-time, post-meeting feedback. Circle back, follow-up on the status/progress on ideas/tasks you or your team committed to improving. This is the most important aspect of a feedback cycle and builds trust like nothing else.

I know it a long read but hope you are walking away with at least one actionable idea here. Please like or share the article and/or leave a comment with lessons/practices you have implemented to strengthen your product-engineering team partnership.