Product Managers Should Know How to Write Code

By Jake • March 17th, 2010 • 77 Comments

I’ve been absent for a while, not sure if this tweet from Chet was related to my silence, but if it was, I have an excuse.

Paul and I just returned from Austin and SXSWi, which ran March 12-16.

For those unfamiliar, SXSW is comprised of three festivals: film, music and interactive. It began in 1987 as a music festival, and in 1994, the film and interactive festivals were added. SXSWi includes very bright people in web design and development, emerging technologies, entrepreneurship, and game development and design.

SXSWi has recently been the launchpad for web apps like Twitter, which won the SXSWi Web Award in 2007, and foursquare, which launched at SXSWi in 2009.

Anyway, we spent four days in Austin learning about everything from How to Design for the 15 Minutes to Monkeys with Internet Access, Clay Shirky‘s (@cshirky) talk and probably my highlight of the conference.

Rather than comment on each of the panels and sessions we attended, I’ll cover a few of the recurring themes I found interesting and useful, the first of which is that product managers should be able to write code.

Of course, I’m referring to software product management here, and I’m not suggesting that PMs should write the production code. There are always exceptions to the rule, natch. Insert disclaimer.

The ability to understand what’s possible leads to better design, and this becomes much easier if you get dirty with the code, at least at the enough-to-be-dangerous level.

So, a PM must understand both the user and what s/he needs the product to do and what the product can actually do.

You have to be passionate, which leads to breaking, modifying, hacking and bending product to your will. You can’t do any of this without getting dirty with code.

OK, so you think this is obvious?

Most job descriptions for product managers do not require past experience writing code, whereas business skills are usually required. Over the years, I’ve seen a lot of MBA-type candidates apply for PM jobs, which leads me to believe that business schools tell their graduates they should pursue PM jobs.

There is nothing wrong with this. A PM needs those skills too.

Tinkering level experience with code should also be on the list.

There’s been a shift toward this. Google hires developers as product managers. PMs like Chris Messina (@chrismessina) design product, even though they’ve never had development jobs. However, if you’ve ever heard Chris speak or met him, you get the sense that he could hack something together, even though he says he gets developers to do that for him.

Even Google’s designers are code savvy, as we discovered in Prototyping Web Apps: Nobody Loves a Wireframe, where Darren Delaye (@darrend) and Michael Leggett (@leggett) described their experiences with wireframes, mockups and prototypes.

The short version: it’s much easier to get someone to understand what you want by creating a working prototype that can be touched and felt.

Therefore, Darren and Michael both write code.

Paul and I both left SXSWi newly invigorated to continue our education in code. Luckily, we’re not starting from scratch.

Paul has dabbled in Rails a bit, and I used to write tons of PL/SQL (packages, stored procedures, Forms, Reports) back in the day.

My knowledge of the Oracle stack has kept me in PM for a long time, and it’s time to learn the web app tech stack.

Somewhere, Rich and Anthony feel an icy draft.

What do you think? Should software PMs know how to write code?

Find the comments.


Possibly Related Posts

