How to build a healthy relationship between engineering and product

If you’re struggling to work productively with your product partner, here are four ways to build great rapport.

As an engineering leader, most people are surprised to hear that I love product managers (PMs). Most of my friends are PMs. I even married a PM! (Our wedding was a very well-organized three-day affair with a kanban board and weekly standups.)

I love working with PMs because the partnership between engineering and product leaders can be very powerful, when done right. A healthy product and engineering partnership is a thing of beauty. Your team has clear priorities. The backlog is nicely prioritized but still flexible enough to handle adjustments. Engineers feel challenged and engaged. Customers are happy with progress and continue to look forward to more improvements. Code is continuously being shipped to production. There’s a healthy push and pull between customer requests and technical investments. It’s a wonderful thing to be part of a well-oiled machine.

A productive partnership means having one team, and one roadmap. No matter what our individual objectives may be, our main priorities remain the same: ship products that customers want in a timely manner, and don’t burn out the team in the process. And while design is often the third leg of a productive squad formation and is crucial for ensuring product usability, this article will focus specifically on the relationship between engineering and product teams.

In order to build the trust necessary for a healthy relationship, both engineering and product partners need to do four things: understand what the other person does, understand their motivations, collaborate on a shared roadmap, and value one another as humans. Let’s break these down.

1. Understanding the roles of engineering and product

Engineering and product leaders often misunderstand what each others’ jobs entail, leading to confusion, at best, and million dollar mistakes, at worst.

Engineering’s role is to build reliable, performant systems that can address a variety of needs. Product’s role is to break down customer feedback into themes that can be addressed by features.

Both of these functions are crucial to building features that customers want. It can be tempting to disregard customer feedback as annoying, but engineering leaders absolutely need to care about what customers want because customers are the whole reason we are here in the first place! Customer feedback is vital to making sure that the right things are being built. Without valuable customer feedback, even the most beautiful piece of software is doomed to failure.

The key to a healthy partnership is to celebrate your partner’s strengths. While I regularly do customer calls, they aren’t my calling. As an engineer, I want to implement exactly what I’m asked to do because that’s what the customer said they wanted! I love working with a good product partner who is able to ask insightful questions to address what a customer actually needs to solve a problem, rather than what they ask for. A good PM is able to distill customer feedback into themes and problem sets, then translate those ideas into scoped features.

The inverse is also true. While PMs are great at talking to customers, having delicate performance conversations and managing team dynamics to balance engineers’ career growth and prevent burnout is often not an exciting prospect to them.

2. Understanding the motivators for engineering and product

Now that you have a clearer understanding of what the other person does, it’s also helpful to understand the motivators of the job. Why does someone do what they do? What motivates them to ask certain questions and push for something seemingly unrelated to what you thought you agreed on?

Understanding these motivators can help demystify why your partner may be pushing for something or digging their heels against what might seem like obvious progress. Use these motivators to dissect and communicate what the purpose is behind any blockers or requests that your partner may bring up, especially if it feels like their leadership chain may be pushing for something unusual.

If you run into friction, rather than saying ‘no’ outright, ask what your partner is concerned about and what’s driving the request. Is there a big customer pushing for something specific? Are technical investments not providing clear value? Where does something feel too slow? With more context around a request, you can collaborate on what success looks like and where it may fit on the roadmap.

Regardless of motivators behind a request, the goal is still the same: ship products that customers want in a timely manner, and don’t burn out the team in the process.

3. Committing to ‘one team, one roadmap’

The key to a healthy partnership is making sure that both engineering and product folks understand that there is one team, one roadmap. Having multiple backlogs for feature work versus technical investment work is a surefire way to ensure that engineers are overworked and feel undervalued. Maintaining one roadmap for projects ensures the team maintains focus on only the most important and impactful projects.

When you share a roadmap, be sure to use similar language in order to be able to measure success and impact of roadmap items. All items on the roadmap need to be:

• Tightly scoped and iterative
• Optimized to maintain customer trust
• Demonstrate clear and measurable value
• Contribute to the company priorities and align to the north star objectives

Both technical investments and feature work can be treated this way. Let’s break it down. 

All work must be tightly scoped and iterative

This one is fairly self explanatory for feature work, but can often be forgotten when it comes to technical investments. Engineering leaders should strive to make sure that technical work is as tightly scoped as possible with a bias towards proving iterative value. This can mean that work is not done ‘correctly’ the first time. However, particularly with costly platform investments, it’s important to treat internal teams as customers, provide proofs of concept, and break work into tightly scoped iterations that can provide value at each milestone. This is especially important when trying to collaborate with your product partner on putting technical investments on the roadmap. I love this blog post by Camille Fournier on how to think about product for platform teams and technical investments.

Customer trust above all else

Customer trust is our biggest currency. If customers don’t trust that we can provide fast, secure, reliable features on a regular basis, they will leave. Just because a feature is the hands of customers, doesn’t mean it’s ‘done’. Involve product teams in conversations about Service Level Objectives (SLOs) and hold them accountable for performance goals. Interview internal teams that are affected by technical debt and turn these frustrations into roadmap items. Agree on a common vocabulary to understand the risks and tradeoffs that come with making technical investments, and make a plan on how to iterate and provide value quickly.

Demonstrate clear and measurable value

It’s objectively easier to define customer value for customer-facing features, but technical investments need defined success metrics as well. If you maintain the one team, one roadmap mentality, all projects on the roadmap must have clear and measurable value in order to ensure the team is focusing on the most impactful projects. Providing metrics on how a technical investment will increase reliability, improve security, or increase developer velocity is a surefire way to engage with your product partner on building a roadmap together.

Collaborate on a shared business objective

A roadmap is meaningless if it doesn’t lead anywhere that customers want to be. A healthy roadmap has a clear North Star objective that is understood by all members of the team. Every project should be aligned with this objective. By collaborating together with your product partner on a shared North Star, all parties can agree when a project is taking away energy and resources from the team’s primary objective. This makes it easier to say no to special projects that inevitably have an outsized support burden and lead the team to burnout.

Remember the main objective of your role as an engineering or product leader is the same: ship products that customers want in a timely manner, and don’t burn out the team in the process.

4. Acknowledging the human behind the role

Last but not least, remember that you are working with humans. Life is hard right now, especially for folks from underrepresented groups. I’ve found that acknowledging the human behind the role is absolutely necessary to build a strong, trusting partnership.

Over the last few years, my product partner, Jarryd, and I have supported one another through BLM, AAPI hate, and a global pandemic. We’ve trusted that the other person could support the team when we needed to step away because life was happening to us.

This also meant we could freely share our frustrations and pressures from our respective leadership areas. This added more context to the priorities we held separately and helped the other person understand why someone might be pushing for something on our shared roadmap. By collaborating openly, we often could agree on what the most important priority was and where it belonged on our shared roadmap.

Reflections

It’s not unusual to have friction between product and engineering folks, but this friction can be a healthy push and pull. By understanding the other person’s job, their motivators, collaborating on a shared roadmap, and seeing one another as people, engineering and product leaders can forge a strong partnership to deliver features customers want in a timely manner without sacrificing the health of the team.