Should PMs Possess Technical Skills?
The Product Manager role has become a popular career choice among fresh graduates and professionals in the digital industry. As startup companies rise in the past decade, the role of a digital product manager has gotten more attention than before.
The figure above implies that working on digital-based products often requires intense coordination between the Product, UX/UI, Tech, and Business/Marketing team.
An entry-level product manager (Associate/Senior Associate) tends to focus on execution and spends more time with the tech team. This interaction involves discussion around the product architecture, functionality, behavior, and presentation of the product/feature. Therefore, as a PM, you will hear and use some technical terms, whether you like it or not.
As a PM, I am personally privileged by my educational background and prior experience as an IT technical consultant. However, many people who do not possess this technical background want to pursue a role in Product Management. (You can read my journey into my PM role in my previous post here https://medium.com/@frederycolie/journey-of-a-co-incident-pm-tech-consultant-banking-end-up-at-e-commerce-giant-46bc47ea3d73.
The question that I often receive from peers, practitioners, and college students is: “Does coming from a non-technical background hurt a person’s chance to succeed in a product management role?” By saying non-technical background, I am referring to a background with no involvement with tech stack and coding.
A product manager is a tech-literate, not a tech fluent
Melissa Perry wrote in “Escaping the Build Trap”: “A Product Manager is a tech-literate, not a tech fluent.”
I find that articulation robust and helpful in answering our main question.
If I stop for a moment and imagine my day-to-day as a product manager, I can see where Perri is coming from.
As a product manager who works hand-in-hand with software engineers, technical discussions are inevitable. Remember, to succeed, a product manager has to effectively communicate the product vision to the team — and engineers are a part of this team. Someone with a tech background who possesses the ability to communicate fluently with software engineers would have an advantage. He can grasp the technical complexities of a product and foresee technical challenges and blockers.
Here are some of the perks of being a tech-literate product manager:
- Asking relevant questions to the engineering team
Sometimes you find out that your features/product is not working properly due to bugs or errors. Having decent knowledge about the stack and code enables the product manager to address a relevant question to the engineer. Sometimes you can even participate in brainstorming the technical solution when you are good at technical. - Writing a proper technical specification
Every product manager has a set (usually short) timeline to create and get the product out the door. When you are familiar with technical stuff, you can optimize development time by writing a proper technical specification document. Having well-written documentation, enable the engineer to grasp your idea and craft it for you without consuming too many alignments session. - Having higher confidence
A great product manager is a good storyteller. You are not only looking for a VP of product to buy in your vision but also necessary to get the engineer to buy-in. Displaying a high grasp of the technical elements of the product to your engineer can boost your confidence level while you are trying to convince them. Furthermore, you can provide the rough timeline estimation of the product/feature delivery or gauge technical capability for some business requests that come across during a meeting by the business team or other stakeholders, making you a helpful counterpart to the other stakeholders.
In a nutshell, having an understanding of technical things like UX wiring, design, software development, and data manipulation will help a product manager to communicate, problem-solve, and coordinate with the team. You don’t want to squander your software engineer’s prestigious time with a meaningless and going-nowhere of back and forth discussion just because you lack an understanding of the common technical stuff. Again, you don’t have to be a master of writing code or designing web, but you ought to be understanding enough to let your team grasp what exactly you want to build or solve.
What are the common technical things you need to know as a digital Product Manager?
Now, if you want to devote some of your time learning and understanding pertinent technical things, you can start by discussing with your engineer or engineer lead, subscribing to some online learning program or Bootcamp, or by reading some helpful books. To help you onboard on this learning journey here is a few suggested topics to start you off:
- Product Architecture Learning about product architecture will help you profoundly understand each layer of your application and how each part integrates with each other. For instance, if you are a product manager of e-commerce apps, and you want to build an app where users can see and buy the product. Your application will comprise of the following layers:
Front-End or the presentation layer for users to interact with the apps. It shows the product catalog, text, image, button, field, animation, etc. on the user screen.
Back-End or the logic layer or the “input-process-output” layer. Here is where you put the logic, instruction, or behavior. For example, when users buy one book in your apps, the Back End layer will run the instruction to deduct the quantity of that book by one, and send the remaining amount in the inventory to the front-end layer to show it on the user screen.
Data Layer: it is where you store any related data of your application — for instance, the user data, seller data, transaction data, inventory data, etc.
There are some other approaches In learning product architecture in the market (e.g., client-server architecture), so go talk to your engineer lead for a proper start.
Understanding your product architecture benefits you in designing your product functionality and writing your technical requirements. It also helps tremendously when figuring out bugs or errors. - System Architecture
Moreover, you can also learn about System Architecture. It is the broader and high-level architecture level compared to product architecture. There are two popular system architectures that internet companies adopt nowadays: (1) Monolithic architecture and (2) Microservices architecture, Understanding both will help you in expanding and enhancing your product especially when you are in a more prominent company. - API
API or Application Programming Interface, you could find plenty of resources that lecture about it (e.g. Understand API). My definition is that API is the library of the function and behavior of your product or feature. API is not merely being consumed by a single application, but also by other systems/apps internally or externally. I highly recommend you have a deep understanding of API and creating API contracts, as you are undoubtedly going to deal with API in the product development phase. - Performance data measurement and manipulation
I bet every product manager needs to continuously keep an eye on their product metrics for further decision making. Providing metrics data in big companies is commonly served by data analysts however, in a small startup with a lean team, sometimes it takes product managers to do it themselves. Hence, data manipulation skills help product managers in providing data, as well as help to pick the right dataset to be gauged as the north star metrics. You can learn SQL Query language, a ubiquitous tool for manipulating raw data into a more readable and useful form. A great product manager won’t jump to a conclusion without lighting from data, so possessing data manipulation skills can avoid product managers to make groundless decisions towards the product.
On top of that, during your time exploring those skills above, you might be exposed to other technical things around, so don’t stop there, instead explore as many as you can, because the more you know, the more comfortable for you to communicate with your team.
See you in the next post!
