Product vs. Engineering Conflicts

Product and engineering always have tension. They both serve very critical roles in each organization, and each of the functions has similar but different missions.

Product wants to build more, better and faster products for customers. Engineering wants to build high-quality well-architected products customers love while maintaining a healthy codebase. Those things many times come in conflict with each other. That conflict between product and engineering is always there, and it should be. The important thing is to understand it exists and figure out the right balance.

One of the engineering managers I am working with came up with a challenge. They have a new product leader in their organization that is rubbing many people off. The product leader is dropping new requirements while still expecting the rest of the plan to be completed.

We talked about how to work with this new product leader and address the conflict?

Because this product leader is new to the company, the engineering manager does not know them very well.

So first step is to meet and get to know the person.

We are all people working with people, and it is vital to get to know each other as people before we jump on work-related issues.

The product leader lives in a different country, so there are cultural differences to consider.

Fortunately, the product leader visited the engineering manager's local office, so I suggested that as an opportunity to get outside the office and talk outside of work-related things.

If meeting in person is not possible, I still recommend getting to know the individual as much as possible who they are and what they like to do outside of work??

We also discussed meeting to gather information from the new product leader.

In that conversation, I suggested that the engineering manager ask questions and listen to understand where this product leader is coming from? What do they see from their perspective? What bothers them? What do they appreciate? How would they like to work?

Get as much information as possible and try to come unbiased as possible.

I suggested assuming good intentions and removing feelings and bias as much as possible. From my experience, most people are not bad or mean. Therefore it is best to come as positive as possible to the discussion.

The next step after gathering information would be to share what the manager observes from their side share and challenge things. For example, the product leader drops new requirements during the quarter after the work has been already planned out. That causes many frustrations and is ineffective.

We talked about sharing how the engineering org works, what works well for them and how ineffective it is to drop new requirements during the quarter.

I recommend challenging instead of saying no, especially if you talk with an executive you do not know very well.

Instead of saying you're mistaken, which typically creates a negative response on the other side, ask questions that will force them to think and explain how their approach works.

I also recommended giving options instead of saying no.

For example, when I faced unrealistic expectations from product, I presented alternatives and asked them to choose which features they want to be done out of a list.

Say yes, we can do what you want; we have several options such as a longer timeline, fewer features, etc.

Nice, but what if they say no, you have to do everything I asked for when I asked for?

That happened to me too, and my strategy for that is data.

DATA is king, and it is tough to argue with facts and very easy to argue with feelings.

In that case, I suggested looking at burndown charts and data of the engineering org velocity showing what the team can produce based on past velocity.

The product leader can say they want more, but data will show what is possible.

You can always dive deeper (depending on the need) to show what exactly engineers are spending time on. For example, how much time is spent on bug fixes, troubleshooting production issues, etc.

I had used that when I needed to convince the need to invest in architecture changes that will improve productivity and showed how much engineering time was wasted on things that can be reduced to improve productivity.

We ended the conversation with a few next steps this manager needs to take, and I am looking forward to hearing about the outcomes.

I would love to hear back from you about how you faced conflicts between product and engineering?