Should a Product Manager do coding?

The infamous myth busted

just for fun .. PC: Social Stories by Product Coalition

Ok .. coming back to the topic. Should a Product Manager do coding?

Let’s not beat around the bush. Let’s get straight to the point.

Yes, Product managers should do coding if the need is. Product managers who work on technical products define high-level requirements on what they want, but as a PM digs more into the technicalities of the product, the requirements do evolve or change sometimes. PMs usually rely on developers to tell them more details about the evolving requirements.

Developers do a SPIKE on uncertain requirements, and help PM solidify the requirements.

Spike: The developers do a spike on the uncertain requirements, more like a research effort, and help the PM with solidifying the uncertain requirements.

Can PMs do the Spike? Yes, Technical PMs can do the spike themselves and figure out more solid requirements without developers’ help. The counter-argument immediately will be —

“the PMs won't have enough time to figure out customers’ requirements if they do hands-on coding”

My argument is — Well, customer research doesn't take 2 or 3 months time. We learn more about the customers as we implement and launch something. So spending all the time on theoretical customer research is a waste of time for a PM.

After a hypothesis is formed and requirements are outlined, a PM can be hands-on to help do a spike or build a POC.

Limitations of this approach: During a 2-week sprint a PM is buried with figuring out requirements every sprint. A 2-week sprint is a short time for a PM to do any POC or spike. During an 8-week cycle (called the Shape-up process) that we follow at Plotly, it’s easier for a PM to be hands-on and figure out more specific and deeper requirements.

Pros of Shapeup & Hands-on PM: A PM should know the depths of the product, at least from an architecture level. If a product is technical, it is mandatory that a PM knows the architecture of the product, the tech components it's built of, and its respective tech limitations. So being hands-on with the architecture of the product makes more sense, and it gives confidence to the PM while talking to the customers (who will be technical). Also, it's actually more fun to dig into the depths of the product. Sometimes doing dark room coding is a meditative process :)

Cons of a hands-on PM? Well, you know it — the time constraints to get the right requirements!

…. and finally …

Should a PM code? or NO? What do you think?