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.
Sometimes an idea just strikes me out of the blue and sounds interesting enough to sit down and write a little bit about. This is one of those posts, spurred on by a discussion I had today with a newly-hired Product Manager with almost as much experience as me. As we were talking about our past experiences, where the current company is at, and how we can work together to improve some of the practices and procedures throughout the organization, I started to think about all the different things it is that we actually do as Product Managers, and all of the hats that I’ve worn in the past. These are some thoughts on a few of these hats…
We tend to take the fact that agility is important as a given, when the reality is that not everyone in the business world has reached the same conclusion. Thus, it’s important sometimes to take a step back and examine why agility actually matters, so that when we’re faced with people who aren’t as convinced as we are, we have salient points that we can raise to help them understand the value that agility brings with it. Here are a few important things to remember when thinking about why agility is important in our jobs…