I started programming when I was in high school. I learned about computers my junior year and decided to take a programming class. Programming came naturally to me—I’m one of the lucky ones. In college, I majored in computer science at UC Irvine and started my career as a software developer.
Since then, I’ve worked as a consultant, project manager, and eventually a product manager. My background as a “classically trained” developer has been extremely helpful to me as a product manager. Although I don’t do much programming anymore (at least professionally), I’m able to use my experience to understand how a product should be developed and whether or not best practices are being followed.
So—if you’re a product manager and do not have experience developing software, should you learn how to code?
I argue that your time would best be spent learning software architecture and design concepts first (higher level), instead of learning how to code (lower level). This would give you the tools to have deeper conversations with your development staff and also help you short-circuit iterations where requirements meet specifications.
Here’s a story to illustrate: I was on a project where we wanted to enhance our file importer product by allowing it to automatically rotate images if needed. Although this was the only requirement at the time, I could foresee that we would eventually want to support different “pre-processing” operations like parsing a metadata file for information, or rearranging the order in which the files were imported.
By understanding the concept of decoupling, I was able to help design a feature by which we created an API that we used internally (to do the automatic image rotation) but also allowed developers to create their own pre-processing operations. This made the product much more flexible and maintainable (fewer code paths to follow) and our customers, partners and professional services staff loved it!
I would also recommend the following books (try to stay high-level and focus on architecture/design concepts):
Learn some of these concepts and see how they improve the conversations you have with your development staff and how they will help you craft lower-level requirements.