Most Product Managers have, at one time or another, heard the apocyphal quote often attributed to Henry Ford, “If I asked my customers what they wanted, they’d have said a faster horse.” And when we hear the line, we laugh because there’s no way that we would do such a thing — the “faster horse” is a fictional thing that we’d never actually spend out time and effort working on. We slap each other on the back, smile, and then go back to our office where all too often we return to working on the “faster horse” that we’ve deluded ourselves into thinking is innovative and fresh. It’s an unfortunate fact that much of what we do really is just delivering faster horses, giving our customers what they say they want (or worse, what sales tells us they say they want), and not digging deep enough to uncover the real need, problem, and desire that’s driving the request.
I’ll be attending my second formal training this year, getting my Certified Scrum Master certification to match the Certified Product Manager certification that I picked up earlier this year. After 15 years in the business, you might wonder why I’m just now getting around to being “certified”, and I hate to say it but the real reason is simple — the company I work for is paying for it. Otherwise, I’d happily chug away for another 15 years without any form of certification, because I firmly believe that the experience that I have in transforming companies into agile engines is far more valuable in the abstract than any specific certification that I might collect along the way. But, there are a few times when and where a certification might be worth pursuing…let’s talk about those today.
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…
Most companies out there put a huge push on efficiency and running “lean” — doing the most possible with the least amount of overhead. And in most cases, that’s a very noble goal — after all, overhead in the form of people and positions is generally the highest cost that companies face. Reducing the number of people needed to achieve the same goals allows the revenue side of the equation to exceed the costs — which is almost every company’s end goal, to achieve a sustainable business model that makes money for the owners of the business. The problem with this is that it’s often taken too far — the drive to be “lean” winds up causing more headaches and issues than it creates an environment conducive to success. This issue isn’t only of concern to Product Managers, it affects every part of the business, from sales to marketing to support to development. And because of that, we’re often in a unique position to see they dysfunctions that trying to drive too lean causes throughout the company. It’s up to us to be aware of the risks and raise them as we start to see red flags, before they damage the ability of the organization as a whole to compete in an increasingly competitive marketplace.
One of the most common questions I encounter in my work as The Clever PM is a simple one — “How do I become a Product Manager?” And, while the specifics depend greatly on the individual person, where they’re at in their careers, and what companies they want to break into, one of the things that I’m always telling people is that it’s likely that they already have the skills that they need. The best and worst part about being a Product Manager is that the role is often a “jack of all trades” role — filling in where there are gaps in the organization, ranging from the strongly strategic to the severely tactical. No matter where you sit in your organization, chances are good that with the right perspective and point of view, you can likely position the things you do to fit some definition of “Product Manager”.
Product Management is a hot role in the current market, partly because there are companies realizing the importance of the role, and partly because everyone seems to think that they can do the job. Without opining on either of those driving forces, in my experience there are three key things that any candidate can do to optimize their chances of actually snatching a Product Management role: assessing your skills, positioning your experiences, and pitching yourself effectively. If you can master these three key components, you’ll be best positioned to take your next role in Product Management — no matter where you’re coming from.
It’s far too common in the world of Product Management for us to wind up being narrowly focused on the actual product development cycle – define, build, measure, repeat. But there’s far more to building, launching, and maintaining a successful product than just what goes on between Product Management and Development. The best and most successful Product Managers try to look at the “whole product” and not just one small (though essential) part like the development process. To get the whole picture, we need our eyes, ears, and fingers on the pulse of all the activities that go on around the product — development, sure, but also marketing, sales, support, implementation, services, and anything else that might be considered “product-adjacent”.