Leading Through Influence the Clever PM Way — Part 3: Trust & Respect

Leading Through Influence the Clever PM Way — Part 3: Trust & Respect

This is part 3 of a series of articles about leading through influence.  The first article focused on the concept of social capital and how we earn the right to ask people to follow us; the second focused on how to use effective facilitation skills to establish yourself as a valuable resource for others to reach decisions; and this article will focus on the importance of trust and respect, and how ultimately everything that we do as Product Managers comes down to these two fundamental interpersonal concepts.

Trust and respect are more than just important to being an effective product manager or business leader — they are essential concepts to master in all interactions with people, whether in your home, on the town, or in the office.  In fact, trust and respect are the cornerstones of leadership, upon which every other aspect is based.

Trust People to Do What They’re Expected To

One of the most common pitfalls that newly-minted Product Managers fall into is a lack of trust in the other teams that they work with.  The Product Manager often decides that they “own” the product, and that entitles them to exert direct control and influence over how other people around them do their jobs.  The “CEO of the Product” concept is often the crutch that these PMs use in explaining their position, but what they’re missing is the fact that all successful CEOs know what their strengths and weaknesses are — and they build teams to tackle those things that they personally may not excel at.

Successful CEOs know what their strengths and weaknesses are, and build teams around them.

So it must be with an effective Product Manager – the people around you have been hired for a reason, so we owe them a presumption that they’re at least competent in their respective fields.  You can’t be successful as a Product Manager if you’re constantly questioning how others are doing their jobs — just like you wouldn’t appreciate a marketing manager telling you how to prioritize your product features!  But far too many PMs seem to think that because they are a hub around which the product rotates, they can directly influence how other people do their related jobs.

This is doubly true with developers – software engineers are called “engineers” for a reason.  They’re well-educated, dedicated, driven people who like to use creative energy to solve valuable problems.  And they’ve likely spent far more time learning, implementing, and troubleshooting code than the typical Product Manager has.  And even if you’re a former coder who’s moved into a PM role, you simply have to let it go and trust that those around you will do the job that’s expected of them.

Trust, But Verify

Now, this doesn’t mean that you should ever just sit back and let people sabotage your product through incompetence or actual malice.  Someone’s competence at their job by virtue of them being there is merely a presumption, not a guarantee.  And as a Product Manager with a view on the health of the whole product, you need to be sure that those whom you are trusting to perform adequately (at least) actually are — and you need to be willing to be the “bad guy” when someone fails to perform their job in a way that leads to success.

Doing this in a tactful way that doesn’t severely affect your ability to do your own job is a trick that takes a lot of time to master.  You need to develop your abilities to provide constructive criticism to people with whom you notice performance issues.  You need to position yourself as someone who is trying to help build them up and not someone who’s merely trying to tear them down.  You do this primarily by offering solutions, alternatives, or assistance in a way that still allows them to save face while improving their ability to deliver on their promises and the expectations of their job.  Don’t steal the spotlight, and don’t throw a red flag in the middle of the exec team — working with someone who’s struggling is usually far more productive than throwing them under the bus.

Working with someone who is struggling is far more productive than throwing them under the bus.

Humility, the PM’s Greatest Asset

The true key to doing this, of course, lies in your ability to be humble when approaching someone who’s not performing to expectations.  Humility is, in my opinion, one of the most useful tools in a PM’s belt that allows you to build both trust and respect with others in your company.  Particularly when dealing with difficult or complex issues, approaching the situation with humility and using your active listening skills is key to ensuring a positive outcome for both you and the person you’re working with.

There is only one thing that a PM should be absolutely confident about is the product itself – the prioritization process, the backlog, and other directly related aspects of the business.  In all other aspects of the business — marketing, training, support, development, sales, etc. — the PM needs to approach the team with the proper level of humility, even when things are falling off the rails.

In practice, the easiest trick to approaching these kinds of situation with the proper level of humility is to ask the team or person to explain to you why they are doing things the way that they are, rather than just telling them that they’re causing problems.  It could very well be that they have a rational, justifiable reason for what they’re doing and how they’re doing it — and being open to listen to them before making criticisms or suggesting corrections demonstrates that you value their contributions, their knowledge, and most importantly, their input.

Respect – It’s All in the Balance

I’ve focused a lot on trust and humility up until now, primarily because I firmly believe that if you can demonstrate to others that you trust them, and you can be properly (and appropriately) humble when the situation calls for it, the natural result is that people will respect you and your own contributions.

Perhaps the single most important thing that any Product Manager should remember about respect is that it’s something that’s given to you by others, and it’s something that you earn — not something that’s offered up by virtue of your job title.  It’s also something that’s very fragile, and easily bruised or destroyed altogether — returning to the first in this series, the more social capital that you’ve built with a person or a team, the less likely you are to seriously damage their respect for you with a minor mis-step.  This is all the more reason to manage your social capital to ensure that you’re safe from these occasional mis-steps that can endanger others’ respect for you.

Respect is very fragile — easily bruised or destroyed altogether by even the smallest mis-step.

It’s also important to remember that respect is a two-way street — others need to earn your respect as well, through the same social capital processes that have been discussed in the earlier article.  If someone consistently disrespects you, especially in front of others, then you really owe them little respect in return.  That doesn’t entitle you to become a petulant child, but at the same time you should treat others with slightly more respect than they show to you.

Also, it’s key to remember that respect does not mean deference — nobody likes to work with a “yes man,” or someone who is constantly kissing the ass of their executive team, or who lets others walk all over them.  Treating people with respect does not mean that you become a doormat.  When the time comes to defend yourself, your product, your priorities, or any other aspect that’s within your control and direct influence, you absolutely need to stand up for what’s right.

Ultimately, it’s about achieving the right balance between being assertive enough that people don’t view you as a doormat or a “yes” man (or woman), but at the same time not building a reputation for being “difficult” or “obstructive”.  Nobody gets it right the first time, but through careful reflection and self-assessment, you will get it right eventually.  Me, I’m still working on it.

Back To Top