Product Management Mistakes

Being in the role for in extremely long time, I have uncovered a lot of truths, and hidden aspects of the expectations for the product manager. Now, I would like to discuss some of the common mistakes, misunderstandings, and outright WTF things that I see over and over again.

From assumptions that we make, or things that seem obvious to us, but aren’t in general, and what product managers think should be common knowledge. This should be an eye opener, and surprising to many.

Here we go!

What is it we do anyway?

As in, how does the {company|business unit|division|product} make money. On the surface this would seem obvious, but I can assure you that if you ask any 10 people in your local group what the “it” is, they will answer wrong. Sure, they might say “we sell XYZ product”, and that is sort of true.

The “mistake” here is assuming that everybody knows what the company does.

But do they know who buys it, why they buy it, why they spend their money, are they happy customers (the cult of NPS and CSAT is improving this general knowledge.) Yet while they may get that we sell something that customers buy, they often can’t articulate the why, and what value they get from it.

You might think that the job of educating the staff of what your company does – and more importantly how they make money – is the responsibility of senior leadership, and strictly speaking it is, but you would be remiss if you dismiss this as Not Your Job. In reality, if you want to raise your capital, this is a golden opportunity. Have a crisp, correct explanation, be patient (as in no eye rolling – remember, your co-workers often have narrowly scoped roles where they perform a fixed function without knowing the big picture) and gain satisfaction when you see the light bulb turn on during your explanation.

I can’t count the number of times I have done this remedial education at every company I have been at.

Results matter more than the process

This one cuts to the bone. At virtually all companies I have been at, there is some form of a product lifecycle (PLC) process. A stage gate driven process, with artifacts and document requirements, with fixed deliverables, and (usually) a full RACI for each responsible team.

Unless you are at a tiny company, or a company that has only one product, I am willing to bet that this reflects your scenario.

However, many – if not most – product managers chafe at the process. Complaints that the documentation is too difficult, or that the process slows down the program, or that Agile means we don’t need these artifacts and thus they are dinosaurs of the past.

For whatever reason, corners are cut, approvals are skipped, artifacts aren’t done, or are done cursorily, and in the interest of velocity or innovation, the PLC starts to get strained or broken.

I have heard a lot of excuses. “The process gets in the way” or “it slows us down”, or “ain’t got time for that” are common, and increasingly, I am hearing the excuse that Agile doesn’t require up front requirements so we stopped writing the PRD or MRD. Yet, at the end of a program that failed, or failed to yield the expected results, it is clear that in the post mortem that there were ample signs along the way that it was off track, and still, nearly 90% of all products fail in the market place.

You can follow processes, including governance rules, and still be agile. It just requires some discipline. It is your job to bridge those worlds. Own it.

Corollary: If jettisoning the rigor improved product development success rates, we would expect to see the number of successful products increase, and that is not borne out.

Remember, at medium to large companies, these arcane governance policies, and PLC processes were put in place because of a prior bad outcome. Grumble about them, question their validity, but don’t ignore them. I can assure you that if things go wrong, and you haven’t completed the process artifacts, gotten the explicit sign offs, and provided visibility to the leadership, you will wear the failure on your shoulder.

Alas, I am somewhat old school, and like to have a PRD with some idea of what the end state is up front. I revisit it every gate, and if we pivot, it get adjusted. But it is an important artifact, and one that has covered by bacon over and over.

An early boss of mine had a phrase: “process shall set you free” which I think he said in jest originally, but that crystallized my thinking, and it has prevented some pretty large blunders.

Thinking you are the “customer”

This is something I have written about before but it bears repetition. It is a mistake to literally substitute your desires, needs, views for that of the customers. Partially this is the trap of hiring a product manager that is a deep SME (subject matter expert), or a power user. The temptation to overlay their thoughts, views, expectations is too great.

This is also why I am an advocate of a product owner that isn’t the product manager, beyond the fact that the PM as PO under-prioritizes the importance of that function.

Still, too often, the original thesis, the initial MVP, the original end goal is far too often poorly validated, and then locked in. My bet is that this early coloring of the direction or strategy, this application of bias, is a significant contributing factor to the high rate of failure.

This is also why, like Rich Mironov, I prefer to hire people who are experienced product managers, over domain experts - who then need to be brought up to speed with the product management skills. Deep domain expertise seems like a benefit, but alas, every (and I do mean every) time I have gone against this, I have regretted it.

Remember, you don’t build products for the 2% of your users who are experts, but for the entirety of your market.

One place I was at, that made instruments that were used for bleeding edge research, where the product managers were all PhD physicists, an MRD had this gem in the body:

“If we make the product easy to use, and to get good results from, then new users will not experience the epiphany when they master the instrument.”

Seriously, they advocated keeping it so complex that like a pipe-organ player in a cathedral, it takes years to gain proficiency, and decades to master. Yet the “PM’s as the Customer”, saw nothing wrong with this being baked in.

Stunning.

Removing an esoteric feature that doesn’t seem to be used

If you have a product that has been around for a while (as in a decade or more), it likely went through a phase of “feature explosion” where you added capabilities and features to it because:

• an executive heard a peer comment on it missing
• a sales case was important enough that you just added the feature(s) to get the deal
• in an earlier version of the product, it made sense, but nobody remembers why (this gets back to the importance of the PRD and other artifacts)

Or anyone of a dozen seemingly benign reasons.

However, once a feature is in, especially in the realm of enterprise software, it becomes a risky proposition to remove it.

It can be archaic, it can be a use case that is no longer applicable, it can be a feature that should never have been added, especially if your product went through a phase of “feature farming”, but once it is in, I guaran-damn-tee you that someone, some important customer, someone who has the phone number to your CEO, uses that feature, and more importantly, depends on it.

You can move to a cloud solution, build in analytics, report on usage, and make a well-reasoned, “rational” decision to remove something, and once you do, the lag to complaints to your support team is measured in hours.

Don’t believe me? Try it. Especially in the realm of enterprise software.

The better answer is to not have added the feature/function/capability at all in the first place. Easier said than done though.

Summary

This is hardly a complete list, and likely there will be many more follow-on posts. I hope that you never experience these, but if you spend more than one or two trips through the product manager role, odds are outstanding that you will experience the thrill of dealing with these issues. Don’t make the same mistakes.