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.
I’ve been working on B2B solutions for a very long time (dating almost all the way back to the turn of the millennia), and in that time I’ve come to realize that far too many applications try to be everything to everyone, and as a result really wind up serving nobody at all. You can see this in many product designs that try to capture all of the possible things that you could do at a given point in time, rather than leading you through a logical path, or showing you the most likely things that you may want to do. As much heat as I give the “ribbon” change that Microsoft introduced in Office a few (many) years back — conceptually, it was the right thing. It focuses you on the specific things that you need to do in some contextual space, without requiring you to remember which specific menu item someone decided to hide that option under. While the rollout was challenging, in my opinion, the approach really encapsulates a concept that I like to call “build for the novice, enable the expert”.
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.
There are a great many company cultures in the world that go out of their way to avoid conflict of any kind. And, while the intent is good — nobody wants to work in a combative workplace — the common practice of lumping all conflict together into a single bucket and trying to toss it out the window winds up being counterproductive in many ways. You see, conflict isn’t always a bad thing; certain types of conflict actually make us better at what we do. When we engage in constructive conflict, we hone our ideas, challenge our own assumptions and biases, and push others to do the same. In an environment completely absent all conflict, we might as well all just be “yes men” and simply rubber-stamp every idea that comes around. Successful businesses are not built that way. Here are some things to think about when it comes to engaging in constructive conflict.
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…
We live in a day and age where there’s a ton of information and mis-information out there about pretty much every topic imaginable, and Agile development is certainly not immune to this phenomenon. In fact, anyone who looks for help in pushing through an Agile transformation in their organization is immediately confronted with a vast array of presumptions and preconceptions about what Agile is, why it matters, and most importantly what it delivers. The simple truth is that the reality of an Agile transformation — both in process and in outcome — is often so very far removed from the myth that we as Product Managers need to be ready, willing, and able to step in and manage the expectations that our stakeholders have about what’s going to happen and what they’re going to get from it. Here are three very common preconceptions that simply must be squashed for us to lead a successful cultural transformation.