There’s always a fine balance to be found between making sure that your product is as buttoned-up as possible when it ships and the small (sometimes large) sacrifices that we have to ask our technical teams to make in order to just get the damn thing out the door. Within this gap lies the dreaded concept of “technical debt” – the ever-growing list of things that you know you probably shouldn’t have done or that you should have done, but that have way to the reality of getting product out to market. The good news? It’s not always bad. The bad news? Play too fast and loose with it and it will come back to bite you in the ass.
One of the more common challenges that growing companies face is balancing the needs and goals of the company with the needs and goals of its employees. And, unfortunately, all too often decisions are made with a business perspective that don’t take into account the potential effects on the personnel side of the equation. The simple fact is, people will do what we incent them to do and what we reward them for far more often than they will do what we want them to do, if there is any misalignment between the two. This applies across the business — from high-level executives to entry-level employees, and even out to our products — how we position, package, and price our products can often drastically affect how people will perceive and use the product.
While people always seem to nod their heads when you tell them this, it’s rather insane to realize just how often we create competition between these two things. Here are some things to consider when you’re trying to figure out how to get people to do what you want, or why they’re not doing what you expected.
Many people are aware of the famous quote from Peter Drucker, “What gets measured, gets managed.” But what people don’t often consider is that what’s being measured and managed might actually not matter at all at the end of the day. When we measure things that don’t actually drive us to improve, we’re just acting like a cargo cult — going through the motions and expecting something magical to happen that never will. Instead of just picking some popular or standard metric, we should instead make sure that we understand what direction our measurements are going to give us, and what change they’re going to drive in our behavior or in our products. Only by being thoughtful and deliberate in our choices will we find the right metrics to use and rely on in our choices.
Here are a few things to watch out for and to take into account when considering what metrics we want to put into place…
One of the ongoing challenges that we face as Product Managers is that we’re primarily charged with predicting customer and user behavior. We’re constantly asked to come up with new ideas, new features, and new designs that we “know” will delight our users, or at the very least satisfy them. But the fact is, predicting human behavior is incredibly difficult — there are many thousands of people who have spent hundreds of years trying to figure out why people do what they do (they’re called psychologists, sociologists, and anthropologists), and we’re still making educated guesses at best. So, what are some of the challenges that we face?
Awhile back, I answered a question on Quora about behaviors that indicate that someone may be a bad PM; since I’m in all-day sessions this week in a sales kickoff, I thought I’d re-share these thoughts here on the Clever PM blog…
- Dictators, not Facilitators
This behavior shows up across the board, from the sprint planning sessions to meetings with stakeholders. This kind of PM is so absolutely certain that what they want is the “right” thing that they ignore input or patronize people during discussions, even when good points are being made. They also tend to dictate to the teams what’s going to be done, rather than facilitating discussions of scope, level of effort, and general team morale. The biggest consequence of this is that their meetings take forever, because nobody else is motivated to solve the problems in front of them.
- Can’t See the Forest for the Trees
I’ve typically seen this from PMs who originate from the development side of the business, or who are trained project managers trying to take the next step into strategy rather than execution. The problem is that they’ve spent so much time doing that they have trouble thinking. This typically shows up with too much focus and micro-management of the development teams that they work for, as well as an “order-taker” mentality, where someone else in the company winds up defining the strategy, and the “PM” winds up just executing, based on that input.
- I’m the Customer, Right?
This is a trap that many PMs fall into every now and then, but when it’s more often the case than not, it becomes a major problem. It’s even more painful when the person who is making these decisions really doesn’t have the UX chops that they think they do. There’s a reason there are UX professionals out there, folks – and if you think that just because something works for you it will work for your end user, I’ve got a bridge to sell you. It’s important that you remember that you’re only a proxy for the user – if you lose that perspective, you will fail to be an effective product manager.
- Too Much Responsibility, Too Soon
It’s tough to determine when someone is ready for the kind of responsibility that a “true” PM should have – here I’m talking P&L responsibility. The kind of person who succeeds here is someone who has enough business experience and maturity to know how to discuss, debate, and politic within the company without sacrificing their dignity and core goals. If you pick someone who comes into this role too early in their career, they go one of two ways — they either become a sycophant for more “powerful” people in the organization, or they piss off everyone around them and never build the social capital needed to be a good PM.
- So What? Being a PM is a Breeze!
No, it’s not – it’s hard work. And there are some people who come from other disciplines, who have only seen how PMs work from the outside, who think that all that’s really needed is to come up with cool ideas and get people to do them. This PM tends to be superior, condescending, and not really “get” the fact that there are actual users out there who should be talked with and understood before doing something “cool” that nobody ultimately cares about. I tend to see this a lot in startup cultures that are very development-driven, since developers always like to play with new things, whether they’re really useful or not – and the lack of maturity that this type of PM has plays perfectly with the dev’s desire to play with things, rather than deliver business value. They usually wind up being development puppets, unless someone steps in and helps them learn how to be a good PM.
The good news is that all of these things can be corrected, with a little bit of training and a whole lot of humility. If you find yourself doing these things, step back and take a breath. If you see your PM doing these things, take a few minutes sometime out of band to provide them with a little constructive feedback.
This is a post that I originally published last month in coordination with my friend Molly Lindblom, principal strategy consultant at Business Transformations. I hope you find it just as interesting as her readers did…
Amazon.com is pretty much world-famous for their customer-centric approach. Product Managers who want to build something new are supposed to start with their press release for the launch, and work backward from there. There’s no PowerPoint allowed, just written user goals and statements of purpose and goals, from which the product evolves to it’s launch. It seems that Jeff Bezo’s customer-first strategy is the be-all, end-all of Amazon’s success, and works brilliantly.
Except when it doesn’t – let’s consider this an analysis of the exception proving the rule, shall we?
There are a lot of things that Product Managers can be accused of “doing wrong” when it comes to our daily jobs. As a wise mentor once told me, if there’s not at least one stakeholder upset with you, you’re not doing your job right. However, that doesn’t mean that we’re without fault.
If we’re honest with ourselves, Product Managers can often wind up doing things that unintentionally set us apart from the teams with whom we work. Often, this results in an increase in randomization and a decrease in the trust that we’ve worked so hard to build and maintain with those from whom we need things on a constant basis. One of the requirements of leading through influence is that we are mindful of how we are approaching our daily duties and what impact our decisions are having on others around us.