I recently read a post written by a (cranky) Product Manager (PM), describing different programmers from a PM‘s view. The whole post is decretory and self-centered (as usual for cranky PMs), evaluating programmers not as people but as clichés, and overall is quite insulting. The easy thing for me would have been to write an equally decretory view of PMs: the MBA-PM, the “I was a developer guru” PM, the “I got here because I was a bad developer” PM and the “I got here because I was a bad developer but I THINK I was a developer guru” PM.
Instead, I decided to take the high road:
I got together with some of my peers to discuss the characteristics of a PM. We’re a technical bunch, so it took us just 30 seconds to reach a conclusion: PMs have but two configuration variables from which all interactions with them (APIs?) derive:
- Has technical skills = (True/False)
- Knows what he wants = (True/False)
All the rest of a PM’s character is just volume control, circumstances, personal compatibility and personal hygiene. If you take these away, there are just four combinations of PMs which derive from the above two Booleans.
[For PMs who bump into this post by mistake, here's a graphical representation:
Figure 1: Code Of Contact's Configuration Table for a PM
Got it? Good. Now I can proceed.]
Super Star (Tech = True; Knows = True)
If that’s your PM, you’re a lucky dog. He will not only know what needs to be done, but he will know what can and cannot be done and in what costs. Not only will product demands be technical in nature and broken down to modules, they will be realistic and leave room for last minute changes. He will watch your back from hidden pitfalls; he will provide that crucial correction to your design; he will even offer to code that tricky little feature. The only problem is that you can’t bullsxxx him. It’s not a biggie; he knows what “black-ops time”* means and will gladly put some on your Gantt chart. You may feel a little obsolete and overshadowed, but that’s just you. He’s great; trust me.
Quote: “I thought of a cool new feature for the product, so I coded it last night.”
Exclamation Mark (Tech = False; Knows = True)
It may be tiring to explain repeatedly that effort estimations are actually the result of, well, effort. You may feel like someone with complete lack of skill is trying to do your job. If you do, count your blessings: someone has a vision for your product, and is likely to take you places if you just let him. You will eventually settle in one of two conditions: either he becomes technical, or you learn to be assertive. Either way is good.
Quote: “What if we implemented it for just 80% of the cases: will it take 20% of the time?”
Code Monkey (Tech = True; Knows = False)
That’s not a very good combination. I mean, that’s you. And two technical people who do not know what they want is a recipe for stormy weather. You’ll be arguing over the best way to do things, but that’s not your real argument: you should be arguing about what to do, but neither of you knows that and neither of you will admit it, so you keep to technical arguments. It may be his first role as a PM, maybe he’s new to the field or maybe he’s just indecisive, but until he charts the course on the map, you’ll both be fighting for the steering wheel. Do you think that’s bad? Think of the situation when his previous job was doing yours. You have to weather it out, mate, and refuse to enter technical discussions with him. Only then will he be able to concentrate on his real job.
Quote: “How about we’ll do a complete rewrite of this module? Why? I don’t know!”
Puppy (Tech = False; Knows = False)
In some ways, this combination is better than the previous one. Sure, he doesn’t know what he wants, and how it’s done, but he has you, and you’re there to take care of him and explain things to him and to take the blame when things go horribly wrong, so no need to worry, right? This will be a good time to dust off your plans for extensive rewriters and obscure (yet challenging) features. Not that you’ll get to finish them. He’ll probably change his mind when you’re in the middle of it, decide that some new market trend he just heard of is the next big thing, and scratch all your work – unless you can do it in “black-ops time”*. Then you’ll be chasing “next big things” for a while, whoring out to all kind of customers with strange demands, and never finish anything until one of two things happens: either he’ll get technical, or he’ll finally know what he wants.
Quote: “If we’ll implement the thingamajiggers for the whatyoumightcallthem we will surely conquer the market.”
The configurations discussed are not inherent, personal flaws; these are just the current configuration values. A PM can be technical about one product and know nothing about another. He could be passionate and have a clear vision for one product, and will not know what to do with another. He can get tired of a product over time, and he could learn the ins and outs of it enough to handle customer bugs. So ask not what your PM can do for you; ask what you can do to make your PM more tolerable.
* Black ops time - time left as a buffer or from tasks finished early. This time is used for doing things the developer really wants done but his PM would never dedicate time for in the project Gantt: rewriting that fiddly locking mechanism, scripting the release procedure, hunting down the memory leak that happens 0.0001% of the time, going over the new guy’s code and giving him the what for, etc.