As a PM, do you need to know how to code? Write software? As with many questions related to product management, it’s not a black or white answer. There are shades of grey. You technically don’t need to know how to code to perform your daily tasks as a PM. There’s no coding session when you are being interviewed for a PM position. But you should have some basic competency in writing software and even deploying real products for real users to use. In this newsletter issue, I talk about why you should know how to code. In the issues after this, I provide an overview of common software languages and frameworks that you can explore on your own as necessary.
It’s not so you can help write code
Maybe it’s obvious. But just in case it’s not, you shouldn’t be writing code for your product! Writing code is a team activity. So your well-intentioned contribution very likely would disrupt the team, and actually slow them down. It’s often tempting to try and help out. And even if you have all the requisite technical skills to contribute, you might not be aware of all the team dynamics involved. So be very careful in this context. There are some small exceptions however. It’s probably safe to contribute a small typo fix or maybe even a bit of CSS. But exercise caution and know your team before you do start help out in this way.
Collaboration with engineers
The primary reason for knowing how to code is maximizing your collaboration with engineers. Every other reason is essentially a corollary that emerges from this main point. If you know how to code, you’ve entered the world of engineers, at least partially. You can now speak their language. You can now understand their mindset. And if you’ve been involved in building any products in a real-life setting, you’ll know that it’s often a very messy situation. There are many moving parts. There are internal business stakeholders and their interests. There are existing users and legacy workflows. There are ongoing risks with the technical infrastructure. And so it’s your job as a PM to aggregate all these concerns, and work with the core product team, often containing at least a few engineers, to advance the product accordingly. And so if you can collaborate and communicate with engineers, entering their world, it makes you that much more effective, as a PM.
Focus on solving business problems
Everything you do as a PM should be ultimately considered and evaluated as a business problem. As a PM, you should already have basic competency in translating all your daily activities into this light. And so when it comes to technical concerns, you want to do this as well. In fact, software engineering is often times one of the riskiest activities in a business. (It’s called “engineering” at the end of the day. It’s not a science!) Despite decades of technology advancement in software, creating and maintaining software is still very uncertain and high risk. And so that’s why as a PM, if you have a least some basic literacy in coding, you can do a much better job at quantifying those risks, translating them to a business context. As an example, consider tech debt, which I detailed in the previous newsletter issue. If you know how to code, you are more likely to be able to manage tech debt as a PM.
Engineers should be solving business problems. But often less experienced engineers may tend to get caught up in a technical discussion and lose the business context. So as a PM, you can help re-orient engineers to a business focus. The goals of any project or initiative should have a clear business articulation. Nudge engineers in this direction. Help them think business-first, at least at the problem abstraction level. Often it’s easier for you as a PM without a strong technical background, to learn enough coding basics, in order to converse effectively with an engineer, than the reverse.
Leave room for technical solutions
Once a problem has been articulated from a clear business perspective, leave room for technical solutions. This is where you should really lean on engineers and their expertise. You pose business problems, and they provide technical solutions. In practice, the lines are very blurry. And so this is why knowing how to code is extremely beneficial. You can have an intelligent conversation with an engineer, poking at the problem, maybe even offering some technical ideas based on your cursory understanding of the technical underpinnings of the codebase. But don’t go overboard. Just get the engineer thinking, and leave the ultimate technical solution to them. And so in this way, you are able to dance on that line between business and technical carefully, making the collaboration that much more efficient. You want to ultimately leave room for the engineer to make the final technical solution. And along the way you help the engineer reach it.
For example, a search feature may be very slow for your users. You suggest to an engineer adding an index to a database column to speed it up. (But also make it clear that the business problem to be solved is speeding up the search feature.) That helps the engineer quickly zero in on the problem. It turns out there’s some tech debt in the code logic slowing down the query. So, it shouldn’t be solved with adding a database index. The engineer says the tech debt should be fixed instead. This is the type of back-and-forth you should have with an engineer, as a PM.
📬 Mentorship in your inbox: Subscribe to Product Management 101
Product Management 101 covers practical tips and basic skills for aspiring and new product managers.
I’m Victor Wu, Head of Product at Tilt Dev. I’ve been creating digital products for over 15 years, and mentoring folks for much of that time. Subscribe, and reply to email updates with questions you’d ask in a real-life mentoring session. I’ll answer them in future issues.