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.
One of the things that I love about the Product Management community here in Seattle is how close-knit we are, so when I reached out to Tricia Cervenan, a fellow Product Manager and General Assembly instructor, for her thoughts on the industry, the role, and what it means to her, I was not disappointed. I met Tricia a few years back at a panel discussion for General Assembly’s and have worked closely with her during our classes to help mold and modify the curriculum to best fit the needs of our students. I’m happy to have her as a returning judge for each of my courses, and more happy to mark her among my very close colleagues in the business!
In her own words:
Tricia Cervenan is a product manager at L4 Digital and part-time instructor at General Assembly. She has shipped over 15 digital products and is most proud of the teams she’s help to build while doing so. Tricia is a co-organizer for App Camp for Girls Seattle where she teaches 8th and 9th grade girls confidence and coding while taking them through the process of building iOS apps in a week. When she’s not building software or working with those new to the industry, Tricia finds joy in long distance cycling, world travel and a good cup of coffee.
There are a lot of different hats we wear as Product Managers, which means that there are a great many opportunities for us to do the right thing, at the right time, for the right people. But the inverse of that is also true — by virtue of wearing so many hats, there are a lot of opportunities for us to do the wrong thing, at the wrong time, for the wrong people. These anti-patterns have a tendency to sneak up on us and bite us when we’re least expecting it, and therefore least prepared for them. But by being aware of them, we can keep our eyes open and try to avoid them if we spy them sneaking up on us in our rear-view mirror. This is far from an exhaustive list, but I’ve compiled five mistakes that Product Managers often make that set us up for almost inevitable failure.