What a Product Manager is Not?
As a product manager myself I find it particularly surprising how often I find myself doing others people’s jobs for them or being expected to do certain things due to my team and external parties perceptions of what a product manager is. As the product manager on a very tenured team with years of waterfall experience and deeply embedded in a large corporate environment there’s an even more warped perception of the role and responsibilities of a product manager than I’ve ever experienced.
The truth is, there’s no fixed definition or scope, however I think there’s generally a clear understanding of what role the product manager plays — in particular with respect to an agile scrum team, which is the environment in which I operate. What’s less clear is what a product manager isn’t, so let me shine some light on this.
Scapegoat
Can you sign-off on this? Can you put that in an e-mail so we have a paper trail? Immature scrum teams love to shift responsibility to the product owner in the event something goes to crap or the users aren’t the biggest fan of the new enhancement or feature! This is even worse in corporate environments where there’s less of a ‘one team’ culture with relation to a product but instead a ‘business’ product owner and a ‘technologies’ delivery team.
As a product owner I’m more than happy to take responsibility in what we deliver because I make data driven decisions, listen to my users and interact with great digital experiences on a daily basis. Agile is to some extent a game of taking calculated risks to harbor insight and learning. I’d rather be admired for my confidence and risk taking than play it safe.
However, never let a product team make you the scapegoat — I’m sure if you are successful they want some of the glory. You are not responsible for code quality, for ensuring zero defects, for hitting release dates, for writing rich acceptance criteria on your own etc — everyone working on the product needs to assume the role of a product team, no one person is responsible but the collective for ensuring you launch a best in class product.
The Boss
The amount of times people ask me for permission is remarkable, who am I to approve if you need to use AJAX vs. jQuery? Who am I to tell you where you need to report your hours worked? Who am I to have to tell that scary boss person that they’re making your life difficult? So often I’m expected to approve things that signify I’m of some kind of higher ranking — I’m not, I’m your counterpart.
Sometimes I think it’s just a cultural thing. If you’re an assertive, innovative product owner that likes to push boundaries and inspires other then oftentimes you’re considered the leader by default. This is great; however don’t let the team you work with confuse you as a top down ‘boss’ but as an enabler, someone who can help them push to find better ways of doing things and inspire them to also push boundaries and to harvest a culture of innovative and inspired product ambassadors.
One caveat and something I’ve seen the members of product teams do in a few organizations is that negative people can refer to you as ‘the boss’ because it’s the product owners role to have final say over the priority of the product backlog. This is poisonous and an attribute of the negative. If you’re re-prioritizing with your team during backlog grooming, if you’re delivering technical debt, operating and open backlog and bringing people along on the journey with you then you’re breeding a ‘one team, one dream’ mentality, don’t let the poison in the team drag you down.
The End User
Never kid yourself that you represent the end user and always know best. You represent someone who has access to lots of fantastic data about your end user and who knows the product inside out and all of is nuances. You represent the person who could navigate your product with their eyes closed, the person who represents the ‘millennials’ with your digital proficiency and who may have personal and organizational vest interests in the product, which could potentially and subconsciously, without intention skew the way you evolve your product.
You are the ambassador of the end user — unbiased in opinion and agnostic of influence. You are the definer of the product vision, which is the nirvana of satisfied end user needs but not a definitive list of things you think the product should be.
The Project Manager
Grrrr — oh how I’ve been here. Defining release roadmaps when you have release roadmaps, telling scrum masters how to forecast velocity, telling test managers why automation is good — being everyone’s champion and when they don’t show the same enthusiasm as you doing their jobs for them. As a product owner what you will inevitably face is environments where you’re part of a product team which is full of individuals who…how do I say this…don’t have the same passion for creating world beating digital products. It sucks. You will work with people who do things that same way and expect different results, people who don’t care what the result is, those that need spoon feeding and that treat frameworks as gospel and those have problems for your solutions.
What happens, you end up managing everyone and everything because you want things to be as good as you know they should and can be. You end up writing test cases, scheduling retrospectives, managing the finances…it’s working but you’re killing yourself and no one’s giving you any kudos. The catch 22, you step back and leave it in others hands and you know it will all go downhill and the way you deliver and what you deliver won’t be half as good. I empathize. The simple truth though is managing it all isn’t going to work, you’ll just burn out and we won’t get enough of you don’t what you do best as a product owner.
Inspiring others to be the champions for their respective roles and to self assemble around change is no easy feat but the sooner you crack it the more the reward you will reap.
Enjoy this? Join the community at www.productmanagerclub.com or follow us on Twitter at https://twitter.com/
