53

Product Managers Should Know How to Write Code

Posted by JakePosted ago

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.

AboutJake

a.k.a.:jkuramot

53 comments

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

  4. @Rich: I'll learn ADF as soon as you do 🙂

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

  5. 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.

  6. 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;-)

  7. 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.

  11. 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.

  12. 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…

  13. 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.

  14. 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…

  15. 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.

  16. 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…

  17. 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 🙂

  18. 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.

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

  20. 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 🙂

  22. 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.

  23. 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.

  24. 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.

  25. 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.

  26. 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.

  27. 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 🙂

  28. 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.

  29. “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.

  33. 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.

  34. 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.

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

  40. 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. 😉

  41. 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'.

  42. 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.

  43. 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?

  44. 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.

  45. 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.

  46. 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.

  47. 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.

  48. 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? 🙂

  49. 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 🙂

  50. 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.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.