It is a fairly common question many of us ask ourselves when we are trying to break into product management: how technical does a product manager need to be?
When I was first getting into product, many people told me my background as a political science major would be a major liability. 5 years later as I begin to hire PMs for my own product organization, I can say definitively that you do NOT have to know how to code in any way, shape, or form to be a great product manager. You only need to be intellectually curious enough to conceptualize how technologies work and relate to each other.
I examine this in a longer post, but I have condensed a summary here looking at the three components of building an innovation conversion engine that efficiently moves from generating ideas to execution.
Product Discovery
Product discovery is the beginning of the funnel for an innovation conversion engine. It is the role of the product organization to not simply leave ideas up to chance, but to systematically capture ideas and decide which should move forward in the funnel. This could move along many different tracks, from discovering new feature ideas that will optimize a current product to discovering an opportunity for an entirely new product.
I think it is important to distinguish between two types of discovery: technological innovation and application innovation. Technological innovation is an idea that expands the boundaries of what is currently thought possible (i.e. self-driving cars), and it is the type where technical experience seems most advantageous. However, the role of product, even in such a frontier, is still that of an intermediary between the customers and the technology. That means it is their job to understand the opportunity (the what) that breakthrough represents and use that to guide further R&D, and then to collaborate with their tech leads on how.
And this is also true of the more common types of innovation, which involve new application and creative coordination of existing technology. Again, product is the intermediary between what is possible and what is needed. Spending a year as an iOS developer 5 years ago doesn’t make me any more qualified to look at the logistics domain and discuss with my CTO if blockchain is an applicable technology for our product goals.
Really, product discovery is about gap analysis, something that is extremely prevalent in both liberal arts research and technical research. For those of you aspiring to be the first PM at an early-stage startup, or management level PM (director, VP, CPO), demonstrating the capacity to learn new domains quickly and research them for gaps is going to be much more important than whether you are technical or not. Most PM roles will be more focused on ideation and execution within the scope of the product discovery done by senior leadership, which we address next.
Execution and Product/Market Fit
After the innovation conversion engine has generated an idea, the rest of the funnel could be described as an ever-tightening loop between execution and market feedback.
Day to day execution does involve a number of activities where technical communication is important. Yet, almost all these activities are collaboratively done: specs with engineers, mockups with designers, deadlines with business execs, etc. Coordinating all this specialized expertise to create a plan, and to make calculated trade-offs, is a process where soft skills are more important.
Fitting the product to the market is about research design. Once again, research design has little to no correlation to experience as a technical individual contributor. In fact, qualitative research of this kind, research on people, is primarily a skillset you’d find in the social sciences. This tells me that companies should be looking for PMs with research design capacity mixed with the communication skills necessary for coordination and specification in execution.
Leadership and Communication
One thing that makes product so difficult is that many departments, teams, and stakeholders are accountable to the product org who pulls it all together as a coherent, executable whole. But, none of them report to you, which means you have to lead with influence rather than authority.
To do this well, PMs must be able to understand specific execution questions within the broader context of the following flow:
Business Strategy –> Product Vision –> Product Roadmap
This is a conceptual skill, to hold a mental model of different layers ranging from the very abstract to the specific existing within each other in concentric circles. To collaboratively work through trade-offs in the execution process, with stakeholders who often have incentives that are directly at odds, takes a deft touch born of a nuanced understanding of the bigger picture. Technical experience does nothing to explicitly prepare you for this.
Conclusion
To be successful, product orgs need to exhibit strong capacity for a variety of conceptual thinking skills, from gap analysis, to technical communication, to research design, to the leadership necessary to hold multiple stakeholders accountable. If you want someone with the capacity to grow into a good approximation of the “whole package”, I think it’s just as likely a non-technical person can learn to fill in their gaps as a nominally technical person.