Often times, I get asked the question, do I need to do some technical courses? They often time point to job descriptions that require an understanding of technical roles.

And if you’re planning to get into technical PM roles, definitely! You need to know what you’re talking about — especially when you’re in sales meetings.

However, for general product management, there is no need for you to get your hands dirty in the code. It helps though.

Your role as a product manager, usually, will need you to position yourself as a product leader for your Development Team (which includes not only Devs & QAs but also UI/UX, Analytics, and others). And this is where things get tricky.

Even Architects need to know a little about civil engineering

If you’ve ever looked at basic architectural degree courseware, you’ll notice a strong focus in the early years on construction technology.

They need to know how their plans are converted to physical structures and the challenges involved. Their foundations (pun intended) need to be strong.

Left looks like someone designed it without taking into gravity!

However, they are never judged by their understanding of construction science. True, those who understand construction science are sometimes better valued over those who don’t, but that doesn’t make or break a great architect.

Similarly, Product Managers need to know how their backlog will be converted into a product, used by 1000s of users. It just makes sense to know what the challenges are before you jump into a backlog recommendation.

Advantages of knowing where to dig the well

I prefer having a working knowledge of design/tech & analytics. There is so much in knowing how the product will be built than just thinking outside the box all time.

Too many out of the box ideas will brand you as crazy and you’ll lose influence over the product backlog.

Sure, if you can make sense from the above (the best dig site is 1), you’ll point out that that’s the job of the developer. But remember, you dictate which site to dig based on the backlog.

A strong Development Team will question your understanding of the ground layers before they start digging. But often, they’ll just start digging till they reach the rock bed.

Then you have to figure out the additional resources you need to complete the dig OR abandon the project altogether.

Analogous to the above situation is to know which problems to tackle first, but having the know-how of the type of issues you’ll encounter will ensure you reduce the burden of discovery.

Practical Example

You are leading a SAAS product where you’ve got a demand for creating a new API set that’ll allow the users to connect the data to their favorite BI tool (Tableau, Data Studio, Power BI).

Knowing that your database cannot handle the load that these tools bring, will quickly help you know what your preparation steps are… i.E. You’ll prioritize the scaling and replication of the dB over the creation of the API (or parallel work, depending upon the development teams preference).

In the sales call, you’ll know that you need to do some groundwork before you commit to the delivery.

Where do you draw the line?

Exactly how much technical knowledge is too much technical knowledge? Curious question — which can have answers depending upon your aptitude and your ability to separate the technical side of you from the product side.

If you find yourself weighing in on the technical decisions of your team, you need to stop. They are the subject matter expert here.

Use your technical know-how to nudge the team. Keep them on their toes. Remember, in the grooming sessions, you’re allowed to question.

Pose your knowledge as inquiries — “Do you think the database can handle the load?”, “Do you think we need more time to simplify the logic?” or even, “Can this feature be built this way?”.

Asking such questions will only enhance your knowledge. The side-effects are that the team will think twice before coming up with a solution (now that they know you know the technical side) and your team will deliver the best possible value to the users.

In all the things I have experienced as someone who has a technical side, the most difficult aspect is to keep yourself in check. It is easy to go to the drawing board and come up with a solution.

A little knowledge makes you feel wise and capable. A lot of knowledge forces you to second guess your decisions.

Non-technical product managers are successful too!

Lastly, there is no hard and fast rule you need to know everything about technology to be successful. Even non-technical PMs are successful!

However, if you ask them, they’ll tell you that they have, over the years, learned a bit of tech just to partake in discussions, directly or indirectly. The nature of work that we do, will invariably, brush off some of the technical know-how on us.

Product management is all about finding the right balance between your skills, your team's skills and your users needs. My experience has shown that if you can offset some of the things your team lacks, you can deliver stellar features to your users.

Play to your strengths. Don’t get overly obsessed with your shortcomings.