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

← Older Comments
  • http://twitter.com/jkuramot/statuses/10693093993 jkuramot (Jake Kuramoto)

    Twitter Comment


    RT @rmanalan: 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://theappslab.com manalang

    Too bad they don't call them CEOs or CPMs. Yes, a good PM understands the lifecycle, but understanding is different from having deep knowledge about how their product works. In a software company like Oracle, most product lines have product marketing people, sales consultants/engineers, customer support, competitive analysts, etc., etc. The burden of running a product inside a company like Oracle typically lies in the VP or SVP of that product line… who all of the PMs report to. So, guess how this evaluates (PM == CEO)? “bex is wrong” : “bex is right”? Anyway, let's agree to disagree. The one core thing we do agree with is that good PMs understand their product, their market, and their customers. PMs with the ability and desire (and passion) to hack on their own product(s) in order to make it better typically gain my respect because they not only understand the core PM role, but have that itch to make it better and can convey their ideas to those who don't have that same vision.

  • http://theappslab.com manalang

    BTW, the technical skills we're referring to isn't the ability to understand deep CS principles, but the ability and desire to take apart a product, see what's under the hood, tweak stuff and share them with others in order to start conversation and promote innovation. Each trade has some idea of craftsmanship… people who take pride in what they do. Software developers who treat their role as a craftsman tend to write great software. All I'm suggesting is that software PMs who approach their role as a craftsman typically have better products than those who don't.

  • http://twitter.com/techgeist/statuses/10702746056 techgeist (Techgeist)

    Twitter Comment


    Product Managers Should Know How to Write Code [link to post]

    – Posted using Chat Catcher

  • Pingback: PM Should Know How to Code, Part 2 | Oracle

  • http://www.matttopper.com topperge

    Agreed, I owe that guy a beer (again) at OOW.

  • http://bobfraser1.pip.verisignlabs.com/ Bob Fraser

    PMs absolutely should know how to write code. Especially for products that are meant to be extended.

  • http://theappslab.com Jake

    Good point, tough to design extensions if you don't code.

  • Myrandompixels

    Great Discussion!

    There are some compelling personal reasons why I should be on the side of “PM should have code skills” and I'd really like to come back to this question in a year- however I don't think there is ANY real benefit in a PM being able to code.

    Any such benefit is easily nullified by a PM simply being good at what their job requires and TRUSTING dev to do the same. PMs should work WITH Dev to determine priorities and scope- each and every feature.

    The main arguments have been communication, prototype building and Planning/scope.

    Communication with a developer can, by luck on occasion be improved with coding knowledge. The only case I've seen this is with a PM who could read SQL so that they could personally ensure that the correct logic really was implemented. This I believe is the only substantial argument and is a nice-to have at best.

    There is no reason for a PM to code prototypes. Prototypes are a very expensive way to plan/design/communicate. They should be used in special cases, like for a study or presentation/pitch with someone who cannot or will not visualize the application with other tools. The PM should focus on functionality, not Javascript. Who cares about how to code CRUD behavior into Dream Weaver when what is at stake is whether or not the PM can come up with an really lovely way for an HR Person to indicate the routing rules for promotions approval at their company?

    Nor does prior coding experience help a PM determine how hard something is to write. In fact, it barely helps DEV. Ongoing continuous experience with the current manifestations of the technology and the environment in which they code is what HELPS developers determine if its easy or hard. And more often than they'd like- that doesn't even help.

    So no, a PM doesn't need to know how to code. They just need to be trustworthy/respectable in their skills and trust/respect dev in theirs. OH yeah and communication kind of helps. ;-)

  • Myrandompixels

    Extensions, compartmentalization, resuability, modularity, integration…. these are not concepts exclusive to code. It helps to have a certain kind of mind for these things and sometimes people who have done some coding are of that ilk, but I cannot think of a single concept in an application that requires coding experience to design or that cannot be easily sussed out via the natural and I consider required ongoing communication with development. Unless of course, I've misunderstood your use of the term 'extended'.

  • http://theappslab.com Jake

    There's no way I could have designed features like the posting algorithm for FSAH without a background in development. Understanding how the logic would be built allowed me to understand the challenges and complexities of the development process.

    Similarly, changes I designed for reports were easy to describe and document b/c I could go into Reports and, well, make the changes.

    I guess it's a matter of what you're designing. The bigger the organization, the more involved, i.e. PM, UX, performance, standards, templates, etc. The more involved, the more specialized each role is.

    Specialization is great, but the more you know about what's involved, the stronger you'll be.

  • Myrandompixels

    Everyone must have the skills you describe in order to be innovative. I completely agree with your thoughts on craftsmanship and yet don't see how your post is related to a PM knowing how to write code.

    Does an architect need to know the inner workings of a circular saw in order to design and oversee the construction of a great building?

  • Myrandompixels

    Posting Algorithm for FSAH sounds a little like a technical feature to me. But I don't know. I've mistakenly done some design work myself that borrowed from coding practices and laid out some interfaces that were strongly biased towards the ER Diagram. I'd have to say that I think its more of a risk than a bennie. A complex application feature functionally designed by a programmer is probably going to look a lot like a program interface. This might be a good thing or it might require that the customers hire programmers to use it.

  • http://theappslab.com Jake

    Extending the building metaphor, I suspect many architects do tinker with saws and build stuff in their spare time b/c they are passionate about building things.

    Maybe this boils down to passion, and writing code (i.e. building product) is the expression of that passion for some of us.

  • http://theappslab.com Jake

    Maybe not the best example, but I did review lots of designs for more functional features when I was an architect. Like I said, when the product is very functional and requires non-technical domain expertise, it's helpful to have both a technical and functional PM collaborate; this is how it's done in pre- and post-sales.

    UI design may or may not fall under PM, and even if it does, interface design is an entirely different topic that shouldn't get mixed into this one.

  • Chris

    This creates an interesting example. If you extended, the question would be “should” an architect know engineering (materials, stresses, loads, construction capability, etc.)? The answer is probably “probably” since that would mean they might be able to architect something that was within the capabilities of the engineers and construction crews to build. Of course, they would be limiting themselves to their perception of others' capabilities and not simply providing the vision as a challenge to the builders.

  • Chris

    Why isn't user experience a significant aspect of the product that the PM has to manage?

    And what do you think the PM for something like Twitter needed to know? :)

  • http://theappslab.com Jake

    I'm not really sure why everyone wants to extend this to other disciplines :) Software is software and has its own set of requirements, capabilities, responsibilities, etc. I just don't know enough about other disciplines to tell if they are analogous or not.

    Anyway, I have to assume that architects are constrained somewhat by materials and other physical realities (like gravity), making it value for them to understand engineering principles. I believe these are requirements for a degree in architecture. Otherwise, designs would be art :)

  • http://theappslab.com Jake

    UX is a PM concept, but within large organizations, UX is controlled by designers to ensure consistency, feasibility, etc. The bigger the shop, the more granular the roles become.

    As for Twitter, I'd assume they need to know it all, probably splitting twitter.com and API design.

  • http://www.blogger.com/profile/07421049499752624699 Edward Vielmetti

    Would there be any reason not to hire for both?

    The only perspective that I can see easily that would make the argument for hiring people who don’t have any experience in the field they are going into is that they would be there to bring a new perspective to an organization that had become stuck in its ways or had otherwise failed to adapt to the times. The argument would be that you should be readily able to pick up whatever elements of the culture are essential by being immersed in it, but the specific set of previous experience that brought you to the job doesn’t have to come from the identical industry.

    This comment was originally posted on Inside Out (mcwflint)

  • http://www.blogger.com/profile/00183010504600574644 MaryAnn Chick Whiteside

    You’re right – the best candidate has both. I see the value of bringing in someone from a different industry. What I don’t see is much attention paid to understanding there is a culture and that only by understanding an organization’s culture can you effectively remodel it.

    This comment was originally posted on Inside Out (mcwflint)

  • Anshu

    Here is what I think – there is (believe it or not) at least two class of products. Products where domain knowledge is key (think Revenue Collection System or Supply Chain Automation or Tax Calculation) – for this class of products, what the team needs from a PM is clear specs. Its not obvious to a software developer that the Dutch system for calculating taxes is different since it excludes tips (a completely made up story).

    Then there are – every software developer knows this – class of products. These products are also common in the open source community – think IDEs, Web Browsers, OS, Database Systems, Archiving Systems, Cisco Routers etc. etc. For these products, developers don't always need domain knowledge – they need insightful interaction with customers and the person responsible for this (typically a PM) must have strong technical foundation.

    A lot of products fall in the middle – think Document Editing – an engineer intuitively knows what a text editor is. Here the value add is UE design. Engineers may bias towards keyboard shortcuts (vi lovers?) while the average user would like to have buttons that do things.

    Therefore, the ideal PM for a job – and whether coding is a required skill – depends entirely on the product you are looking to build.

    In general, smart people can pick up domain knowledge where as domain experts can't become smart in 6 months. ;)

  • http://theappslab.com Jake

    This makes sense, but in each case, knowing how to code makes the result better, especially in the first case.

    Understanding the requirements for Revenue Collection System or Supply Chain Automation or Tax Calculation is a must-have, but you'll come out with a better product if you understand some principles of design and a little architecture.

    The more a product relies on domain expertise, the more it needs a guiding technical PM, either from the same person or from an architect.

    I think domain experts would be able to pick up the concepts required, but they are never encouraged to do so.

  • http://theappslab.com Jake

    This makes sense, but in each case, knowing how to code makes the result better, especially in the first case.

    Understanding the requirements for Revenue Collection System or Supply Chain Automation or Tax Calculation is a must-have, but you'll come out with a better product if you understand some principles of design and a little architecture.

    The more a product relies on domain expertise, the more it needs a guiding technical PM, either from the same person or from an architect.

    I think domain experts would be able to pick up the concepts required, but they are never encouraged to do so.

← Older Comments