Does a Software Product Manager Need to be Technical?

I founded WP Opera in 2019 and from the early days I have been wearing many hats. Sales Manager, CTO, Product Manager, and Solution Architect. I am coming from a solid technical background but I lean a lot towards customer success, business, and management. When working at a corporate level, during my time with Squiz, as a Senior Consultant and Software Engineer, I have been blessed to be merged into a formidable culture that brought my career to be what it is today. For a brief time, I have been working in the Squiz Product Team, building the next generation SaaS product and a new role came up as Product Manager. I wished to apply for that role but I was excluded from participating in the interview process by the production manager at that time because: " Dom you are a Senior Dev, you cant be a product manager".

I am not a person whom you can tell what "I am not" so here I am designing, producing, and managing my own product!

Before finding the bravery to start my own endeavor I have been doing my homework and I found out the top 5 benefits that a technical background brings to the role of "Product Manager".

5 Benefits of Being a Product Manager with Technical Skills

As Product Manager for the past 2 years, I made my own mistakes and I have been drilling down on how my technical background has been affecting my performance. I learned how not to allow my technical side to crowd out the rest of my Product Manager role. The temptation to become too focused on the technical side of the product is always there because that’s where I feel most comfortable has been there, and I have learned how to manage it. The feedback from my customers has been precious and I will forever be grateful to them. Ok now that we have cleared what is the downside of being technical let me talk through some of the reasons that being a technical product manager can greatly benefit both you and your company.

1. Being better-informed about your product and how to manage it generally speaking.

Squiz, the Digital Transformation company behind Squiz Matrix CMS, has an interesting policy for their employees. When you start in the company, you have to spend your sweat deal of weeks/months working full-time in customer support.

Why do they do this? I never been told, however, my guess is that the company points out that it’s the best, fastest way to get new employees familiar with their products the way customers actually use them. That makes sense: Answering dozens of real-world questions or complaints sure seems like a better way to gain a deep understanding of your company’s products than just reading their marketing literature.

In my experience, I quickly learned what is under the hood of the product, spoke with dozens of devs and their managers, but also collected the frustration of the customer about features that were missing or not working out for them and connect the dots between the customer needs and the product roadmap.

Now I am dealing with my own customers, as a Product Manager with technical skills I know what and how to address my customer request and go to the devs that are helping me build and maintain my product with straightforward technical information, what actions they need to apply, they can give me feedback in terms of effort required and we can then generate Tickets and triage them in order to get quick wins for our customers and come back with instant resolutions.

Speaking of which…

2. It helps you better be aware of development timing, scope and requirements, resources, and roadmap prioritization.

All of this will be very beneficial in setting the stakeholder expectation, which is clearly going to benefit the mental health of everyone involved in the project. One of the duties of a Product Manager is to keep the budget and roadmap clear for all the stakeholders so those who are investing money in the product know exactly what is going to be delivered and how much is going to cost and who is developing has awareness of the budgeting and why the Product Manager is guiding them towards a direction rather than another one. The common mistake for a Product Manager is to listen to the Development Team and let them make decisions that will double the effort down the road causing delays in production and increasing the cost of development for instance.

This leads to yet another benefit of being a technical product manager…

3. It helps you better recognize when your engineers or developers are wrong (or even exaggerating a bit) in the planning or resource estimates they give you.

As a Product Manager responsible for a technical product like a SaaS Platform, you will ask your development team to add new features or modify an existing one, and they may estimate that it will take them three months to code, or will require four dedicated development resources at a higher rate and skills, and that answer is not at matching at all what you are willing to hear from them,

How to approach the situation?

Well if you’re not technical, you won’t know if that assessment is correct. You won’t know, either, if they’re telling you a bit of a tall tale because they want to give themselves some more buffer between projects or if they’re simply negotiating with you for more time.

If you’re technical or you have even a general sense of what’s involved in coding the functionality you want—how long it takes, how many people, what level of skill is needed, etc.—you’ll be able to sniff out these problems and show your developers that there’s probably a way to get it done. And if they know you’re technical, they’ll be a lot more likely to hear you out.

This leads us to another important point...

4. Your technical skills will earn you the respect of your technical team which is very critical.

As a not technical Product Manager—if you cannot see the whole picture of the details behind how the product is actually built and upgraded, what dependencies are involved, etc.—then your development teams are much less likely to respect you or take seriously what you’re asking of them.

A lot of your role will involve negotiating with various teams to get things done for your product. When it comes to development, you’ll have to advocate for your technical teams to get as much done for your product as quickly as possible.

They might assume they know better than you how to build your product. And they might be right If you are a hands-on Product Manager you can even handle the little tasks on your own saving them to spend time on simple operations ( even helping with testing ) that can for sure increase your own understanding of the process and increase your appreciation for the effort that your team is putting in the product.

This takes us to the last but not least point ...

5. It helps you better understand the new technologies and threats that are always on the horizon, and predict market trends that could be critical to winning over the competition.

You are a Software As A Service Product Manager and you repeatedly hear rumblings in your market about, say, GraphQL, you’ll want to know if this new technology affects your products that are currently delivering a CRUD REST API. Maybe it has nothing to do with your product portfolio; maybe it represents a powerful new design pattern or methodology that you and your team should be looking into right now because it could become a potential competitive advantage, for instance, a Serverless design pattern that will save you a lot of money over your AWS Bills.

Having some technical knowledge here will be valuable. You will be better equipped to spot technical developments in your industry—opportunities as well as threats—that might affect your products and your company’s bottom line.

The more technically savvy you are, the more comfortable you are reading your industry’s tech magazines and blogs, and the more prepared you will be to properly react to these new technological opportunities and pitfalls.

Overall if you are a Software Product Manager, technology represents the foundation, the bricks and mortar of your Building, and you should be able to make educated choices over what material your building needs to serve its purpose at its best for your customers.