When did learning to code become the silver bullet to productive exchanges with engineers?
By Tami Reiss (CEO, Cyrus Innovation)
This post originally appeared on Medium.
Over the past few years, I feel like I can’t go a week without hearing someone say, “everyone should learn to code”. And in practically every first conversation I have with an aspiring product manager, I am asked “how technical do I need to be?”
Anyone who’s been around when I’m approached with this topic knows my stance.
I do not think all product managers should learn to code, but I do think we all should be technically literate.
Everyone agrees that quality communication skills are key to being a good product manager [1]. We explain the product vision with all members the team and often translate between the business and engineering worlds. The communication is not unidirectional; we must understand what our colleagues are saying back to us as well.
Many people make what appears to be a logical leap at this point and think that if product people bridge the gap between business and software development teams that they must have a background in coding. How else could one have a quality conversation with a developer about what is being built?
When did learning to code become the silver bullet to having productive exchanges with engineers?
I cannot code, and do not plan on acquiring that skill anytime soon, but I can have an intelligent conversation with software developers about what they are working on. That’s because what is important is technical literacy, not having the specific proficiency in writing code.
What Does It Mean to Be Technically Literate?
Simply defined, it’s the ability to discuss the relevant technology for your product. This means that you can understand and speak with the people deeply engaged in the tech, at least on a basic level. The distinction is that you are not fluent; if you were, you’d be an engineer.
It’s the technical equivalent of ordering lunch and asking for directions to the bathroom in Japan, but not being able to cut perfect sashimi. You can talk about where you’re trying to go, but you leave the details on how to get there to the locals.
Why is Being Technically Literate Important to PMs?
Like anything else, depth of knowledge is dependent on the goal. The primary objective of a product manager is to explain the vision and requirements for what should be built so that others can make it a reality. Before we set a product roadmap, we go through multiple prioritization exercises to establish it.
In order to choose the priority for what is developed, a PM weighs user value against the technical complexity. Without understanding both, we cannot make well-informed decisions. Therefore, talking with engineers about the goals for the user and considering their opinions is key to properly deciding which features to build. Often they’ll provide opportunities to reduce effort by changing the order in which items are developed.
Beyond the ability to work with diverse teams, technical literacy also can reduce project risks.
It’s the product manager’s responsibility to prevent time wasted building the wrong things. As my former manager, Graham Siener [2], explained, “development is the most expensive part of your process, optimize for it.” If the conversation about technical complexity is productive, a product manager can ascertain not only what to prioritize but also change the product design to minimize the risk of over-investment in development.
What Does Technical Literacy Look Like for a Product Manager?
The things you should know vary depending on the technology involved in your product. But, on a fundamental level, you should know enough to ask questions.
When I took a business law class in college, my professor explained to us that her goal wasn’t to make us lawyers, but instead to give us a good gut for when a red flag should go off in our brains. I think the same about the amount of technical knowledge a PM should have; know when something doesn’t seem right and respectfully challenge your peers until you’re satisfied with the answers.
Julie Babb [3] remarks when we “ask questions, developers are excited to share their knowledge. You just have to ask.” This knowledge adds to our technical literacy for our products. If it’s an unfamiliar product, team, or technology, the questions will seem rudimentary at first. Over time, as we learn more, the questions will become more insightful.
Ellen Chisa, who has an engineering background, recently wrote [4] that what matters is “how curious you are about the technical things.” The curiosity she describes leads to asking questions, which in turn allows us to learn more about the technology behind a product.
Through asking many many questions I’ve learned some essential things I think all PMs working on modern software should know about. These include in no specific order:
- How relational databases work and the difference between 1:1 and 1:Many
- What calling an API means and why you’d use one
- How to read a Service Oriented Architecture (SOA) diagram
I’m sure others would add more things to the list, but to me everything else is built on top of the understanding of these items. Over time, a product manager will gain more technical knowledge and become more confident in their ability to understand the details of each product they work on.
Why Not Just Learn to Code?
I ask in return, “What would you learn to code? Ruby? Objective C? C#? Python? Something else???” Then I poke a little more, “will you keep up with your craft and continue to advance your knowledge about coding in the future?”
The reason I ask these questions is to point out that if a person isn’t going to dedicate some serious time to becoming proficient in a coding language, that maybe the initial investment in “learning to code” isn’t the right way to spend that time. Even then, I wonder if in the future whether they will only work on products written in that language? Probably not.
When we interface with other teams (design, legal, finance, sales, etc.), we often ask questions centered on “the why” of things not often the “how.” This is because a product manager’s role is to understand the different pieces enough to make decisions but not enough to do the other people’s jobs.
Therefore, no one says that a product manager should go to design or law school. To paraphrase Outcast, “what makes code the exception?”
I think we should take a similar approach to software development. As Lesley Kg says[5] “you need to understand structures, logic, and how to solve problems; these are skills you have in common with your engineers.” She adds that “at the end of the day, they’re the ones building it, not you.” Know how to do your job, not theirs.
My perspective is that if a product manager isn’t trying to transition into a more technical role, why learn to write code? Software development is a specialized skill, and saying that everyone should learn it is no different than saying everyone should learn to change the car’s oil or to speak Spanish.
On that note, I believe learning to code is like learning a foreign language. It has a specialized lexicon, is unforgiving to bad syntax, and has many dialects. Some people are great at picking up other languages, others are less adept. Though being bilingual is nice, no one feels inadequate if they aren’t.
Personally, I’m an auditory learner and I’m good at learning to say important phrases in the lingua franca of countries I visit, but I’m horrible at absorbing written languages. Because coding is equal to learning a complicated foreign language that is available purely in written form, it’s something I’d have to invest a lot of time in learning. The effort in obtaining the skill isn’t worth it to me when there’s so much else I can be doing to improve my own craft.
What Should I Be Learning Instead of Coding?
As product managers our role is to understand, prioritize, and explain. Why not work on the related specialized talents [8] instead of trying to master the craft of our peers?
When Rohini Vibha [7] lists the top qualities of a good product manager, she emphasizes that these skills are non-technical. Bo Ren relates them to a liberal arts education, not an engineering one and further explains [6] that product people have “empathy for teams and users” which is what differentiates us from simply having “enough technical acumen to communicate credibly with engineers.”
Let’s focus our energy on gaining competence in the areas that set product managers apart.
Some ideas on how to sharpen those skill sets:
- Take a public speaking or improve course and learn to improve your demos
- Sign up for a facilitator workshop to run meetings more effectively
- Attend a Meetup to hear from other product and design folks
- Teach a class about product management and see what questions come up
- Learn about market shifts in your product’s industry
- Get better at asking open ended questions when interviewing people
- Sketch and prototype something and get some feedback on it
What will you do to up your PM game?
This post would not have been possible without some great peers and thoughtful PMs across the globe like:
- Ben Horowitz — Good Product Manager, Bad Product Manager
- Graham Siener — How Technical Should A Pm Be?
- Julie Babb — Confessions Of A Non-Technical PM
- Ellen Chisa — Do I Need To Be Technical To Be A PM?
- Lesley Kg — The Myth Of The Technical PM
- David Lumb — Why You Should Learn Product Management Instead of Coding
- Rohini Vibha — So You Want To Manage A Product?
- Bo Ren — This Is Water
About the guest blogger: Tami Reiss is the CEO of Cyrus Innovation, a New York-based company that provides teams of amazing software developers to enterprises and startups. She is and expert in web and mobile product strategy and UX design and is a champion of diversity in tech. Follow her on Twitter at @tamireiss.
