Product Management is Messed Up

Today I am kicking off a series focused on product management.  Some people in this discipline are terrific at what they do.  In my experience, the majority are terrible, mediocre at best.

Finding a good product manager is like panning for gold.  For every bucketful of mud and silt, you may come up with one or two flakes that are worth something.  Occasionally, you find a golden nugget of significant value.  Every pan is loaded with fool’s gold.

Over the past 25 years, I have worked with a few decent product managers.  Only one or two stand out as exceptional.  Most are downright useless.  I often wonder, why do software companies continue to waste money on employees who contribute so little?

Maybe I have been working at the wrong companies.  Maybe most of the talented product managers get hired by the greats like Apple, Google and Electronic Arts.  It could be that by the time you get to insurance software, the talent pool is a bit thin.

I suppose many companies employ people who do not contribute much if anything.  I have interviewed (and not hired) plenty of “software engineers” who cannot write a line of code.  A company with poor hiring practices is bound to attract lots of these fakers.

With product managers, even a decent interview process seems to let in losers at a rate of 50% or more.  One criterion of a good product manager is an ability to explain things.  Someone who is a good talker can sound reasonable.  Never mind if what he says is nonsense.  A convincing faker can get through product management screening and last in the role for years.

Frankly, I think the problem with product management start with the vagueness of the position.  The product manager is supposed to understand what customers want and write specifications that describe what a product needs to do.  These are called features.

During development, the product manager needs to answer dozens of questions to create a single feature.  Should the buttons be red, green or blue?  Are users allowed to delete things?  What kind of security rules are required?  What is the expected peek demand on the system?

These questions are wide-ranging, from cosmetic to deeply technical.  They require thought, research and experience to answer intelligently.  Finding one person with such a range of knowledge and skills is difficult.  If that person was technical enough to build the system, she would be an engineer, not a product manager.  So companies hire the best they can find, and punt.

Many product managers answer with opinions disguised as facts.  For instance, the product manager might say, “Customers like blue better.”  Is that conclusion based on survey results or research in psychology?  Is the product manager simply fond of blue, or is blue the latest fashion in UX design?

Then the product manager has to fend off other people’s opinions.  What does the typical engineer know about color?  Probably very little.  But about security, say, you might expect more.

Let’s say an engineer asserts security requirements—e.g., the system has to use TLS and enforce multi-factor authentication.  Are those real requirements or opinions?  (Hint: those are real requirements if you care about security.  Does your system need real security?)

Another engineer might say that passwords should be changed every month, which might be more a matter of opinion.  Changing passwords too frequently leads people to write them down, which is less secure than keeping a hard-to-guess password for longer.  How long is “too long?”

If implementing an engineering requirement makes the product more difficult to use, how would a technically challenged product manager know whether to push back.

On the other end, the product manager is trying to understand “the customer.”  The best will talk to actual customers.  That requires social skills and enough awareness of psychology to intuit what is behind what customers are saying.  The customer said she likes blue, but does she notice that the blue theme makes her sad?  Maybe what she really wants is to speed up her work so she can accomplish more or go home sooner.

Clearly these problems are quite different from the technical ones.

Next time, I will share ideas for how to break product management into separate, more achievable jobs.  A refined division of labor would give competent people a better change to succeed and expose the fakers.

Later I will tell you how to spot the fakers.

For now, I leave you to ponder the idea that the job of “Product Manager” is far too broad.  Even the best do what they can and fake the rest because they have to.  Let’s help them first.

After that, we’ll turn over some rocks.



4 thoughts on “Product Management is Messed Up

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s