In many organizations, conflict is part and parcel of the culture — some conflict can be constructive, some destructive, but most of it can just be downright annoying. And, because we often sit right in the middle of all of the random agendas, battles of ego, and emotional storms that can rage throughout the company, Product Managers often wind up dealing with the outcome of these conflicts if we’re not pulled deeply into them by one or more of our stakeholders. And while it can often be tempting to take on all comers, to defend your territory and your teams to the bitter end, the sad truth is that all too often, these conflicts simply aren’t set up in a way for us to “win” — and seeking that extra mark in our “W” column can often be counterproductive rather than helpful in the long run. All of the best Product Managers know that sometimes when there’s a fight that you’re not going to win, it’s far more important to lose gracefully than it is to die on a hill for something that ultimately didn’t really matter much.
There’s a well-known theory in psychology known as Maslow’s Hierarchy of Needs, named after its creator Abraham Maslow. The concept behind this theory is that as human beings there are certain needs and interests that we seek to fulfill in a predictable priority — from physiological needs for food, water, and sleep up to social needs of belonging to a group, all the way to becoming independent, self-actualized creatures — the “best that we can be.” It’s a very interesting concept, and one that immediately came to mind in a recent Twitter discussion that I had with a fellow Product Manager named Gasca. Gasca proposed that the “intersection of business, development, and design” wasn’t really sufficient to describe what makes a Product Manager excel, and added a circular diagram to the discussion which immediately prompted me to think of the whole idea more in terms of Maslow’s Hierarchy — just what is it that makes a good Product Manager better, and how can we structure our approach to building skills and refining talent to “level up” our co-workers and peers to make the me most self-actualized Product Managers we can? I don’t pretend to have the full answer, but here are some thoughts, using Maslow’s Hierarchy as a model…
There are a lot of different hats we wear as Product Managers, which means that there are a great many opportunities for us to do the right thing, at the right time, for the right people. But the inverse of that is also true — by virtue of wearing so many hats, there are a lot of opportunities for us to do the wrong thing, at the wrong time, for the wrong people. These anti-patterns have a tendency to sneak up on us and bite us when we’re least expecting it, and therefore least prepared for them. But by being aware of them, we can keep our eyes open and try to avoid them if we spy them sneaking up on us in our rear-view mirror. This is far from an exhaustive list, but I’ve compiled five mistakes that Product Managers often make that set us up for almost inevitable failure.
There are a great many company cultures in the world that go out of their way to avoid conflict of any kind. And, while the intent is good — nobody wants to work in a combative workplace — the common practice of lumping all conflict together into a single bucket and trying to toss it out the window winds up being counterproductive in many ways. You see, conflict isn’t always a bad thing; certain types of conflict actually make us better at what we do. When we engage in constructive conflict, we hone our ideas, challenge our own assumptions and biases, and push others to do the same. In an environment completely absent all conflict, we might as well all just be “yes men” and simply rubber-stamp every idea that comes around. Successful businesses are not built that way. Here are some things to think about when it comes to engaging in constructive conflict.
While Product Managers have a great many tools in their belt to use when working internally with stakeholders or externally with customers, there’s one tool that seems to elude so many of us. That tool is silence. When you’re talking with someone and trying to get them to say what’s really on their mind, what’s underlying the things that they’re telling you overtly, silence can be one of your best tools for figuring out what they’re really thinking, what problems they really have, and what’s really motivating them. Silence can be an amazing tool when used properly and in the right circumstance — it essentially forces the other person to fill in the gaps of conversation, and when they do it’s usually with something that comes from the subliminal thought processes rather than the conscious ones. In my constant effort to empower Product Managers everywhere, here are some thoughts on using silence effectively…
A recurring challenge that many Product Managers face is coping with stakeholders who attempt to block our efforts, either covertly or overtly. Sometimes these situations arise due to simple miscommunication, but other times they’re power plays, the results of internal politics, or even caused by grudges held from previous slights — real or imagined. To excel in Product Management, one must not only deal with these blockades as they arise, but you need to predict when, where, and how they’re likely to come up so that you can head them off before they even become an issue. To do that, though, we have to try to figure out what the most common reasons are for stakeholders to actively or passively interfere — and that’s what the Clever PM is here to share with you. In this first installment I’m going to focus on overcoming passive resistance, and we’ll address more active resistance in a future piece.
A common theme in online discussions and forums around Product Management lies in how to level up our skills and be a better Product Manager. While there are a lot of different options available, just as there are as many different aspects of Product Management to focus on, there are some very specific areas that any given Product Manager can assess themselves in and decide what next steps they want to take to become a better Product Manager.