Even though it’s been around as a formal role in software organizations for nearly 20 years (or more, depending on who you talk to), Product Management still struggles with a lot of definition problems — what is the role, how do we grow, when do we get promoted and to where, etc. One of the common issues that we run into are companies who don’t have any form of structure around their product teams, who struggle to define the actual differences between their “associate”, “general”, and “senior” Product Managers without simply resorting to the amount of time they’ve been in the role. As anyone with extensive experience in the profession can tell you, how long you’ve been doing the job has little to no bearing on your actual ability to do the job — you can work for 10 years practicing all sorts of bad behaviors that have resulted in zero growth as a Product Manager. Similarly, you can go deep and hard for 2-3 years and come out the other side as a true product leader and influencer, capable of taking on much more advanced products and projects than your companions. Here are a few of the common differences that I think draw dividing lines between a “junior” Product Manager and a “senior” Product Manager, where age is not the most important factor…
Due to the unique role that Product Managers play in most organizations, we’re often capable of being the strongest influences on the overall culture of the product development organization and of the company in general. And while there are many companies out there who are truly only interested in giving lip service to the concept of agility, there are others who actually want to be better, who want to embrace the concepts of agility — and it’s up to us as leaders to influence that and contribute where we can. While there are a lot of different behaviors that we can engage in which are likely to increase the adoption of agile practices across our organization, in my experience there are three key things that we should focus on if we want to broaden the success of agile adoption in our companies…
As Product Managers, we’re called on a lot to weigh in on questions, considerations, and issues related to our market, our customers, and our products. And we’re often pressured to provide opinions either with or without sufficient data to feel entirely comfortable about drawing conclusions that we know people will rely on and act on — regardless of how carefully we couch our words. It’s par for the course, to some extent, but the more prevalent such requests become, the more we might begin to lose sight of the hazards of engaging in such speculation, and start to leap to our own conclusions without doing our due diligence, even when we do have the time to do so. After all, if we’re truly experts on our market, customers, and products, then we have license to make such gut decisions and skimp on the data collection. WRONG. Part of our job, indeed our necessary role in the organization, is to push for truly data-guided and data-driven decisions — especially when the conclusion isn’t crystal clear (and often when it is). We need to be comfortable stopping the train, or at least slowing it a bit, to do some basic fact-checking before we make decisions that can literally affect the lives and livelihoods of our team members. We owe it to them, and to ourselves, to understand when we’re stepping out of our “known knowns” and into the territory of “known unknowns” (to blithely steal a classic from Donald Rumsfeld).
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.
At some point in my meanderings online, I heard tell of a Slack channel that had been set up for Product Managers to engage with each other and discuss topics of concern to those in the profession. And, being the Clever PM that I am, I had no choice but to check it out — that channel turned out to be hosted by the folks at the Product Coalition, and administered by none other than Jay Stansell. The channel has turned out to be an exceptionally popular location for PMs to share articles they’ve written, ask for thoughts or feedback on idea that they have about how to improve the craft, and even to just humbly ask for advice when they’ve hit a brick wall on something. When creating my list of participants for this 10 Questions series, I knew right away that I’d want Jay’s thoughts on the role, and he was more than happy to oblige.
In his own words:
I’m a product person, who is grounded in design, shaped by technology and inspired by profitable business models. I “cut my teeth” in a travel start up in 2007, and grew it into one of Australia’s leading travel products. I’ve since been fortunate to craft products and product experiences for some of Australia’s largest brands. Today, I take my start-up learnings, attitude and culture, into coaching Agile, Lean Startup and Design Thinking methodologies at Australia’s most innovative insurer, IAG.
What I’ve enjoyed the most from my story so far, is the talented people who have become friends. It’s these connections that inspired me to launch the product community ProductCoalition.com – a place for product people globally, to connect, collaborate and inspire.
And without further ado…my ten (eleven) questions for Jay…
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.
There are a great many different corporate cultures to be found in the world, but one consistency among far too many of them is decision-making processes that rely more on gut-level instinct and whomever yells the loudest rather than on hard data. For some companies, this has served the CEO well — a small, nimble startup can’t always waste time doing detailed validation or data-gathering in a “stop moving forward and you’ll die” environment. In other companies, it’s become the de facto standard due to strong personalities who may prefer authoritarian leadership styles over more democratic and empowering styles. Regardless of the reason, though — companies like this eventually wind up struggling because they make the wrong choice one time too many, based on the leaderships “market instinct”. And it’s our job as Product Managers to shepherd these companies into a more modern-day, data- and hypothesis-driven approach. Here are three major reasons why data-driven management is far more effective than management by gut or personality.