Technical jargon for PMs
The ultimate collection of engineering terms and what they mean
Hey, I’m Colin! I help PMs and business leaders improve their technical skills through real-world case studies. For more, check out my Live cohort course and subscribe on Substack.
One of the most common insecurities for product managers is technical skills. Let’s get you feeling a bit more confident in 2025!
How internet software works
As a quick reminder, all internet software products follow the same core patterns. They have 3 main components:
Client – what your users interact with. Eg: website, mobile, tesla, smart fridge
Server – processes requests to fetch and store data or perform actions, like syncing your google calendar
Database - permanent storage of data
Each section can be expanded into many smaller components. A lot of thought and effort goes into building scalable, well-organized software products. Let’s dive into those components and what they mean.
Frontend
Our frontend application refers to the code the user interacts with directly. This code can be written in different programming languages depending on the platform (web, mobile).
This code is distributed to the user by connecting to a website or downloading from the app store.
The simplest front end stack for the web is HTML, CSS, and Javascript.
HTML is the structure of the page, outlining the order items appear in.
CSS is the styling like fonts and colors.
Javascript (JS) is the interactivity that allows you to play an animation or load new data on a page.
Web development has evolved as applications have become more complex to use frameworks. These frameworks provide tools to help developers organize their code better.
Common frameworks for front end web applications include React, Vue, Angular. These frameworks allow developers to split up their code into reusable components.
In order for your frontend application to get information from your database, it needs to send HTTP requests. These requests are received by your backend server and processed.
Common requests include:
GET - retrieve information
POST - submit information
PATCH / PUT - update information
DELETE - delete information
When your client submits a request to the backend server, it sends it to an endpoint. An endpoint is a location that has been set up to receive this request, like a mailbox that is created to receive letters.
Backend
Your backend contains all of the technical infrastructure. This code is not distributed to your users – instead, it stays isolated from the rest of the internet. The only way to access it is by making API requests.
Your backend is likely hosted in the cloud by providers like Amazon Web Services (AWS), Google Cloud (GCP), or Microsoft Azure.
These services allow you to rent components of your backend application stack like your database or server. There are many components available for rent that can be connected together like legos to solve various problems.
When you rent these services, you temporarily buy the use of some software and computing resources. You can add or remove resources based on your needs at any time.
Common examples include:
API Gateways: A service that receives API requests and sends them to other servers in your backend
Caches: A faster, more expensive data store. Used to speed up retrievals of commonly requested information from your database
Queues: If you are getting too many requests at the same time, or want to limit how many requests you send out, queues allow you to store requests until you’re ready to process them.
Content Delivery Networks (CDN): Storage of files that don't change, like images and videos, around the globe to speed up load times for users
Scaling
The backend of a product that supports 10M+ users will look very different than 1000s of users. In order to handle additional users, we need to scale.
Scaling refers to adding more resources to our backend and adding new components to make sure nothing breaks under load.
There are two types of scaling:
Horizontal scaling: This means adding more than one machine to do the job. For example, go from 1 to 10 servers to handle API requests from our users.
Vertical scaling: This means making our machines better by spending more money on hardware. For example, renting a computer with 4GB of memory instead of 2GB.
When we scale, we have to consider the impact on the entire system. It’s not uncommon that adding more resources in one area creates a bottleneck in another.
As we increase scale, we may also need more components to help make our backend more stable. Each step in the sequence may be able to handle a different number of maximum requests. This is where adding queues can be helpful.
If our product has any interactions with other SaaS companies, these are built on our servers as well. These integrations are built with API requests between servers, rather than between client and server.
For example, if we wanted to integrate with Google Calendar, we would send a GET requests to retrieve our user’s calendar events.
Some more common terms used in backend systems and scaling include:
Pubsub: A queue. A message is sent in to the queue (published) and one or more servers can receive it (subscribe)
EC2: A product offered by AWS to run a server (Elastic Compute Capacity)
S3: A product offered by AWS to store files (Simple Storage Service)
SQS: A product offered by AWS to run a queue (Simple Queue Service)
SES: A product offered by AWS to send emails (Simple Email Service)
Lambda: A product offered by AWS to rent a server for a very short period of time
Containers: Document everything you need to run your application in one file
Kubernetes: Deploy a container to a server and manage all your servers automatically
Batching: Grouping requests together instead of sending them one at a time
Rate limit: The maximum number of requests that can be processed in some duration
Microservice: A set of resources (server, database, queue) that are built to do a specific task, like handling billing, notifications, recommendations, etc.
Putting it all together
Understanding technical concepts isn’t about replacing engineers. You don’t need to be an expert. But it is immensely helpful for communicating with your team and managing risk.
I hope this guide helps you piece together at least one idea you’ve heard about in the past few weeks!
Good piece. Allow me to go a little farther. It’s not about PMs knowing how to code “then” they’ll feel less insecure. That won’t do it. You can learn how to code but that’s often not the value you’re bringing to the deep technical conversations about a product. And it’s not about just the basics of learning backend, frontend, etc. It’s about PMs understanding how the system works, understand the data flow design, be able to speak enough about the tech to the non-tech stakeholders (Privacy, Market Compliance, Model Governance, etc.) when the engineers aren’t in the room. It’s understanding the failure modes. Systems thinking.
I love the topic because it’s something that resonates - bit confused on the relationship of docker, Server, Kubernetes’s - and then from there VM and VPS