It seems to be a pretty common question in the PM world these days — just how technical does a Product Manager really have to be?  And what baseline amount of technical knowledge and/or skill does at PM really need to have in order to be successful.  Many development teams will tell you that they want a PM who can code — but I’m not sure that’s really a function of their needs, or whether it’s a reflection of them wanting someone who knows their domain and is on “their side.”  And many technical businesses short-change the business and strategic knowledge that a good PM can bring to the table, relegating them to “spec-writers” whose interactions are primarily internal.

Having said that, while I don’t believe in any way, shape, or form that all Product Managers must be “technical” — I do believe that all technology Product Managers should have at least a conversational understanding of some key technical topics.

Why You Should Know Some Tech

Aside from the obvious, that you’re working on a technology product, there are some really good reasons to have at least a basic understanding of some technical topics — as I described it to my Product Management class, a “Wikipedia” level knowledge.  Having this baseline level of technical knowledge helps you significantly in your day-to-day work as a Product Manager:

• It lets you be better at your gut checks regarding what’s feasible and what’s not;
• It allows you to be more involved in the Sprint planning, sizing, and task breakdown discussions;
• I provides you with another internal “language” that you can speak and translate; and
• It gives you some common ground with which to build a trusted, respectful relationship with your engineering teams.

In addition, we live in a connected world — and knowing how those connections are created, what they mean, and how they work just helps us to be more rounded and informed individuals in general, not just as Product Managers.

What Tech Should You Know?

This is always the tricky question, and there’s no “silver bullet” list of technologies that all Product Managers should know and understand — and even if there were, it would be outdated almost as soon as it was published, since there’s some “new hotness” that pops up almost every day.  But, from a fundamental perspective, I think that all Product Managers should at least understand the following technologies at a “Wikipedia” level of knowledge — meaning that you’ve read and understand the Wikipedia page for each of them, and maybe dig a little more on topics that are of interest to you or that are important to your product.

• Databases
  The Internet operates almost entirely on some form of database — Facebook, Twitter, Yelp, even Netflix couldn’t possibly operate without some form of database running on their backend.  For some of these products, the database is the actual product, for all intents and purposes; for others, the database just provides a foundation for searches and connections in addition to the actual product itself.  A good Product Manager should know what a database is, what it’s used for, and the basic differences between relational and non-relational databases.  Knowing what NoSQL is compared to MS SQL and some basic use cases for each is a good thing for any PM in this day and age to understand.  Being able to actually write a SQL query (on an appropriate database) is a bonus that can come in exceptionally handy in a pinch.
• HTML and CSS
  If databases are the backbone of technology products, the “face” of these products is often created through (or derived from) HTML and CSS, which are the most common form that web pages take on the Internet.  Knowing how to create a basic page with HTML tags, and then styling that page through the application of basic CSS styles is something that most Product Managers should be able to do.  HTML and CSS can come in very handy in creating interactive mockups or wireframes of your product, or for testing out ideas for layout and interaction.
• Common Programming Languages
  While every PM does not need to know how to write code, you should at least be passingly and conversationally familiar with the three most common programming languages that are in use today — Objective C for iOS and Mac development, C# (“C-Sharp”) for Windows-based development, and Java for cross-platform or Android development.  While I would love it if every PM was capable of writing a “Hello World” program in each of these languages (something I actually can’t do yet for Objective C), just knowing which language your development teams use can help you buy a little bit of “street cred” by referring to it properly.
• Common Scripting Languages
  Developers know the difference between scripting languages and coding languages — something many PMs don’t.  Scripting languages basically provide a pre-set list of functions that provide a known output for a known input — they’re basically just collections of pre-defined functions.  While there’s a lot that can be done within these parameters, they do a lot of the heavy-lifting within their own code, without need of knowing what’s going on behind the scenes.  Common scripting languages that you’ll encounter include PHP (Pre-Hypertext Processor), Ruby (on Rails), Perl, Python, and PowerShell.  Knowing what these are and which languages are used by your team will help you not put your foot in your mouth when talking with your teams.
• Version Control Systems
  Nearly every development team uses some form of version control for their code — and those that don’t are running some pretty major risks with that choice.  Understanding why version control systems are used (so that you can revert to prior versions if you break something, usually) and which one your teams are using provides you with good insight into some common and expected technical practices.  Whether your team uses Git, Subversion, TFS, or something else, knowing that things like repositories, branches, check-ins, and builds exist and having a fundamental understanding of how they work will help you to “get” some of the pains your team may encounter while building product.

Overall, Be Curious!!

This is not by any means an exhaustive list — there are new technologies that come up every day, and every single company that I’ve worked at or with has had an entirely different set of technologies that they’ve used to achieve their success.  Ultimately, a Product Manager should be conversant about the technology that their company uses, just as they should be conversant about the market positioning that’s used, or the scripts that are used by the Support team, or the financial considerations that go into pricing decisions.  It’s just one of the many hats that we wear as Product Managers, and we can use our interactions with technical teams as an opportunity to express some sincere curiosity and to grow not only as employees but also as people too.