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.

SLDC 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.

SDLC Image from Tutorials Point

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:

Client CDN

LoadBalancer

WebServer

WriteAPI ReadAPI

MemoryCache

Databases

System Design Image from Didacus on Medium

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 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 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 Testing Staging Production

Software Environments Image from JaxEnter

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.

Github Workflow Image from Build5Nines

Once a developer is satisfied with their code and have

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

platform 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.

Client Server

Image from Cloudfare

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
web server.

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:

Cross
Native Platform

Hybird

Image from Seasia Infotech

Native apps: These apps are built using software

development tools (SDK) for specific Operating
System (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!
: