If you’d ask me what product management is all about I’d tell you it’s 45% focusing on the value, 45% communication and 10% all the rest.

We already spent quite some time talking about the value, how to uncover where it lies and how to deliver on it. We are not done on that front yet, but I think it’s the time we’ll start talking about the communication aspects of the job.

So with that in mind – today we’ll embark on our communication series. Unlike the other series – the posts are not going to follow each other, but rather will pop up from time to time. I’m pretty sure it will work out just fine. 

Great! Let’s get to it.

Today we’re going to discuss a topic that was raised a lot by product managers I’ve been mentoring or working with – and that’s what I refer to as ‘the battle of opinions’.

The Battle of Opinions

The battle of opinions commences when you make any product related decision that faces an objection from one or more internal stakeholders. This objection may quickly escalates to an endless debate that is based purely on hunches of each of the sides.

For example – let’s say you define that the user must sign in before they can perform any action with the app, while some of the developers think that this makes no sense and we should offer to the user some functionality even before they sign in. Each side has good arguments and none of you manage to convince the other side of the wisdom of your decision by the end of the day.

Got it. Now what?

Before we discuss how to address such conflicts let’s make sure we fully understand what we are facing here – in short we’re talking about scenarios where the people around you challenge your product decisions and you don’t easily manage to convince them of the wisdom behind your decisions.

If it didn’t happen to you yet – then either you’re relatively new to the job or super brilliant. It happens to all product managers I know, myself included.

Why is that?

Well, first – because many times there is indeed more than one way to ‘skin a cat’ and it’s hard to tell in advance which way will be proven to be the best at the end of the day.

Second – we don’t possess all the wisdom in the world, no matter how experienced we are. There may be other options that have escaped us, but are seen by others.

Understanding the above is key for resolving such situations and we’ll shortly see how.

What happens if I don’t address it properly?

Not addressing a battle of opinions properly may result in tension between you and other team members, and eventually if consistently handled poorly – will result with a lack of trust. This is because addressing it poorly usually means you either give up too easily or being too aggressive and forcing the hands of others, while it all seems quite arbitrary.

We want none of those, so let’s see what can be done.

Resolving battles of opinions

Before listing the various tactics you can use – I’d like to state my main rule about resolving battle of opinions:

Data wins!

If one of the sides brings relevant and proven data that support their case, while the other is not – the one with the data wins (yes… even if it’s not you).

With that in mind – let’s go over the tactics.

Prevention

It’s well known that the best way to address a problem is to prevent it from happening in the first place. In our case you can successfully prevent most of these conflicts by applying the best practices below:

1. Do your homework – understand very well the pain you are trying to solve and why you think your solution is the one that needs to be applied. Don’t fall in love with your initial approach and stay open. Consider other options in the most objective manner and challenge yourself before others will do it for you. Also – look at the market and find similar best practices that were applied successfully before. Most problems in the world are not new. They probably exist in other domains as well with some level of variation. See what worked there and adopt. The more data you gather to support your case – the harder it will be to challenge it.
2. Set up expectations with the team – yes, you are all in the same team, however it doesn’t mean that you must always be in agreement as for what would be the best approach to build something. That’s perfectly fine. That being said – if someone doesn’t agree with your decisions as for the ‘what’ (what needs to be built) – you expect them to support their case with data. They are always welcome to suggest other approaches, and you may or may not accept them. However, if you decide to reject their opinion and they are still feeling strongly about this – they will need to bring some data to the table. If they don’t – they shouldn’t expect you to act upon it. Merely by introducing your data driven approach to resolve such conflicts you automatically eliminated most of the future conflicts because:
   1. The team members understand there is a logic behind your decisions and it’s data driven and not your random ego that speaks.
   2. They are required to do homework before they challenge you. Nobody likes doing homework, so it automatically reduces future noise.

Defining the conflicts resolution hierarchy

Explain to everyone on the team that in order to avoid useless debate time on what’s the right way to do things – you are defining a conflicts-resolution-hierarchy (CRH). The CRH works as follows:

• When it comes to the ‘why’ and the ‘what’ of each feature and product – you (the product manager) are the final word. With two exceptions:
  • It’s a UX/UI related conflict and there is a designer in the team
  • It’s a tech-debt issue, originated from the engineering team
• When it comes to the ‘how’ (how to implement the feature) – the R&D are the final word when there are disagreements as for what should be the right approach to implement stuff.
• When it’s UX/UI conflict and there is a designer in the team – then they have the final say
• When the conflict is around how to structure the data and there is a data analyst in the team – then they have the final word on the matter. 

With the hierarchy in place it should be clear to everyone how things can be resolved with the lack of data. However, if someone does bring proven data to the argument (for example, market data that was published lately about the performance of similar approaches) – then their approach is the one to adopt, regardless of the hierarchy.

Establishing this hierarchy in a very clear manner with the team greatly contributes to the ‘prevention’ aspect mentioned before. The team feels that they also have the last word in some aspects of the product development and it gives them the necessary sense of control. From my experience the useless arguments are greatly reduced with the CRH in place.

Letting go

From time to time, though, someone will feel strongly about taking an approach which is different from what you are suggesting. Yes, you can pull your ‘CRH rank’ and close the matter, but I recommend only doing so as a last resort (if you see that the argument keeps going on, no matter what you say and it’s getting nowhere). Instead, try to listen to what they have to say and remember that you don’t own all the wisdom in the world. Other people have good intuition as well, you know. Sometimes it is worth listening to their intuition even though they have no data to support it.

Examine what they say and consider the following – is what they are suggesting fundamentally changes the solution? If not – is it easily reversible in case it doesn’t work? If the answers are ‘no’ and ‘no’ – you might want to give them this win. It could be the smart thing to do if you are going to work a lot with these people. It shows that you can listen, you are open and you are not ego-driven. And who knows – maybe their intuition was right?

When the battle of opinions is with your supervisors

One caveat to everything I wrote above is when the battle of opinions takes place with internal stakeholders who are directly above you in the hierarchy.

It could be your boss, your CEO or someone in between. When it happens – you need to tread with care.

When your boss, for example, feels strongly about how a feature should behave you can’t use the CRH, and you can’t force data to win. The playbook here is different, and I’d recommend the following flow:

1. If it’s not crucial and easily reversible – let go. Don’t even start a debate.
2. Otherwise – if you have data or past experience that supports your case – present it. Delicately ask your supervisors if they have data that supports their case as well. If they don’t – they may be willing to let go at this stage.
3. If you don’t have data to support your case and you only have your intuition – share it with your supervisor and ask them why it’s so important to them. Explain that their approach might take the solution to a different place and explain why you think it won’t solve the pain or it may be hard to reverse if proven wrong (assuming your approach is easier to reverse).
4. If none of the above helps – let go. You lost. The only ‘good’ thing here is that you are not accountable. You presented your case – you explained the potential cons and pros and it was decided against your recommendation. Of course you want the product to succeed and you will be sad if your boss’ decision ruined something – but at least your reputation remains intact and this is more important than everything.

That wraps up the post for today.

If you found this post/series useful – let me know in the comments. If you think others can benefit from it – feel free to share it with them.

Thank you, and until next time 🙂