Archives for July 2015

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.

The title of “Product Manager” seems to be a rather vague descriptor in the current world of technology. It’s become so useless, in fact, that some companies have decided to make things even more convoluted by creating even more useless titles such as “Product Editor” (how, exactly does one “edit” a product?). Because of this level of randomization, it’s difficult to know when a role is a “real” Product Management role and when it’s just a glorified project manager or a strategic marketing position. Never fear, though…the Clever PM is here to shine some light on the warning signs that you might be looking at a role that’s not really the one you want.

Most of the “Agile” and “Lean” product design and development practices that we follow in the modern age can be directly linked to the lean manufacturing movement from the 1940s and 1950s, largely attributed to the work of W. Edward Deming and his influence on the post-war Japanese manufacturing culture. Deming relied on a “Plan-Do-Study-Act” methodology that likely sounds extremely familiar to those who have implemented true Agile and Lean methodologies in their own work, and his influence is clearly seen in such famous processes as the Toyota Production System, Six Sigma, and Kaizen practices.

One of the things that all of these practices have in common, that is often missing from software development teams, is that they are focused on continuous or continual improvement of not only the product, but the process as well. While many software companies do somewhat focus on continuous improvement of the product, many neglect the equally important factor of working to continually improve the process as well.

Ironically, one of the most fundamental tools that Product Managers use every day to communicate requirements, expectations, and user goals to their development teams also sometimes seems to be one of the most difficult things to get right. Maybe it’s because many of us are used to the bad, old days of waterfall requirements, maybe it’s because our developers aren’t used to solving problems, or maybe it’s because our stakeholders and upper management expect certainty in what we’re going to do and how we’re going to do it. Regardless of the reasons, it’s absolutely essential that we master this tool and push for its proper use whenever we can. Properly-formatted, well-written user stories are the cornerstone of a user-centered design pattern — and stating a problem that needs to be solved in a way that allows developers the freedom to solve it in the way they deem most appropriate is a talent that all Product Managers can benefit from. [Read more…]

As a Product Manager, sometimes we get so caught up in either the macro or micro concerns of our day-to-day lives that we forget that getting shit done is our primary job. It does no good whatsoever to have our product remain in a constant state of development, with projects that get put on the shelf after being half-complete, in preference for the new hotness over what’s now old-and-busted. As a Product Manager, we’re not only in charge of making sure that we’re doing the right thing at the right time, but also that we’re actually finishing what we start — and that what gets done gets into the hands of the customer as soon as reasonably possible. Iterative development is literally impossible to do within the confines of your four walls; unless you’re constantly releasing a stream of iterative improvements, you’re just not getting it done.

As a Product Manager, we all have very close ties to our product — in some ways it’s our metaphorical baby. And like any parent, we tend to focus on the good parts of our product — the problems it solves, the efficiency that it provides, the benefits that everyone who uses it gets to avail themselves of. Unfortunately, the inverse of that is also true — we also tend to overlook the areas in which our product doesn’t quite meet our customers’ needs, where it barely misses the mark in competitive comparisons, and where it marginally loses out when compared side-by-side with other offerings.

And when these things are pointed out, some product managers immediately turn defensive — saying things like “they just don’t understand” or “they’re not getting the right training” or even “sales doesn’t know how to position”. Unfortunately, all of those things are actually your problem to solve, and sometimes you’ve got to accept some lumps in order to figure out where your biggest opportunities to improve actually lie.

Every so often, the question comes up in conversation or online — “What’s the biggest mistake that a PM can make?” And it’s actually a hard question to answer, because there are so many possible candidates:

Thinking you’re the customer;

Not validating your proposals or approaches;

Relying only on anecdotal “data” when making decisions;

Dictating priorities and goals rather than negotiating them…

But I think the single biggest mistake any PM can make is hiding the truth from the stakeholders and from upper management, which is a mistake that many make and many feel forced to make on a daily basis. Here are some common causes and ways to avoid this incredibly serious mistake…