Newer Comments →
  • http://twitter.com/oraclenerd oraclenerd

    YES! (I wish I could make that 72pt Arial Bold or something)

    That's all I have right now.

  • http://theappslab.com manalang

    Totally… totally… totally agree. So, when are you going to learn ADF? :-)

  • http://friendfeed.com/jenn2d2 Jennifer Dittrich

    Since "tinkering level" is what is specified, I agree. On the flip side, programmers should be good at conveying the strengths and weaknesses of their own discipline up front, and through the length of the project. It can be frustrating to deal with outlandish expectations, but it is also frustrating to receive incomplete information on which to base expectations.

    This comment was originally posted on FriendFeed

  • http://www.matttopper.com topperge

    He just said you need to know how to program, nothing about programming in a worthwhile language. Like he said, he knows PLSQL. ;-)

  • http://theappslab.com Jake

    @Rich: I'll learn ADF as soon as you do :)

    @Topper: Raimonds' Ruby adapters are making my PL/SQL skills relevant again :)

  • http://theappslab.com Jake

    There are certain exceptions, e.g. areas of domain expertise that are very functionally focused. In those cases, the teams needs an architect between the requirements and the design who can combine requirements with technically feasible design. That architect needs to know how to code.

  • http://friendfeed.com/dgentry DGentry

    If only so the PM can tell when their developers are lying to them…

    This comment was originally posted on FriendFeed

  • http://friendfeed.com/jkuramot Jake Kuramoto

    @Jennifer: I neglected to mention your point about outlandish expectations, an important one. It’s incredibly frustrating (and expensive) for developers to get unvetted design that needs to be validated.@DGentry: Interesting point :) I’ve never worried about that and not necessarily b/c I can write a little code.

    This comment was originally posted on FriendFeed

  • http://friendfeed.com/jkuramot Jake Kuramoto

    @Jennifer: I neglected to mention your point about outlandish expectations, an important one. It’s incredibly frustrating (and expensive) for developers to get unvetted design that needs to be validated.

    This comment was originally posted on FriendFeed

  • http://friendfeed.com/dgentry DGentry

    Has your development team ever tried to claim that a desired feature isn’t just hard but actually impossible to implement? Has a developer added time to a schedule to maintain unit tests (meaning: they didn’t just refactor, they rearchitected and broke all the unit tests)?

    This comment was originally posted on FriendFeed

  • http://friendfeed.com/thomaspower Thomas Power

    hear hear

    This comment was originally posted on FriendFeed

  • christophe claude

    I am a PM and I can write code. I do it on regular basis to code prototypes or even to analyse market data (with MySQL in place of excel). I alway took what you say for granted btw;-)

  • http://bexhuff.com bex

    I'm going to go ahead and disagree with you on this one… a little.

    A little knowledge is a dangerous thing… it's OK to have a rule that PMs be “dabblers” in code, provided that they stay humble about just being “dabblers.” Otherwise, this could be a recipe for “know-it-all-itis.”

    When developers say they want a PM who knows how to code, what they usually mean is that they are looking for somebody who can understand the difficulty involved in writing code. Prototypes are not difficult. Tinkering is not difficult. If a PM knows these things, they can whip out a quick example — which developers prefer to verbose and ambiguous design documents — but that's pretty much where the value ends.

    What about the hard stuff? Security? Performance? Scalability? Risk management for late changes to the code base? A “tinkerer” simply will not have any appreciation for the phrase “software is hard.” Quite the opposite: they might actually think they know everything, and expect something is easy to implement just because they made a prototype with Rails in 5 minutes.

    In short, PMs who code are very helpful at the BEGINNING of a dev cycle… but they can be a significant burden at the end, if they don't stay humble.

  • http://twitter.com/oraclenerd oraclenerd

    I'll have to agree with Bex in this instance. He articulated a point that I was unable to.

  • http://theappslab.com Jake

    It really makes a positive difference in designs and in communicating with developers.

  • http://twitter.com/juanca Juan Camilo Ruiz

    Totally agree, gives u better understanding of the product.

  • http://theappslab.com Jake

    Careful, your mentions of Rails and tinkering (borderline hacking) may upset the Rich, and I can't have that :(

    I'm actually not sure the PM you're talking about exists, at least, not for long. Someone like that will quickly wash out of development entirely (and head to sales) or make the leap to pure developer. Being a know-it-all PM like that just won't scale.

    Eventually, the developers will revolt, and you just can't have that.

  • christophe claude

    I was a developer for 3 years. I left developement because I was TIRED of the hard stuff (security, performance, scalability,..and you forgot, at least, reliability like in 24/7;-). Believe me, I know it is hard…I also know that you have to address those issues precisely AT THE BEGINNING, while you lay down the architecture. What occurs later should be less of a concern to the PM. At some point in time, the PM should shift form “Product” to “Manager”, those people sometime WANT to ignore the details and just pretend “we need this and that”, most creative developpers find a way…

  • http://bexhuff.com bex

    To be clear, I've had PMs of all kinds… those who were former developers and knew how to code well, those who were tinkerers, and those who had no clue about software. I've had good and bad experiences with all 3 kinds.

    I don't think there's a hard and fast rule about this… you can be a lousy PM or an exceptional PM, regardless of your level of coding skill.

    I think the trick is to first realistically determine your level of coding competence, and then select a PM style that suits your talents.

  • http://bexhuff.com bex

    I didn't mean to pick on Rails or Rich :-)

    These kinds of “know it all” PMs indeed do exist… in droves. Ever read TheDailyWTF.com? It doesn't always crop up as micromanagement.

    It's not always a bad thing, tho… I recall one story that James Duncan Davidson told me… he was in a PM meeting at Apple, and everybody was arguing about adding a feature to a page. The PM of that product said it couldn't be done, and the marketing team kept begging for it to be done. James decided that while everybody was arguing, he'd whip it out in AppleScript — yes, AppleScript — and then showed it to everybody. He also gave them useful instructions on how to implement it “for real.”

    The true power that “coder” PMs have is the ability to short-circuit conversations between people with technical knowledge, and people without it. If your organization has problems because the coders refuse to share information with marketing, then coder PMs could be hugely important.

    However… If your problem is marketing making unreasonable demands on developers, then a coder PM could be a big problem. He'll be eager to please, and whip out something to prove marketing's point, and then it's up tot he coders to make yet another unreasonable request magically happen.

    In short… I think it depends a lot on your company culture…

  • http://theappslab.com manalang

    One thing I would probably clarify here is that PMs should know how to tinker and hack but don't need to be schooled software engineers. PMs, above all, should be keenly aware of the user's needs even if the user doesn't know what that need is. I respect PMs who can come up with solid ideas and prototype them — not necessarily engineer the real product. It doesn't matter if the prototype is just a series of sketches or wireframes.

    I've spent the last 10 years of my career between sales consulting and psuedo PM roles, but most of it boils down to cycles where I take existing GA software and make it more useable either by building new features or cleaning up existing ones — even if they're just prototypes. Good PMs should be able to iterate their ideas into prototypes that can convey their ideas in a real user scenario. The best PMs not only can do this well, but can build prototypes that actually convince people that those ideas are worth pursuing.

    I think good software PMs are innovators, hackers, good listeners, problem solvers, and motivators. The emerging pattern I've seen in all good PMs is the ability to carry out all of these things well. Also, I think these kind of PMs have an entrepreneurial spirit that drive them to build cool stuff that people will use.

  • http://bexhuff.com bex

    I still gotta disagree… A person does not need to know a damn thing about code to be a great software Product Manager.

    I've seen a lot of Product Manager in lots of industries, and in lots of different KINDS of software companies. I've noticed that far too many people don't have a clue what a good Product Manager actually does all day long, so they frequently jump to conclusions about what skills or activities would make the person more useful… I was guilty of this myself for a very long time…

    My wife summed it up perfectly: “a Product Manager is the CEO of a product line.” Therefore, the skills required to be a good PM are the same skills required to be a good CEO… just that you operate on a smaller scale.

    So, what are those skills? Well, good listener, problem solver, and motivator are always key… But hacker? Innovator? That's certainly not a requirement to be a good CEO, nor a good product manager. It could help — for some corporations and some products — but it's certainly not a hard and fast rule.

    Now… if you want to be the CEO of a hot new social software company that presents at SXSWi… then yes, I'd probably say hacker and innovator are very helpful, but still not an absolute requirement.

    Do you have to know how to build cars in order to run Ford?

    Do you have to be a rocket scientist to run Virgin Galactic?

    I sure hope not…

  • http://theappslab.com Jake

    I like it as a general rule of thumb, but maybe it's biased toward my work experience. I read DailyWTF off and on, mostly off, and I don't recall much PM-specific hating. Maybe I just ignored it :)

  • http://theappslab.com Jake

    Agreed. I also got tired of writing code and wasn't terribly good at it.

    PM should be around for the whole lifecycle, heavily at the beginning, and I agree w Bex that PM needs eventually to stay on the sidelines and let the developers write code.

  • http://theappslab.com Jake

    *Especially* if the user doesn't know what that need is. PM should shine here based on what is known about the target users.

  • http://theappslab.com Jake

    First off, we're talking about software. I don't know anything about managing product at Ford and Virgin Galactic so it would be presumptuous to include them.

    In software, sure you don't *have* to know how to write code, but as a general rule, it helps.

    So, disagree all you like w corner cases :)

  • http://theappslab.com Jake

    Thanks. This is an interesting thread.

  • http://friendfeed.com/jkuramot Jake Kuramoto

    @DGentry: I guess I’ve been lucky or too dumb to know better :) Or maybe it’s my ability to inspire abject fear. Probably dumb. Good tip on Cranky PM.

    This comment was originally posted on FriendFeed

  • http://theappslab.com manalang

    Agreed. As a software PM, I'd expect a PM knows about software… not just how to use it but keenly knows how it works. Your (or your wife's) analogy of a PM as a CEO is flawed. Yes, PMs have CEO like responsibilities that involve marketing, managing customer relationships, and maybe product line financial responsibilities, but overall, a PM's main responsibility is to manage a product's lifecycle. I don't expect Larry to know the inner workings of WebCenter or Steve Jobs to know how the iPad works in detail (although, I bet he does). But for the PMs of those products, I'd expect them to know all of that and be able to dive deep into the details. They are the face of that product. And I bet a CEO like Larry or Steve would expect the same from their PMs.

  • http://bexhuff.com bex

    Little known fact: Steve Jobs can't code… So, it's not exactly a “corner case.”

    The only techie job he ever held was at Atari, and he got Wozniac to do it for him. He collected $6000 from Atari, and paid Woz a mere $300.

  • http://theappslab.com Jake

    Is that for me or Rich? I didn't cite Steve Jobs as a corner case. Ford and Virgin Galactic aren't relevant in a discussion about software PM. CEO of a hot software company is a corner case, since most of those small companies are small, surprise. Therefore, everyone does everything.

    My opinion is pretty simple. Software PM should know how to code. Not a requirement, but it helps.

    You disagree, but what we do agree on is that PM needs to know product intimately. I don't how this happens w/o knowing a little code, but it's possible.

  • http://bexhuff.com bex

    Ah… I misunderstood what you meant by “corner case.”

    I guess my point is that it takes a lot of talents in order to make a PM successful, and it's rare to find ALL of those talents in one person. So I'm hesitant to say that a PM *must* have skill X, especially when I've seen a lot of rock star PMs *without* skill X.

    For small companies — or a small-company division of a large company — you have to “wear a lot of hats.” So, it's likely to find a PM who is in charge of a lot of things… so the innovative tinkerers might wind up as PMs. But that doesn't mean its a scalable idea that people should emulate.

    Have you heard of “Pragmatic Product Marketing”? They teach PM skills across industries. One of their main lessons is that a “Product Manager” is required to have so many different skills — which are nearly impossible to find in one person — as companies get larger they split this one roll into three (or more) roles. In their model, only one of the 3 roles would always be made more effective if the person was “technical.” The other 2 roles? It might work, or it might backfire.

  • joel garry

    Don't quite get what the pink panties have to do with monkeys on the internet.

    I have seen PM's cause lots of suffering because they have outdated ideas about software (and wrong ideas about administration). One I saw tossed millions of good $ after bad. I've seen several make a poor transition from large to small companies. I'm with Bex.

    I burned out on coding in the mid-'80s. I'm still coding, cause I could never feature being a middle manager, and straight administration is for larger companies Such is life.

  • http://theappslab.com Jake

    Yes, PM takes a wide range of skills, and I didn't say writing code was a must-have. IMO it's a should-have, not a nice-to-have, for software PM b/c passion about product leads to tinkering, which (usually) leads to empathic and better design.

    Never heard of Pragmatic Product Marketing. I get the point they're trying to make, and at a large software company, you'll have segmentation of roles in that manner. It's necessary for scale. My thought is that coding should be emphasized as a should-have skill.

    This is a fun topic though. I'm expecting a counterpost :)

  • http://theappslab.com Jake

    Shirky's talk had a very wide swath of analogies :) I'll post the video if they publish it. Well worth the viewing.

    There are plenty of reasons to agree w Bex, most of them seem to be negative experiences/use cases. I'm saying code makes for better design in most cases, not every last one as the only rule to apply.

  • http://bexhuff.com bex

    “a PM's main responsibility is to manage a product's lifecycle”

    I'm assuming you mean by this that they need to understand EVERYTHING about a product… initial vision, design, development, testing, usability tests, beta tests, product direction, market direction, sales, sales support, sales model, customers, customer support, competition, market analysts, media, deployment, install, testing, modification, customization, new feature requests, patches, new feature prioritization, new product vision, repeat!

    That's pretty darn close to the CEO of a product line… the only thing that's missing is having to worry about payroll.

  • http://twitter.com/rmanalan/statuses/10686434382 rmanalan (Rich Manalang)

    Twitter Comment


    A debate about what skills a software prod mgr should possess is going on at [link to post]. What do you think?

    – Posted using Chat Catcher

  • http://friendfeed.com/e/4750f6bf-3997-4365-8e9f-3f1d0e17681c maheshcr (Mahesh CR)

    FriendFeed Comment


    Product Managers Should Know How to Write Code – [link to post] (via http://ff.im/hH130) http://friendfeed.com/e/4750f6bf-3997-4365-8e9f-3f1d0e17681c

    – Posted using Chat Catcher

Newer Comments →