Product Managers Should Know How to Write Code
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
- PM Should Know How to Code, Part 2
- If Maslow Built Software
- Maker’s vs. Manager’s Schedule
- The Art of Estimation
- On Hiring a Web Developer
March 17th, 2010 at 2:02 pm
YES! (I wish I could make that 72pt Arial Bold or something)
That's all I have right now.
March 17th, 2010 at 2:15 pm
Totally… totally… totally agree. So, when are you going to learn ADF?
March 17th, 2010 at 1:55 pm
Product Managers Should Know How to Write Code http://goo.gl/fb/m6MH
This comment was originally posted on Twitter
March 17th, 2010 at 1:55 pm
Product Managers Should Know How to Write Code http://goo.gl/fb/hDrY
This comment was originally posted on Twitter
March 17th, 2010 at 2:07 pm
Product Managers Should Know How to Write Code http://j.mp/ctZ6ar
This comment was originally posted on Twitter
March 17th, 2010 at 2:20 pm
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
March 17th, 2010 at 6:19 pm
He just said you need to know how to program, nothing about programming in a worthwhile language. Like he said, he knows PLSQL.
March 17th, 2010 at 6:33 pm
@Rich: I'll learn ADF as soon as you do
@Topper: Raimonds' Ruby adapters are making my PL/SQL skills relevant again
March 17th, 2010 at 6:34 pm
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.
March 17th, 2010 at 5:17 pm
If only so the PM can tell when their developers are lying to them…
This comment was originally posted on FriendFeed
March 17th, 2010 at 6:21 pm
Product Managers Should Know How to Write Code http://j.mp/cWxEop
This comment was originally posted on Twitter
March 17th, 2010 at 6:21 pm
Product Managers Should Know How to Write Code http://j.mp/cWxEop
This comment was originally posted on Twitter
March 17th, 2010 at 7:04 pm
@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
March 17th, 2010 at 7:04 pm
@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
March 17th, 2010 at 7:33 pm
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
March 17th, 2010 at 8:04 pm
Product Managers Should Know How to Write Code http://j.mp/ait08B
This comment was originally posted on Twitter
March 17th, 2010 at 10:39 pm
hear hear
This comment was originally posted on FriendFeed
March 17th, 2010 at 11:15 pm
Product Managers Should Know How to Write Code http://is.gd/aMrXh
This comment was originally posted on Twitter
March 17th, 2010 at 11:49 pm
RT @myfear: Product Managers Should Know How to Write Code http://is.gd/aMrXh
This comment was originally posted on Twitter
March 18th, 2010 at 2:49 am
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;-)
March 18th, 2010 at 7:20 am
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.
March 18th, 2010 at 7:37 am
I'll have to agree with Bex in this instance. He articulated a point that I was unable to.
March 18th, 2010 at 8:16 am
It really makes a positive difference in designs and in communicating with developers.
March 18th, 2010 at 8:21 am
Totally agree, gives u better understanding of the product.
March 18th, 2010 at 8:22 am
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.
March 18th, 2010 at 9:05 am
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…
March 18th, 2010 at 9:46 am
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.
March 18th, 2010 at 9:54 am
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…
March 18th, 2010 at 7:25 am
RT @theappslab should product managers be required to know how to code? Jake says yes, Bex says no… http://bit.ly/96Cspt
This comment was originally posted on Twitter
March 18th, 2010 at 10:40 am
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.
March 18th, 2010 at 11:03 am
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…
March 18th, 2010 at 11:19 am
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
March 18th, 2010 at 11:24 am
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.
March 18th, 2010 at 8:24 am
The SW PM role business + technical coding skills. thoughts? RT @theappslab PMs Should Know How to Write Code http://bit.ly/96Cspt
This comment was originally posted on Twitter
March 18th, 2010 at 11:26 am
*Especially* if the user doesn't know what that need is. PM should shine here based on what is known about the target users.
March 18th, 2010 at 11:28 am
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
March 18th, 2010 at 11:29 am
Thanks. This is an interesting thread.
March 18th, 2010 at 8:40 am
@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
March 18th, 2010 at 11:43 am
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.
March 18th, 2010 at 12:34 pm
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.
March 18th, 2010 at 1:55 pm
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.
March 18th, 2010 at 2:32 pm
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.
March 18th, 2010 at 2:32 pm
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.
March 18th, 2010 at 2:40 pm
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
March 18th, 2010 at 2:42 pm
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.
March 18th, 2010 at 2:45 pm
“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.
March 18th, 2010 at 11:47 am
A debate about what skills a software prod mgr should possess is going on at http://bit.ly/b77tCh. What do you think?
This comment was originally posted on Twitter
March 18th, 2010 at 11:49 am
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
March 18th, 2010 at 12:17 pm
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
March 18th, 2010 at 2:43 pm
RT @rmanalan: A debate about what skills a software prod mgr should possess is going on at http://bit.ly/b77tCh. What do you think?
This comment was originally posted on Twitter
March 18th, 2010 at 3:35 pm
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
March 18th, 2010 at 7:40 pm
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.
March 18th, 2010 at 7:47 pm
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.
March 18th, 2010 at 6:39 pm
Product Managers Should Know How to Write Code http://j.mp/acyRBJ
This comment was originally posted on Twitter
March 18th, 2010 at 6:39 pm
Product Managers Should Know How to Write Code http://j.mp/acyRBJ
This comment was originally posted on Twitter
March 18th, 2010 at 6:40 pm
Twitter Comment
Product Managers Should Know How to Write Code [link to post]
– Posted using Chat Catcher
March 18th, 2010 at 10:32 pm
[...] if you’re monitoring the comments almost my factor yesterday, Product Managers Should chute expressed Code, you’ll know Bex [...]
March 19th, 2010 at 6:23 am
Agreed, I owe that guy a beer (again) at OOW.
March 19th, 2010 at 8:27 am
PMs absolutely should know how to write code. Especially for products that are meant to be extended.
March 19th, 2010 at 9:12 am
Good point, tough to design extensions if you don't code.
March 19th, 2010 at 12:11 pm
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.
March 19th, 2010 at 12:18 pm
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'.
March 19th, 2010 at 2:13 pm
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.
March 19th, 2010 at 7:52 pm
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?
March 19th, 2010 at 8:03 pm
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.
March 20th, 2010 at 9:40 am
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.
March 20th, 2010 at 9:47 am
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.
March 21st, 2010 at 10:45 pm
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.
March 21st, 2010 at 10:50 pm
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?
March 22nd, 2010 at 8:15 am
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
March 22nd, 2010 at 8:20 am
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.
March 24th, 2010 at 3:00 am
Product Managers Should Know How to Write Code: http://theappslab.com/2010/03/17/product-managers-should-know-how-to-write-code/
This comment was originally posted on Twitter
March 24th, 2010 at 6:11 pm
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)
March 25th, 2010 at 7:53 am
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)
March 30th, 2010 at 6:33 pm
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.
March 31st, 2010 at 6:42 am
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.
March 31st, 2010 at 2:42 pm
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.