What if two product managers disagree on something and can only agree to disagree?

I received the below great question a few days after my Art of War for Product Managers and High-Performing Professionals.  I thought you might be interested in the answer as well.

What if two product manager colleagues disagree on something and can only agree to disagree and cannot come to a resolution, what do you do afterwards?

I go into the: who, what, where, when, why and how in more detail in the IT Professional Development Toolkit product.

One recommendation is to find the common-shared goal among the three product manager.  Continue to bring the discussion to a higher-level until you get some type of agreement.  Oftentimes people are arguing over a detail or specific solution.  When people of like-minds and professions are arguing – it simply means that they are talking ‘at’ the wrong level.  It’s merely an indicator that the parties are looking in the wrong place for the answer.  When you pop-up the discussion to the next higher level, things tend to work out.

One example:   One product manager (Product Manager 1) states that this release needs to have a Drag-n-Drop feature in this release.  The other product manager (Product Manager 2)  is adamant that it cannot be included in this release because the code is from a 3rd-party company.  There simply isn’t enough time to get the legal authorization to change it on our own, or get the 3rd-party folks to change it.  Product Manager 1 knows that a high-profile client will leave the company and product – if we don’t but this feature in this release.

This is what I did:

1)     Paraphrased our common product goal:  Release the product with high-quality, on-time and with significant enhancements that clients will be very pleased with.

2)     Get everyone agreeing to the high-level common goal.  Get everyone on the same page with the company vision and mission.

3)     Try to kick-up the discussion by understanding “why” this change is needed in the first place.  I asked the team ‘why’ this change is needed.   Product Manager 1 says – “The client needs create a project plan from some of his other project folders.  He doesn’t want to start from scratch.  He wants to drag-n-drop his selected folders to create the new project.  He doesn’t want to re-invent”

4)     I paraphrased, “So, let me restate to make sure I understand.  You’re focusing on what the client really wants, which is what we all want.  And what the client wants is a method to import files from a previous project into his new project file.  He doesn’t want to start from scratch.  He wants an import function.”  (First understand and then be understood — from Steven Covey’s 7 Habits of Highly Effective People).

Product Manager 1 – “Yes – they want an import function”

I asked Product Manager 2: “I think we already have an import function, don’t we?  It’s not using the drag-n-drop feature.  But it accomplishes the essence of the goal.  It gets the job done, doesn’t it?”

Product Manager 2 nods, “YES – it’s called IMPORT.  You can browse your directory and click on the folders to drill down.  You can even drill down to the documents and specific lines to import.  Once you have highlighted the areas that you want imported, you just hit the IMPORT button.  You can even include everything and then mask-out things you don’t want to include (which are a faster way to important large amounts of data).”

Product Manager 2 is happy, “Really?  That’s even better than what they asked for.”

Product Manager 1. “And it’s already in the product that they have today.  They don’t have to wait until the next release….”


The stale-mate was caused by getting too caught in the details.  Product Manager 1 wanted to give the customer exactly what he/she was asking for; customer was asking for a specific solution (drag-n-drop) to answer their problem; Product Manager 2 was narrowly focused on the impossibility of that one solution (drag-n-drop).   By focusing on a single solution, we were in stalemate.

By disengaging from the specific details on HOW something will be accomplished, and focusing on exactly what is trying to be accomplished – most people can find a common, shared goal.  I talk more about how to use paraphrasing, listening techniques, negotiating techniques and finding the common ground in the IT Professional Development Toolkit.

I go through more of the: who, what, where, when, why and how – in the IT Professional Development Toolkit product.



1 thought on “What if two product managers disagree on something and can only agree to disagree?”

  1. Loved reading this! The art of compromise requires validating shared efforts and realizing both parties are working towards the same goal. And then, as both colleagues see each other not as threats by as allies working toward a similar goal, the two can see disagreement as a challenge/opportunity to create a new solution! The problem ceases to be a problem and turns into a fun challenge – a puzzle of sorts – for combining unique ideas into something that delivers the best value to the team and the customer.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top