Explore Must-Know Technical Concepts For Product Managers: Your Guide to the Mind of a Dev

Photo by Milad Fakurian on Unsplash

Software product managers with no previous experience in a technical role and who do not know how to write code can now loosen their grip on soft skills and transferable skills. Those are great but not always enough. A reasonable knowledge of software-related concepts is also needed.

The role of a software product manager also known as a digital product manager is to oversee the entire lifecycle of a digital product from inception, launch, and post-launch. It is only logical that added to PM skills some technical understanding is expected, especially for PMs in early-stage startups.

In this article, I have compiled a rich list of resources that have been helpful for me in my product management journey. I have arranged them in a way to give you a crash course on relevant software-related concepts that non-technical product managers should know.

1. Software Development Life Cycle

As a product manager, most of what you do falls within the Software Development Life Cycle.

SDLC is a process defining tasks performed at each step in the software development process. It defines a way of timely improving the quality of software built to meet the needs of customers, and within cost estimates.

2. System Design

This is the process of designing the elements of an application in such a way that it is easy to develop and change. System design gives developers a detailed sketch of how they plan to build an application—the architecture, components, modules, data, etc. They know where what goes. Here is a breakdown of some parts of a system design:

• Content Delivery Network [CDN]: This is a network of servers [Let’s call this branch servers] that get content from an origin server [we can call this the master server], and distributes the content throughout the world by caching content close to where each user is accessing the internet from. This distribution helps websites load faster. Click here to read more on CDN.

• Load balancer: This acts as a traffic warden in front of the servers [branch servers]. When a user [also known as the client] makes a request, the load balancer routes the request to the server that is capable of fulfilling the request speedily and efficiently. This way, the traffic of requests is shared amongst the servers in such a way that no server is overworked, and downtime is well managed. Click here to read more on the Load Balancer.

• Microservices: This is more or less building an application in independent chunks with well-defined interfaces and operations. Each microservice [we are calling this chunk for clarity] performs a single function [its specified job] like payment, shipping, etc, based on the business logic.

• Database: This is the systematic collection of organized information stored in a system. The developers gather the information they want to record and categorize them into appropriate tables for storage. This database is controlled by a database management system. Click here to read more on Databases

To study extensively on System Design, click here.

3. Software Environments

In software development, separate environments are used to build, test, and ship the entire product. Here is an explanation of them all:

Development environment: A developer’s computer where code is written, bug fixes made, and unit tests run locally, is referred to as the local environment. Whatever the developer does in this development environment does not influence what other developers are working on until the code is pushed to a shared environment like Github [more on this later].

Staging environment: This environment is a mirror of the production environment. It is designed to demonstrate the product progress to product owners, test the code, and fish out potential bugs. Any bug found in this environment does not have an impact on the real users as it is basically a test environment, not the production environment [the real deal].

Production environment: This is the ‘‘Live” environment where the finished product enters the market ready for commercial use. This environment has live data and is accessible to the general public.

To study extensively on Software Environments, click here.

4. Version Control System:

Developers working on a team have a central place where their source code is stored [online repository]. They create a branch of this main repository [master branch] and individually write their code for the part of the application assigned to them.

Once a developer is satisfied with their code and has done all due diligence, they then create a Pull Request [PR] and request a code review, so that their code can be merged with the main repository.

Github is one of the commonly used code hosting platforms for version control and collaboration amongst developers. It helps them know what changes have been made. They can view the annotated history and revert to any version of the code.

To study extensively on Github and Pull requests, click on the respective links.

5. Client-side and server-side:

The client-side is sometimes referred to as the front-end [the user-facing side] and the server-side as the back-end [where the data and source code is stored]. Full-stack developers know how to use both client-side and server-side development.

Form validation, cookies, flash games, etc, are examples of what happens on the client-side [the user's computer], while on the server-side actions like connecting a website to a database take place on the webserver.

 Click here to read more on client-side and server-side, and here to read up on serverless architecture.

6. Application Programming Interface [API]:

This is a software intermediary [a messenger] that allows two applications to communicate with each other and leverage each other's functionality. It is like the waiter at a restaurant who takes your request over to the kitchen, they prepare the food, he collects the food, and brings it over to you at your table.

For example, when the client-side [the user's computer] makes an API call to retrieve information [request], the API receives the request and makes a call to an external program or web server.

The server sends a response to the API with the information requested, the API then transfers this information to the requesting application [the user's computer].

• Third-party integrations: When developers are building an application, there are times that they do not need to build every single component from scratch. They can always leverage already existing components from third parties using the third-party APIs. Click here to read more on third-party integrations.

7. Native vs Hybrid vs Cross-platform

To build an app, a decision has to be made on whether to build it natively or as a hybrid. Here is a short explanation of the platforms:

Native apps: These apps are built using software development tools (SDK) for specific Operating systems (OS), like iOS or Android. The code used on one OS is not usable for another.

Hybrid apps: These apps combine the features of both native and web apps, and the codebase is reusable on multiple platforms. They can either be downloaded just like native apps or accessed from a web browser.

Cross-platform apps: These apps allow code shareability just like hybrid apps. But the core difference between cross-platform apps and hybrid is the better user experience on different UI, as a framework like React Native allows the use of native UI views.

In Conclusion

Although some product management roles like API Product Manager require the product manager to have core tech skills, most just need a product manager who knows enough software concepts to understand what the developers are saying.

What I hope that I have achieved with this article is to help you move from “I have no idea what the devs are saying” to “I deeply understand what’s being said, what’s important, and the implications for my product”.

Going forward, when you listen to your devs discuss the architecture, dependencies, tech requirements, and assumptions for your product, I will be happy to know that it is no longer all Elon Musk Jargons to you. Feel free to share your experience with me on Linkedin.

Know someone who is trying to get into the product management space? You may want to share my previous article on Entry Level Resources for Becoming a Product Manager with them. Thanks for sharing!