Managing a product team is not like in a traditional hierarchy.
Product teams especially in larger organizations are matrix organizations. Even in small companies we typically see matrix organizations where 'Product' (with a capital 'p') is separate from Marketing, Development, QA and the business stakeholders.
This presents a unique challenge to Product Managers because each of the people in your squad, scrum team, agile team are not directly under your employment. That's typically of many engineering organizations.
The definition of a matrix organization from Study.com is:
"A matrix organizational structure is a company structure in which the reporting relationships are set up as a grid, or matrix, rather than in the traditional hierarchy. In other words, employees have dual reporting relationships - generally to both a functional manager and a product manager."
This definition applies to us product manager directly.
This dual reporting relationship means that as a product manager you have to manage people that are cross-functional and also be able to manage up in your functional organization.
Managing a team that are not our functional direct reports have it's own challenges.
This is a big obstacle to overcome. You have no say in who is being hire, you have no say in the quality of the person, if you could get along with the person.
I've personally experienced situations where changes to the team were not told to me until the new person joined or the person on the team was on his last day.
This happens a lot and whether it's an oversight, or just the fact that it's a matrix organization, it doesn't help with morale or the collaborative aspects that are expects of how to managing a product team.
The reserve is also true and even worse. If the person doesn't turn out to be up to snuff, you are stuck with someone who is mediocre or requires a lot of hand holding which brings team velocity down too. This is even worse than not having someone there, at least there isn't an expectation of the work being done.
People management and people will always be a "messy' affair, but not having a say in who joins your team or who leaves the team because of poor performance is a significant challenge.
There's in fact very little you can do, but the little that you can do is two-fold:
People are messy. Products are easier -- but hey that's why we feel into this in the first place, isn't that right?
Most product managers we've come across come from all sorts of previous careers and backgrounds, but they all share something in common -- this desire to want to be right about the product they want to build.
Most of us get into this career path because our focus is to want to build product and it's also mislead because of what the name implies because we are 'Product Managers'. We are managers of the product, but really what the actual job title or role should be is Product Owner or Product Evangelist.
Having the title Owner is a bit better because it doesn't specify what is being managed and focuses more on being the person who is ultimately responsible for the product.
Evangelist or Product Evangelist helps to provide the connotation that this role is to motivate people to get things done.
The people skills aspects is nothing new for many roles. Even developers, the good ones anyway, require those that can communicate well, manage conflicts and debate on product tradeoffs.
The Product Manager is no exception -- it's a critical juncture of business, engineering and design and being able to navigate between those functions AND all the people within them are vital to the success of the product.
There's many books in this subject, but the one where I've found to be the most useful and effective is the method they teach in having Crucial Conversations.
This is a book about having and need a balance between getting your point across, not getting emotions get the better of you and knowing it's even more important to have these conversations when the stakes are high.
It's been recommended by other product people that I know and I wished I'd know this sooner or that I finished the book sooner to gain more confidence in how I manage people on a product team.
Don't be afraid to have a conversation with them, even if it's hard, even if it's busy. Try to do 1-on-1's where possible but if not, having a small group is also fine.
If managing just one person is messy, think about all the permutations of things that can go wrong in a group. There's groupthink of one, herd mentality, drama, gossip, that's bound to ensue in any group larger than 2.
So there's no need to talk about general group dysfunctions which are typical of groups of large enough size, but what are those specific issues that plague product teams?
Dysfunction can start to happen when people start to perceive others are not pulling their own weight. People start talking behind people's backs and not winning as team.
Product teams that are not resilient enough to withstand poor decisions. I think it was Charlie Munger, the Vice-Chairman of the successful company Berkshire Hathaway and Warren Buffett's best friend, who said that great businesses can withstand a little mismanagement here and there.
The same can be applied to products and the product teams that support it. If the team cannot withstand a little mismanagement in making bad decisions then it's probably not a good product team or product.
I've seen this before, where bad decisions even made with the information at hand are reviewed over and over again. People are reprimanded or worse, people no longer feel like it's psychologically safe to talk, make reasonable mistakes and recover for them when given a chance to.
Product mistakes and product decisions are made everyday -- you never know when it's a mistake or not until well after the fact. When groups start pointing fingers, when groups start no sharing the responsibility of putting the product first and individual decisions second then it's not a resilient enough product team.
Jeff Bezos has often talked about this concept to "Disagree and Commit". Perhaps he didn't invite it, but he certainly made it famous and made a point of talking about it his 2016 annual letter to shareholders of Amazon.com.
Bezos talks about this more in the context of moving fast as a technology company. He as a manager who decisioning rights has the power to voice disagreement but that let's try it anyway. I think this concept also gives psychological safety to the team too that it's okay to disagree, it's okay to have crucial conversations one on one, but when it comes time to do something you just have to make a decision even though it doesn't all compute.
Dysfunction on a team starts when people have resentment, harbor ill-feelings or don't feel like they have a voice. If a team continues to talk, have a conversation, openly talk about different and/or opposing viewpoints respectfully and agree-to-disagree, this will go a long way to building a great, functional team and the products and users benefit.
What do you think about managing at team? Have you managed a team before and encountered these challenges? Any other challenges that you'd like to comment on below?
Thanks for reading.