Last night I attended my first The Product Group Meetup where people in the field of product development get together to discuss best practices and knowledge share. The discussion is split into two parts: Part one focuses on a discussion topic and the second part of the evening is dedicated to a product showcase where a representative (usually a founder) talks about roadblocks, best practices and successes in creating the product.
The discussion last night focused on product related disagreements – What are common root causes and how do people manage disagreement? Although billed under the “product” umbrella, many of the points discussed are applicable to most work situations, but let’s keep the focus on the product development process.
Some interesting takeaways:
Disagreement is not necessarily negative:
- It can be an indicator that people are engaged, thinking independently and are passionate. “Group think” is a pitfall teams can fall into and some disagreement is an indication of staying away from pack mentality.
- Disagreements can produce opportunity. If handled properly, usually someone will learn something from the situation, be it familiarization with what motivates team members in a project to technical learnings and beyond.
The endpoint of a disagreement should not be looked at as a win/loss outcome. What we really want to do is get to the root cause of the issue and learn. Many times, just like in an agile environment, progress is measured by what we learn.
We are all aware that there is a difference between construct vs. destructive disagreement (The latter gives the word “disagreement” its negative connotation.). So how do we foster an environment conducive to construction? For one, trust. This starts with leadership and visible people should be able to openly admit when they are wrong (Of course this is not easy and is more difficult in larger organizations with complex political atmospheres.).
When managing a disagreement, it takes a level of empathy to understand what motivates people (a skill more managers very much need) and the ability to speak the “language” of various team members. For example, a developer will have different motivations and ways of conveying a business point than an experience designer may.