Do Product Managers Need Engineering Skills?
It's one of the most common questions when talking about the product management profession.
No, product managers do not need engineering skills. OK, article over. Thanks for stopping by.
All joking aside, it’s a legitimate question, and it’s one that many people might assume I fall on the other side of. I am/was/kind-of-am an engineer. I’m technically inclined and I can code. It informs a lot of my product decisions and the way I work with engineering teams. However, I didn’t come from an engineering background first. I came from a product background first.
I define product background loosely here. I have worked with customers for my entire career, going all the way back to my grocery store days. That foundation builds the empathy necessary to succeed in product management. When I moved into a tech role, I worked in what was called the Customer Experience Division. Again, more empathy building. I was charged with understanding the customer journey through many different processes in the app. I had to spot friction points and opportunities for improvement. However, I didn’t have the power to enact any changes. I simply had to capture those suggested changes in slide decks and presentations. Later, when I moved into the startup world, I got to do everything. This included distilling customer feedback, bugs, and ideas into an actionable backlog. The CEO of that company was the only real product manager, but my experience at this company was roughly equivalent to product management. Over the years, I’d been picking up more and more technical skills. And finally, I taught myself to code so I could build an app that turned into a startup.
Those technical skills and, eventually, the ability to code helped me build empathy for engineering teams as my career progressed. Rather than ask blindly how long something might take to build, I had a general sense. If there was a feature that needed to be built, I could understand the tradeoffs. When I transitioned into my role at Pinata, this skillset proved incredibly valuable. I didn’t trade speed for engineering empathy. Instead, I built product around what was feasible and hammered down the scope of problems rather than just expecting engineers to hammer down the scope of the solution.
Though, as I grew into a leadership role and began hiring PMs to work with me, it became clear that having the ability to code was not the secret sauce that made for good product management. It might help, but it helps in the same way any skills help—they aggregate to form a complete solution. None of the PMs I’ve hired at Pinata can code, and yet they are all insanely talented and continue to move the product forward. While observing them in action, I’ve learned three important lessons.
Curiosity drives progress
Strategy comes from commitment
Trust means more than engineering skills
Curiosity drives progress
A product manager’s main job is not to push tickets across the finish line. It’s to be curious. Curiosity is often misunderstood, so I’ll try to provide my best definition of it in the context of product development.
Curiosity is information-seeking. Rather than seek the answer, seek the way to find the answer. If it sounds a little bit like the old teach a man to fish proverb, that’s because it is. Knowing how to find answers will make you infinitely more powerful than knowing how to ask for answers. Bringing this back to coding, if you ask any honest engineer, they’d probably tell you that a decent amount of their success comes from knowing how to find answers (i.e. Google and now ChatGPT). Curiosity extends beyond searching for answers externally, though. In product management, curiosity should include information-seeking through experience. If you’re not using the product you’re managing, you’re not seeking out all the information you can.
Strategy comes from commitment
Product strategy is a vague term. When used as a measurement of someone’s capabilities, it can be frustrating. John Cutler, who writes a fantastic newsletter about product management, recently wrote about this problem:
Phrases like product sense and product mindset are equally slippery for this reason. Are these placeholders and shorthand for something else? Outs or inputs? Capabilities or skills? Can they be learned? Through years of experience and trial and error, a 6hr certification course, or something in between?
For this reason, I don’t intend to define in detail what strategy is. I think strategy is simply an output of certain inputs. One of the most important inputs is commitment. I’ve seen this so often with my team. The commitment to a vision, to the customer, or to the curiosity that we discussed previously creates the inputs that drive the strategy output.
Trust means more than engineering skills
Trust cuts both ways. Product managers have to earn it and they have to give it. I’ve watched PMs on my team excel by simply building strong trust within their teams. Trust leads to confidence. Confidence leads to commitment. Commitment leads to strategy. Strategy leads to execution.
You can build trust with engineers without having coding skills. You do this by listening. Everything comes back to listening, doesn’t it? You listen when they tell you something might not work. You listen when they tell you something will work. You listen when they provide product and design feedback.
When the team works as one, PMs can execute almost any vision without knowing a lick of code.
I think engineering skills can make you a better PM, but they are by no means a pre-requisite. I can say this with confidence because I’ve seen it in action many times. So, if you’re a PM or an aspiring PM and you’re worried about a lack of coding skills, just know that there is a path forward. And if you are a PM who can code or an engineer that wants to move into product, use your powers for good and feed the three lessons from above.