In Defense of a Multidisciplinary Product Manager
There is nothing more mythic than a great Product Manager. Forget eyes of an eagle and strength of a lion — a Product Manager must have the communications skill of a PR Guru, the design background of a UI expert, the first-hand experience of a user-researcher, the organizational skills of a full time planner, and all this outshone by the coding abilities of your best programmer. In the Acropolis of Silicon Valley, the myth persists of the unicorn PM whose sparkling gaze will surely bless your product for success. The exact attributes of this unicorn varies from company to company but often the unicorn’s sparkle is derived from no less than his or her technical expertise. What’s lost in the hunt for the unicorn whose resume abounds superhuman accomplishments is real candidates with real capacity for product.
Let me start by saying, I’m biased. I’ve always lived in this hybrid space. Throughout college, I was a rare English major not only working at a tech support desk but managing an entire technical team. I loved classes from psychology to computer science to design to creative writing and did my best to provide myself with a Renaissance education borrowing across disciplines which piqued my interest. I’ve never been able to define myself with the consistency of disciplinary boundary but hey, I’ve found it works pretty well for me.
Unfortunately, my comfort and proclivity towards a multidisciplinary approach has been met with discomfort from others whose philosophy can be summarized as follows: you’re either technical or you’re not in their perceived black and white divide. And by not defining myself solely as a technical contributor, they failed to perceive possible shades of grey. This typecasting is further complicated by assumptions of gender norms and biases that influence everything from interviewing to daily work. In my own career, I have been rejected from jobs without a staunch technical requirement for not being technical enough without a single technical question being asked. Even once at Google, a company that often champions equality, when discussing a project I was leading with an engineer and getting into the details of the API implementation, my probing was met with a conversation-ending “Oh that’s technical sweetie.”
Living in this hybrid space isn’t easy. But I’m still convinced it’s good — for me as a person and as product manager.
I recently heard Charlene Li speak about understanding technological trends. One of the things that resonated with me in her speech was that most hugely successful companies weren’t new technologies but rather new applications of existing technologies. As she put it, it’s easier to design a product for a need than to make a need for a product. Snapchat didn’t invent messaging, it just tapped into a human desire to live in the moment. Uber didn’t invent taxis nor was it the only company to be experimenting with hailing rides from smartphones — it did however have a laser focus on decreasing human frustration. Tinder wasn’t revolutionary in terms of technology. Instead, it was was revolutionary in that it understood exactly how painful online dating had become for most individuals. What do these stories share in common? The focus on human need and behavior came before the focus on technology.
We look at failed products as failed technologies when what really failed is the human aspect. Failure to bridge the adoption chasm is often an inability to connect product and people. This isn’t something that can be resolved as an afterthought — the world is full of flops who despite providing a technologically interesting product failed to realize a compelling end-user experience. In these cases, the focus is on softer failures often lumped together as product-market fit -i.e., when a great product just didn’t work out. The lean startup movement attempts to capture these so-called softer failures early in the iteration process through a series of trial and error starts that lead in a better direction. What’s understated from these processes and analyses is that what leads a product isn’t technology; it’s people.
I’ve been fortunate to work with great technologists and great product people. Occasionally, these are the same people but not exclusively so. A great product person needs first to understand human needs, and then only when these needs are determined, consider how technical implementations may meet them. This is not to say that you should hire people unfamiliar with technology; product people need to have some understanding of technology to grasp the trends and understand how to apply technical solutions. However, if what matters to great products is great user experiences, wouldn’t it make more sense to first look for a background in psychology, design, communications or other areas stressing creative critical thinking? Why does the technical come first and at what cost?
Perhaps part of this technical bias is that it’s easier to ascertain. We know the questions to ask to see if you can code or you think like an engineer. Where we fall short, however, are universal ways to screen for thought. Most product interviews I’ve seen dive in quick and deep — ‘what feature would you add to this page?’ — while ignoring the essential background analysis of product purpose and end user needs. All that other-ness is just too hard to capture in a 30 minute conversation. Instead of relying on imperfect guesses of thought processes, companies lean hard on the metrics they can answer succinctly: are they technical? In the long run though, this is clinging to an imperfect metric as if it gives them certainty.
This undue focus on technical skills does a disservice to both individuals and companies. By holding them to unnecessarily high technical standards, we are preventing diverse well-balanced candidates from getting jobs. Only 14% of computer science majors are females and many minorities are notoriously underrepresented. The numbers for women (and minorities) in leadership positions is similarly poor. When looking at a position that requires leadership and technical ability the deck is quickly stacked against minority groups. It’s often been said diverse people build diverse products and leaning too hard on technical requirements limits the applicant pool from the get-go. Instead of looking to requirements, look to experiences and understand how their different backgrounds might make them a fit for the role.
The best class I took at Stanford to prepare me for my real world job was not related to computer science or design but focused on graphic novels and was taught by Pulitzer-prize winning Adam Johnson and the ever-inspiring Tom Keeley. In a 10 week class filled with late nights and coffee, a dozen students managed to produce a full length graphic novel. There I learned more about prototyping, execution, leadership, and project management than in any other class, and even put my technical skills to work in the real world by building a website trafficked by tens-of-thousands for that class. There’s no easy slot to mention experiences like that in interviews.
Product managers need to think, to build, to work with others and lead — these aren’t lessons that come neatly packaged in computer science classes. Intercom publishes articles on how product managers must be strongest at saying no. This isn’t a technical lesson but one I learned in poetry classes where you cut every last word until you could cut no more. You hear about getting in users heads — for me these came from classes in human psychology and design thinking, not something I found in the CS department. Yet, instead of an acknowledging the inherent cross-disciplinary complexity of building a product, we celebrate extreme examples of this overlap (see: the philosophy of self-driving cars) as anomalies. How strange, how quaint, that something like the humanities might matter in tech! The reality is these softer skills that examine human truths are essential to imagining new ways to connect to people through products.
As product managers our work is complex and widely unpredictable in terms of depth and variety of skills. Hiring predominantly for technical skills as the sole solid metric we can create a false security which obfuscates the actual complexity of work. Remember, you’re hiring a person, not a skill.
