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.

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.

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.

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

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

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

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.

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

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?

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.

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.

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

– Posted using Chat Catcher