How Technical Should a Product Manager Be?
Toeing the line between Superpower and Kryptonite.
A great Product Manager has to somehow be the jack of all trades while also being their master.
At least that is the impression I get when reading almost any job posting for one. When I first came across the role, I felt the rush of a very promising challenge. I don’t know much about superheroes but surely, this is a fair comparison. One must be influential, managerial, entrepreneurial, eloquent, and dependable. One must also be technically skilled, understand the fundamentals of user experience, be effective at stakeholder management, and be able to lead a cross-functional team to deliver value to the business.
Having been a Product Manager for a couple of years, I find myself really exploring the value of all the boxes one tries to check in their quest to be a great PM. In particular, the need to have a deep understanding of technical concepts. As someone with a technical degree, I have always considered my technical education to be my most valuable superpower in the world of Product. It may not be as strong as in someone who has practical work experience in the field but it has proven very useful in the early years of my career. I have, however, recently learned that it could also be my Kryptonite.
Most aspiring Product Managers are aware of the pros of exercising their technical skills on the job. However, all good things should be done in moderation. As a less seasoned PM, I need to always be reminded that my ownership as a PM should live exclusively in the context of the What and the Why — not in the How. The How should always be left (in majority) to the experts — Developers, UX Designers, Data Engineers, etc.
To put this idea into perspective, I’ve compiled a list of the pros and cons:
DO use your technical knowledge to inspire and challenge your team.
Having a technical understanding allows you to know how and when to challenge technical stakeholders, encourage your product team to be more ambitious with their estimations, and obtain the real technical “costs” of every new initiative. Being able to quickly grasp technical complexity allows a PM to run efficient and focused ideation with their peers as well as facilitate agility by knowing how to break down larger problems into smaller, valuable chunks.
DO NOT let technicality dictate the decisions you make.
Many times, I have found myself spending too much time in the solution space not only because it is intriguing, fun, and challenging, but because it gives me a chance to flex my technical chops. In doing so, I have regrettably made many decisions based more on technicality and less on desired outcomes (which should always take business needs and customer value into account). This has led to decisions that are not holistic.
DO use your technical knowledge to build trust with your team.
PMs must lead by influence without authority. In order to do so, PMs must build credibility within their team. In my experience, trust comes easier for those who also share deep technical knowledge. Difficult concepts can be communicated quicker. New ideas from emerging tech trends can be trusted to be rooted both in business needs, customer pain points, and a clear assessment of current technical capabilities.
DO NOT take ownership of technical decisions away from your team.
This is particularly true when a feature or initiative introduces technical constraints. In situations where trade-offs need to be made between technical complexity and feature scope, it is important to come to decisions collectively. I have found that being technical has led me to take ownership of technical decisions away from the technical experts in the team. In doing so I inadvertently made myself more accountable for a solution than my own team. Ownership within members of a team is difficult to cultivate if they are not given the space to make their own independent or collaborative decisions. Ownership should always be on the team, not just on the PM.
DO use your technical skills to be an effective communicator.
This skill set is extremely useful for stakeholder management. Bridging communication between the technical and non-technical without dilution is something only having technical acumen can cultivate. Rallying stakeholders of various backgrounds around a purpose always proves difficult without deeper technical context.
DO NOT make commitments without consulting your team even if you believe you have a handle on the technicality of an initiative.
In the face of exciting ideas, I have, in the past, allowed commitments to be made solely based on my assumption of the complexity of a feature. Though well-meaning, jumping the gun on committed scope and dates without taking time to consult with one’s team can cause misalignment, scope creep, and ultimately missed commitments. It can also lead to a loss in team trust and credibility which, once lost, is difficult to regain.
Superpower vs Kryptonite
The growth of a PM lies in getting increasingly strategic and decreasingly tactical. At the beginning, it is vital for a PM to really understand and facilitate the execution of their product. In this phase, that technicality, though beneficial, could stunt their growth. However, in order to progress, I believe a PM needs to learn how to hold back on their technical instincts and advocate for the experts in their team to take that ownership. Learning this balance is very difficult. I have definitely not mastered this yet. How about you?
This piece was inspired by a colleague’s experience transitioning from Development into Product. (Shoutout Christopher Ciufo!)
“Your technical background will be your superpower as a Product Manager but in the early days, it will be your Kryptonite.”
This is piece is entirely my own opinion. Happy to hear feedback and discuss further!
** Also published on linkedin.com/in/sasithrathanabalan/
