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…
I’m often asked by in both formal and informal discussions whether I think that Product Managers are stuck in whatever industry they start in, and if not how to break into a new one. And through all the years of having these discussions I’ve determined that the vast majority of the skills that make someone a great Product Manager are entirely portable between companies, products, and industries. You can learn a new product pretty easily, assuming that you have an organization with a good onboarding process. You can learn the market pretty quickly, assuming that the company has some internal experts already there to learn from. And you can learn the politics of the organization by just paying a small iota of attention in your first 30-60 days in the organization. None of those things are directly determinative of success as a Product Manager — what is determinative is the soft skills that you bring along with you, your approaches to problem solving and consensus-building. To that end, here are three key skills that any Product Manager should leverage no matter where they are and no matter where they want to go.
One of the many challenges that Product Managers face in trying to move organizations toward a more agile approach to product development is that some stakeholders simply don’t see the value in the shift. They believe that, since their way has worked for them for so long that there’s no need to change — after all, it can’t be broken if it works, right? But the simple fact is, the bad old ways of product development are dying, as markets and customers move faster and have more options available to them to solve their problems every single day. There’s not a single industry that isn’t facing high-investment newcomers who are able to move fast and adjust — and leave they’re slow-moving, waterfall-based competition in the dust.
A couple years ago I ran across a blog post by Paul Jackson where he mentioned in passing the idea of a tension between “default ship” cultures in relation to corporations versus startups. For some reason, those two ends of a spectrum have stuck with me ever since, and after struggling with some culture change in my day-to-day job recently, I thought that it was an interesting subject that deserved a little more attention and dissection. Because, even though Paul positioned it as a startup v. corporate culture issue, my feeling is that it goes much deeper than that and is a topic that every Product Manager should be aware of and have their eyes out for — you never know when the “default delay” police will come knocking on your product’s door…
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.
As an active member of the Seattle community of Product Managers, I’ve been fortunate enough to find many opportunities to engage with fellow Product Managers as well as those looking to make a break into the role. Between my work with General Assembly as a part-time instructor, my volunteer efforts as a board member of our local Pacific Northwest Product Management Community, or my presentations at ProductCamp every year, I enjoy sharing my knowledge and experience with those who seek different perspectives on old problems or just want to hear a good old war story. The fact is, we all have something to impart on those around us, and we should take any opportunity we can to share with those around us.
I recently had a really great conversation with a fellow co-worker about how and why companies struggle with the adoption of agile methodologies like Scrum. It just so happened that he had come from a very large company where someone had undertaken something unheard of — they attempted to objectively measure the effect that Scrum participation had on a variety of employee metrics, including productivity, job satisfaction, and overall output. The interesting finding was that for teams who skipped any one of the five key Scrum ceremonies, their overall scores were literally no better than teams who maintained an old-school, waterfall approach — while every team that performed all five of the key ceremonies on a regular basis has scored vastly greater than their peers, across the board. Seeing this data in tangible, objective numbers really stuck with me, and I think it’s important to discuss just why these ceremonies are so important to successful adoption of agile processes.