/ Product Management Essentials

When Product Managers Fail part 1 - Engineers

The Dude's last posting on product management was focused on how to grow a product manager. Today, the Dude is going to look at the reverse, and outline how new product managers fail when they come from other disciplines. Let the Dude preface this with “I know that there are plenty of exceptions to these reasons”, where poor fit people have been successful. The Dude has even seen some himself.

First off, nobody sets out to become a product manager in a tech field. You fall into the job either directly (you apply and interview for the position), or indirectly by just sort of doing the job. There is a third path, and this is usually where in the Dude's experience, the failures begin. The Dude will regale you with a story:

The Engineer

You are a pretty good engineer (software or hardware), running a couple of programs pretty efficiently and are recognized as a good program or project manager. The general manager of your division has a need for a product manager, either because of a departure, or the need to expand the team due to growth in the business. You get tapped, because you are a good engineer, and can manage a project pretty tightly. What happens?

First, because you are an engineer, you are, by definition, rules bound. You see the world through a lens of black and white. 6061 aluminum alloy has this hardness, and tensile strength, that optical filter passes such and such wavelength, and the sort. You are used to rigorous, analytical, and most importantly, a single – optimal solution to every problem.

Sad man Next thing you know, you are dropped into a role where chaos seems to reign. First, you find you are doing something that you have likely sneered at in the past, this “marketing” thing. In the beginning, it is inbound, handling input from customers, customer support (where if you are smart, you begin to immediately forge alliances), sales and sales reps. These are your eyes and ears. No longer can you immerse yourself into tables of physical properties, or the MSDN to solve problems. You suddenly are defining the problem that your team will have to solve. This transition from being a ‘solver’ to a ‘definer’ is difficult one, and often the weakest link in building a product manager.

Second is being thrust into the center of a cross functional team. I mean a true, high conflict, ego laden team with Sales, Marketing, Management, Support, and engineering. You will have to get these people into a room, and get them all moving in the right direction, which usually doesn’t have a poynting vector you can extract. Here is one of the biggest obstacles, and where many engineering transplants to product management stumble badly. Their nature is to guide the discussion in the direction of their former life (engineering), and favor the engineering faction. However, this is guaranteed to alienate ALL the other parties, causing them to tune out, and eventually leads to failure.

Third is comfort level with multiple communication vehicles. Product managers MUST be prolific communicators. Written communications include the various requirements documents, press release drafts, data sheets, brochures, applications notes, internal sales training material, customer facing communications, and recently, blog postings, web site copy, and others.  Most engineers can draft technical documentation fairly well, but lack the flair required for the rest (you might be thinking to yourself “Doesn’t Marcom do most of that?” Yes and no. The Dude has found that they need lots of direct help and guidance, so you are most likely writing all the early drafts on your own). Add to this the verbal communications, a clear presenting style, that can be effective at many levels, from technicians up to the C level executives.

Last, but not least, every engineer I have ever seen cross over has been utterly overwhelmed at the onslaught in email and other demands on their time. Product managers are the hub of activity, and you are directly addressed or copied on hundreds of emails EVERY DAY. I am often shocked when I visit an engineer and see that his daily inbox is on the order of 10 – 20 emails. Of course, their primary task is to decouple from the firehose of information, and focus on high value tasks to move the product/project forward. Compare that with product management where a typical day can have a roadmap presentation with a premier tier customer, a sales training session that you lead, detailed to an ECCN filing, drafting or approving a case study for Marcom, interviewing two candidates for an open position, explaining our activation process to a junior product manager and the program managers, and finally to triage the bug queue for our upcoming release iteration (and that was just my day yesterday), and you can see that it is a culture shock for someone who is used to being able to spend 3 hours at a time working a single task.

The Dude does want to point out that engineers can and have made the transition. They start out with the curiosity and the intelligence for the role, and, if they were lucky learned some of the communications skills needed in university. But they have to be willing to take a radical departure, to consciously shuck off the title of engineer, and make connections and bonds to the other groups that are key. They need more than a little humility ('smugness' and product management don’t mix). They need to become multitasking machines, task switching effortlessly throughout the day.

Not impossible, but far from a sure bet. Next time the Dude will explore failure from the non-techie side: Marketing


Like what you see? Why not join our mailing list for a weekly roundup of posts?