Should Product Managers Know How To Code? Steve Jobs Couldn't...

Last week I was in a spirited debate with @jkuramot over at The Oracle AppsLab about whether or not Product Managers need to know how to code.

Jake says yes, I say no... Primarily because we disagree about what a product manager actually does...

First, I think I should answer the question, what the heck does a Product Manager do all day long??? Most of the time when my wife tells people she's a "proDUCT manager" they think she's a "proJECT manager"... which isn't even close. I've met quite a number of Product Managers, in different industries, and I can safely say that most of them do significantly different tasks... And many of them disagree on what their main focus should be.

Why such contention? The best explanation I ever heard was this: a product manager is more or less the CEO of a product line. Which means that pretty much anything that will help your product, you should do... which means a million different things in a million different situations. In order to be successful, you need to know a little bit of everything -- what features to add, what new markets to attack, what sales people need to sell -- in order to be an effective Product Manager.

Rich Manalang did not like that definition, saying it was too broad... he preferred the idea that a Product Manager is responsible for just the "life cycle" of the product. In other words, vision, design, creation, testing, support, and end-of-life decisions. In my opinion, this definition is far too narrow... it's far too "developer centric" in that you focus mainly on new features, training, and support... but neglect such very important things like what effect does the existence of this new product have on the rest of the company? An individual Product Manager might not know this... but hopefully somebody on the Product Management team does! If not, then nobody is building the path between a successful product launch, and a successful company.

If the Product Manager isn't responsible for that critical task, then who the heck is???

Back to the original question... do technology product managers need to know how to code? I say, emphatically no... It's a useful skill to have, don't get me wrong... but I disagree that it's a requirement for everybody on your product management team.

Let's be clear -- programming skills are primarily useful to a Product Manager as a communication technique. A prototype speaks volumes about what features people want... but that's about the limits of it's usefulness to a Product Manager. And, of course, if you are a good communicator, you can certainly do without it.

"the three great virtues of a programmer: laziness, impatience, and hubris" -- Larry Wall, inventor of Perl

Now... what if you are a Product Manager in charge of lazy, lazy developers? This happens. Maybe you want a feature, but the developers don't want to add it. So the developers give you the run-around so they can go back to playing Halo. Well, in those cases it helps to know how to program, so you can call out your developers for being lazy virtuous... but this only works if you know a great deal of the existing code base as well! Just because it works in a prototype, that doesn't mean it will work when integrated into the product.

"When it comes to understanding code, if you wrote it 6 months ago, it might as well have been written by somebody else" -- Ancient Geek Proverb

Knowing the code base is a pretty hefty requirement... even seasoned developers don't know everything about their product... so it would be nigh impossible for a Product Manager to do so. It's more important that their minions think they know the whole code base, to try to keep the lazy virtuous developers honest. The best technical Product Managers know ho to "dive deep" into the product, and know well a handful of obscure but important details about the system... this inspires a healthy amount of fear.

Ultimately, Product Management is so important and so difficult, that it's almost impossible to find all of the skills you need in one person. Small companies do this, but as companies grow, they usually break it down into three teams... it's occasionally useful for the "technical" Product Manager to know how to code, but this rule does not apply to your whole team.

If you're looking for more info on this subject, I've heard great things about the Pragmatic Marketing Framework for designing a Product Management team.

Which is the main responsability of a Product Manager ?

I totally agree with this opinion, in fact a Product Manager should have some other technical and management skills that will be helpful (not obligatory) to communicate/relate the IT world with the Business World. It would be a plus for instance if the PrdMgr know to write code (in order to communicate and validate project estimates) also is very important to have PrjMgr skills in fact he is in charge of a big project : DEVELOP A PRODUCT after this he will need SALES / MARKETING SKILLS otherwise all the r/d effort will die in the Laboratory before reaching the stores. So at the end the Product Manager is a career path that should be constructed over IT developer skills, Enterprise Architect skill, Project Management skills and finally Sales and Marketing skills.

Dear Bexes

Dude, we're AppsLab, not Apps Labs. You know that already :)

First off, this isn't a one-ring thing. There are always corner cases.

We agree that prototyping is a good way to communicate, but I disagree that if I'm a good communicator, that I can do without it. Take for instance when I'm communicating with developers whose first language is not English. I might be the most eloquent communicator ever, but that could be for naught if the developers can't understand what I mean due to language barriers.

So, I communicate by showing, i.e. with a prototype, which I built b/c I can code.

And no, I don't need to know the whole code base, just understand at an intimate level what the product can do. Of course, the latter is a must-have for PMs.


Re: Dear Bexes

I think the only solution to this problem will need to be an expensive survey...

Developers, tech leads, sales people, marking people, and executives should be surveyed about who is an "exceptional" product manager, who is "average", who is "bad," and why. PMs could chime in as well. Then, the surveyors would need to examine what skill sets "exceptional" PMs have, which ones "average" ones have, and which ones "bad" ones have... and look for some patterns.

Of course, a salesperson would always prefer a sales-y PM, a developer would always prefer a techie PM, so you'd have to ask a lot of people a lot of questions before the answer will present itself...

Your point about ESL developers is well taken, but then again, shouldn't that be role of the "tech lead"? You know the management rule of thumb: four people need a coordinator. That coordinator needs good communication skills: ESL or not, proficiency in the company's official language is mandatory. The tech lead is not the "boss" of the other 4 -- although he may think so -- he's just the one who both knows the code base and can communicate with the PMs. The PM need not be able to talk with the other 4 as long as he can communicate with the tech lead.

