How technical should a product manager be?

“How technical should a product manager be?”

The question might give you an impression that technical depth is required if one aspires to become a product manager. However, let me save you from that judgment. It’s not a “must-have” skill, rather a “good-to-have” one.

What encompasses good-to-have? A product manager must at least have familiarity with how a product is engineered. Having a technical aptitude helps in situations when the team is in the midst of a technical apocalypse and they need someone to be a good soundboard, and guide them through it.

Product management is more about envisioning the functionality, and then aligning all the stakeholders, business and tech teams, on the same page. Additionally, if a product manager is technical enough to understand the nuances of product development like coding and design, then it helps them make the right product decisions for the team.

In most cases, Product managers acquire these technical skills through succession in their role over a period of time. But what if there is a person who doesn’t have a technical background, doesn’t know programming, but he/she is interested in taking the big leap? Should the aspiring PM first learn to code?? Is that really necessary to be a successful PM?

My answer? NO.

To be (technical) or not to be?

When I think of the reasons that would have triggered this debate, I often workaround a hypothetical situation in my mind. Here’s the story that I make-

Once upon a time, there was a product manager who was interested in building software but he didn’t have any prior knowledge in that field. He had good management skills but he couldn’t empathize with the development team or understand their challenges whilst designing, programming, and testing the product. This lack of understanding and effective communication between developers and PMs often resulted in bad decisions and delayed timelines.

So, one fine day, a group of decision-makers sat together and gave the verdict that this chaos was created because the person didn’t have a technical background. People who were against this decision fought, and the fight is still going on.

You’d be glad to know I’m on their side!

I am of the opinion that if communication is the problem then one should fix that part of the role rather than forbidding talented individuals from emerging as great PMs.

I concur with anyone who has the opinion that if the PM has enough technical vocabulary to maintain effective communication with devs- there is absolutely no need for them to have a strong technical background, especially coding experience.

It’s important to understand that your role demands that you make your product stand out. You must first understand the value your product creates for its users and what business benefits it should deliver in order to delight its people.

In fact, having a PM with less technical expertise and more visionary skills is actually a blessing in disguise. The more technical knowledge you have, the more tempting it’ll be for you to interfere in the decisions that the technical team takes. Human nature, I tell ya!

A PM who understands the domain, has empathy for users, invests time in creating delightful UX, and assists marketing and sales to fuel user growth is far more valuable than a hardcore technical-PM.

Technical background is just icing on the cake. And if you’re still adamant, here’s a list of things that are more than enough for you to know-

1. Understand the basics of how client-server interaction works.
2. Very basics of how the database works and how data is fetched from backend and taken to the frontend
3. Understanding of HTML and CSS, and basic design knowledge
4. APIs and their technologies
5. Current technology trends.

And once you’ve acquired this knowledge, ask yourself below questions-

• Am I communicating effectively with the developers? Do they know what problems we are trying to solve?
• Do I understand what developers and QA are saying even though I might not have a strong opinion to put in the conversations?
• Am I able to identify and understand problems shared by the dev team? Or, am I becoming a bottleneck in the execution?
• Does my knowledge help me come back to them with an answer if not a solution? Or, do I need to learn new tools and skills?

Conclusion

Just like you don’t learn the mechanics of flying a plane when you are on a flight, in the same way, you don’t need to be an expert in everything related to product management.

Instead, surround yourself with experts. Take help from team members who are passionate about technology. Combine it with your decision-making skills to build great products.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by people of Quovantis to share their learning.