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