Of course... if your team is small, then the PM and the tech lead might need to be the same person... in which case, yes, the PM needs to be a techie. But then again, if your team is small, then any skills your PM lacks will be reflected in the product's measure of success in the marketplace...

The Bex doth protest too much, methinks.

I'm beginning to wonder if you're actually *against* PMs knowing how to code, i.e. you actively don't want them to know how to code for some reason.

Which makes me wonder what you really think of we PMs who do know some code :)

Anyway, are you going to correct the post to say AppsLab or not? We've worked so hard on the brand and all . . .

Re: The Bex doth protest too much, methinks.

I'm beginning to wonder if you're actually *against* PMs knowing how to code

Not really... However, I do think it is a bad idea for them to think they are better coders than the people who are doing the actual coding... That will always lead to chaos. The pointy-haired-boss scenario, and all. It's probably best that they have the talents necessary to be a PM, and learn whatever skills are needed along the way.

It's more important that a PM be a fast learner, than they know any one thing...

And yes, I did fix the post ;-)

If I write better code, then I'm the developer, right?

Just saying, if I think I write better code than the developers on my team, e.g. Rich and Anthony, then I should be writing the code, no?

You still don't have our name right. It's AppsLab. Not AppsLab, only one 'Lab :)

Re: If I write better code, then I'm the developer, right?

Not always... Leonardo da Vinci probably hired somebody else to paint his house... Bill Gates doubtless hired developers inferior to him to make Windows.

Let's take a step back

If the ability to code is primarily effective as a communications tool to convey a concept of what the product manager wants, then are there other tools out there? Certainly there are. Even a graphically-challenged person like myself can scribble a picture that roughly shows my vision, or if my vision is based on something else, I can simply say "I want something like Twitter" or whatever. Or I can convey what I want in text, via various communication methods, ranging from the general (marketing requirements) to the more specific (design documents).

However, I believe that being the CEO of a product doesn't mean that you have to come up with all of the ideas. Using the Steve Jobs example, he clearly had a vision of what he wanted to do, but at the same time he gathered people around him with their own ideas of what THEY wanted to do.

Any product is going to be created by a team, and the actual duties of people are obviously affected by the strengths and weakness of the people on the team. In my years in product manager, I did not consider myself a proficient coder (my brief professional experience in HyperTalk would only tangentially be applicable to the Java & web stuff our programmers were actually doing), and I did not consider myself a professional architect, but I believe that I made up for these deficiencies by communicating to those people who WERE good coders and architects, as well as to customers and to the other stakeholders of the product.

Re: Let's take a step back

I'd agree... although I do believe that the optimal solution is to have a product management team... the team should have all the skills we mentioned -- vision, communication, coding, marketing, sales -- but any one member of the team need not have it.

same argument in other lines of business

Several of us discuss this same topic in support as well. There seem to be two basic career paths for technical support personnel.
a) coming from a customer service background and learning the tech skills later
b) coming from the CompSci world (mostly programming) and learning or possessing the customer service skills

The overall mind set for tech managers seems to be that it's easier to take someone from a > b versus b > a and for the most part that has been true in the past. However, the trend now seems to be for the products themselves to get more and more complex to where even basic support functions are becoming hard without the background tech skills.

Just look at the upcoming 11g ECM releases and you can see the challenges the the people in the a) category

So, my thoughts related to this thread would be;

Having a background in programming helps in all functions of managing, supporting and delivering a tech product but ultimately it's how you work with your team that determines "good" from "bad". I think the background knowledge simply speeds up the communication between co-workers and/or customers.

Here's a specific example, when I started with "Stellent" like most people I didn't know idoc script but because of some core skills I was able to pick it up in just 1-2 days. Conversely there are still support people that struggle with even the most basic scripting functions inside a workflow event. Now, these people can usually get through those issues but it takes the customer much more time to explain and walk through the business process than someone that can just look at the code and see an infinite loop without even needing the customer to explain the whole process.

You sound like a product

You sound like a product manager from hell. How pointy is your hair? Do you talk to your developers this way? "Enough of your ones and zeros, Poindexter! Tell me about paradigms, and dynamic, service-oriented business solutions!"

Temper, Temper...

I'm actually a developer who has on more than one occasion had to take "demo-code" and ramp it up to "developer-quality" shrink-wrapped product. Very few people who know how to code have this skill.

In my experience, a good product manager does not need to know how to code. Most of the best ones I know lack this skill. When they do write code, they do it to explain the basics, like a proof-of-concept. That's sometimes 60% of the vision, but really only 10% of the code.

This article makes no sense

Steve Jobs actually was an engineer. He was designing chips alongside Woz way in the beginning. He also had an electrical engineering background and was a technician (albeit bad one) at Atari.

A huge point of Steve Jobs' success was his understanding of what was possible technically, so if you think you can achieve that hovering around instead of heading into the trenches, more power to you. Steve Jobs definitely spent his time in the muck.

I think you missed the point...

From Wikipedia:

"Jobs returned to Atari and was given the task of creating a circuit board for the game Breakout. According to Atari co-founder Nolan Bushnell, Atari offered $100 for each chip that was eliminated in the machine. Jobs had little interest in or knowledge of circuit board design and made a deal with Wozniak to split the bonus evenly between them if Wozniak could minimize the number of chips."

But that's kind of the point I'm trying to make... knowing what is technically possible is MUCH different than knowing how to write the finished code. Some people believe Product Managers should be required to know how to code. The analogy would be that Steve Jobs would have to know circuit board design in order to be a product manager at Apple...

I say, no... What's more important is, as you say, an "understanding of what was possible technically."


Since when did you need to be a mechanic to know what makes a great car?


You agree with the article then? Because that was kind of my point...

Recent comments