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.”
Migrations
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.
Tags: developer, PM, product manager, work relations
Comments and trackbacks
1. Yishay Ben-Shimol | September 10th, 2008 at 8:49 pm
My dear friend,
you could postulate for only two kinds, PM and AM.
The first is the good one, since he’ll do his job and you’ll be home while it still PM next to the hour mark in your watch, while the other thinks he’s doing his job only if you get home After Midnight.
2. Stewart Rogers | September 10th, 2008 at 10:13 pm
The fundamental flaw in this theory… your Product Managers should not be ‘owning’ the gantt chart. Fun read though, thanks!
3. Ran Arad | September 11th, 2008 at 12:59 pm
@Yishay:
I thought all PMs are the AM kind, that it’s just the way they do it that changes
But seriously, Any PM can have you work weekends if you (or your manager) are not assertive enough.
@Stewart:
I agree, the Gantt chart is made by you (the programmer/manager) and for you, not by your PM. however, it’s the PM that decides which features are in the Gantt chart and which are left for future version, and you have to give the costs to these decisions.
And if you’re not too careful with these costs, it will be you, not the PM, who will be responsible for the late night work.
4. Todd Bashor | September 13th, 2008 at 12:26 am
Good write up. I like to think I fall into the true, true quadrant of product management and I’ve certainly worked with people in the other quadrants. Your assessment of the two primary variables is accurate and your final comment about how the PM’s type can change based on the context is spot on.
5. Guru | September 15th, 2008 at 6:47 am
Were you a consultant before ? – I thought 2 * 2 were their specialty
.I think the two varables you have considered are pretty true for most software products – there could be a case for people with domain skills who would fall in exclamation and be very valuable to the product as a whole (sales background person for salesforce.com for e.g. ? )
6. Howard | September 15th, 2008 at 8:04 pm
This is hilarious, and I think pretty accurate. As a PM who was a hardware guy, I think the bottom line of what is needed and another variable which makes all the difference is the big R; respect. does the PM have the respect of the management team? If he/she does, then he can make things happen. If not, even if a superstar, guaranteed that things will go horribly wrong. If he/she does have the respect and is one of the other quadrants, then the whole checks and balances will fail and you might as well sell your stock short.
7. Mara Wormwood | September 16th, 2008 at 7:01 am
Hi Ran,
I think that there should be a wider audience for such a marvelous article.
I’d like to translate it in Russian and publish in dev-related blogs with link to this original post.
Would you mind if I do that?
8. Ran Arad | September 16th, 2008 at 8:20 am
@Todd:
Thanks!
@Guru:
I wasn’t a consultant, but someone told me that PMs wouldn’t understand it without a 2X2 chart.
The Exclamation quadrant is indeed very good. Some project managers will even prefer it if the PM won’t get too technical.
@Howard:
I think everyone should have some respect to the management team. a programmer without respect to his manager will do things “his way” causing all kinds of havoc. PM do, however, have more potential for havoc.
9. Erik Josowitz | September 16th, 2008 at 10:54 pm
I think you need one more “interface” for your PM taxonomy:
Constantly changes mind: yes/no
This would add another 4 types of PMs–
Your 4 where Changes = False and then the Changes = True varieties:
Strategist (tech=true, knows=true, changes=true)
Sales VP (tech=false, knows=true, changes=true)
SE (tech=true, knows=false, changes=true)
Marketing VP (tech=false, knows=false, changes=true)
10. Ran Arad | September 17th, 2008 at 1:39 pm
@Mara:
Sure, you can translate it.
@Erik:
I assumed that (for PMs at least) “knows=true” => “changes=false”, but why do you consider marketing VPs as the lowest of the low?
11. Oren Markovitz | September 18th, 2008 at 11:05 am
Very nice work. The next step is trying to figure out the distribution (as R&D guys see it vs. how PM see it). I think I can place a sure enough bet on this
Trackback this post | Subscribe to the comments via RSS Feed