PM Should Know How to Code, Part 2

By Jake • March 18th, 2010 • 16 Comments

So, if you’re monitoring the comments on my post yesterday, Product Managers Should Know How to Write Code, you’ll know Bex (@bex) and I are having a bit of a disagreement.

This is good. I really like intellectual (vs. emotional) disagreement on the intertubes because it opens eyes to new viewpoints.

Too bad Bex is wrong.

He’s not really. I just wanted to write that.

Anyway, we’re not that far apart; it’s really a glass half full/half empty perspective difference. In this case, I’d say I’m representing the half full glass, which is out-of-the-ordinary for me, and it’s more like 80% full.

Meaning, it’s generally useful for product management to know how to code; it’s a should-have, not a must-have or a nice-to-have.

If you encounter the 20% that Bex discusses, you’ll definitely remember the negative experience, which makes sense.

As with anything, balance is key, and breadth of knowledge doesn’t hurt either. A PM who is too functional can lead to unusable or impossible to build software that needs to be redesigned by development (or other PMs), and a PM who is too technical can lead to design without empathy, one of my latest kicks.

Happy medium is happy.

Again, as with many arguments, there are corner cases. This is 80/20 stuff.

Anyway, add your thoughts there or here.

In a related note, Rich reminded me of this classic software cartoon, which always amuses.

Don't know whom to credit, wish I did b/c this is hilarious.


Possibly Related Posts

  • http://empoprise-bi.blogspot.com/ John E. Bredehoft (Empoprises)

    I intentionally didn't weigh in on the original post, but I'll add my two cents here. First, my perspective:

    1. I was employed for nearly a decade (2000-2009) as a product manager.
    2. The only professional coding that I have ever performed was some Hypertalk stuff back around 1990.
    3. In general, my coding experience is extremely dated. Not counting Hypertalk (above) and simple HTML, my only programming languages that I've ever used are Pascal and BASIC. And back when I was using BASIC, line numbers were required.

    When I began as a product manager, one of the senior developers took me aside and offered me advice – “Don't worry about the 'how,' worry about the 'what.' We'll take care of the 'how.'” For better or worse, I pretty much followed that senior developer's advice. While I'd occasionally referee some things, I personally didn't get involved in a lot of discussions about feature placement, compatibility with so-called standards for Windows general usage, etc.

    In cases in which I did get involved – one example involved the use of the middle mouse scroll button to execute a function – it didn't really matter whether I could code or not. This was a higher-level discussion which involved a balance of the aforementioned so-called Windows standards, the needs of some customers, and the needs of some other customers.

    In fact, a lot of my work was on this higher level, and really involved the best way to respond to high-level customer needs. My product was not a volume product – the entire industry has probably only deployed a few thousand of these products – so individual customers are very influential. My favorite example involved one customer who required that a particular application NOT allow editing of textual data, while another customer required that the same application ALLOW editing of textual data. I did not need coding experience to realize that this needed to be a configurable setting in the application.

    There's also another danger that Bex missed, although the cartoon alluded to it. A code-knowledgeable product manager – or a developer – would have enough knowledge to tell a customer that some action is not recommended. For example, one shouldn't use the middle scroll button on a mouse to initiate a function – if something is so critical that it has to be done in one click, then the right mouse button is the way to do it. But in this case, the phrase “the customer is always right” comes into play. In this case, the customers spend long shifts looking at image data, and anything that requires two clicks is one click too many. Heck, if it makes sense to the customer to initiate a function by pressing the computer's on/off switch, then the developer and product manager had better figure out a way to do it. Obviously these examples won't work in a mass consumer market or mass enterprise market, but in certain cases it may be advisable for a coder to do stupid things that a coder should never do.

    I'll be the first to grant that my examples probably fall within the 20% category, but I'd share them nevertheless. And they don't negate your assertion that it is good for a product manager to have both technical and business skills – but people have to realize that even the product manager with supreme business and technical skills may have to do things that are technically stupid and/or unprofitable.

  • http://theappslab.com Jake

    Interesting. Your story about competing customer requirements represents enterprise software perfectly. Frankly, you probably have to do both, which adds to the setup/administration. This is why enterprise software is hard b/c it must meet all the competing requirements of its customers.

  • http://empoprise-bi.blogspot.com/ John E. Bredehoft (Empoprises)

    And one would think that consumer software would have more of a need to do this because there are more customers, but enterprise customers are bigger than consumer customers and therefore exercise more power. Microsoft's consumer division might not care what I think, but you can bet that Microsoft's enterprise division cares what Toyota thinks.

    Incidentally, your Fourface post tangentially inspired me to muse on such matters over a week ago.

  • http://theappslab.com Jake

    Glad I inspired tangentially inspiration, makes me sound like a guru :)

    And yes, number of customers vs. size of customers is the big difference between consumer and enterprise. Of course, many consumer PMs have no customers, only users.

  • http://empoprise-bi.blogspot.com/ John E. Bredehoft (Empoprises)

    Technically they do have customers. Twitter's customers, for example, are Google and Microsoft. But that's going off on a whole different tangent…

  • http://theappslab.com Jake

    With the launch of the @anywhere platform, I suppose they have customers. Not sure I'd classify Google and Microsoft as customers, since the service isn't *for* them. They're just eavesdropping on it.

  • http://empoprise-bi.blogspot.com/ John E. Bredehoft (Empoprises)

    If you define a customer as someone who pays you, then Google and Microsoft are definitely customers. The $25 million Twitter got from Google and Microsoft is more than they got from you or me.

  • http://theappslab.com Jake

    Dunno. Customer pays for a good or service, not someone who just pays you. There's no good or service being provided, just access for indexing. Twitter shouldn't treat that as a product. It's a lucky biproduct.

  • http://theappslab.com Jake

    Kinda feels like a partner relationship.

  • http://theappslab.com Jake

    With the launch of the @anywhere platform, I suppose they have customers. Not sure I'd classify Google and Microsoft as customers, since the service isn't *for* them. They're just eavesdropping on it.

  • http://empoprise-bi.blogspot.com/ John E. Bredehoft (Empoprises)

    If you define a customer as someone who pays you, then Google and Microsoft are definitely customers. The $25 million Twitter got from Google and Microsoft is more than they got from you or me.

  • http://theappslab.com Jake

    Dunno. Customer pays for a good or service, not someone who just pays you. There's no good or service being provided, just access for indexing. Twitter shouldn't treat that as a product. It's a lucky biproduct.

  • http://theappslab.com Jake

    Kinda feels like a partner relationship.