What every product manager should be scared of not knowing about engineering: key concepts and definitions
Dealing with engineers can be daunting when you lack the domain expertise. This glossary provides the basic understanding a product manager should have of some key concepts.
If you’ve ever found yourself in a room full of engineers, missing 80% of what’s being said, you’re not alone. Don’t worry though, you don’t need an in-depth knowledge of engineering to be a good product manager. Yet, it’s helpful to have a basic understanding so you’re not drowning. It also helps you build stronger relationships with your team.
This glossary aims to provide the basic understanding a product manager should have of some key engineering concepts. I for one wish I had come across this article when my product career started. However, there will be plenty more concepts more specific to your organisation. So here’s how I suggest you go about it:
- Spend some time listening out for recurring mentions of practices, activities or services you’re not familiar with during meetings or conversations with your team.
- Make a list of those terms and, seek to build your own understanding. Google is your friend.
- Last but most importantly, ask your team! They will provide context you won’t find on Google, and they’ll appreciate the effort you’re making to learn about their work.
Development process
Pull request / Merge request
When satisfied with their code, your engineers perform a pull request / merge request. The merge is subject to a code review from the repository maintainers or code owners. They will often comment or request changes. Once sorted, the request is approved and merged into the repository.
Peer review / Code review
After a pull request an engineer other than the author of the code must review it. This peer review best practice helps maintain quality standards and may improve performance. It also mitigates risk by preventing deployment of malicious or unwanted code.
Tech debt
Product managers and engineers must sometimes agree to make tradeoffs. The team may sacrifice quality of code in order to deliver faster. The code delivered comes with limitations. It may be hard to maintain or not scalable. It will require additional work. This work is what engineers refer to as tech debt or refactoring.
Service level agreement (SLA)
Modern software applications are complex collections of services and systems communicating together. Often, third parties provide some of those systems for you. An SLA outlines the commitment the service provider has made to you. Your organisation may also have an SLA if it provides a service to others.
Testing and QA
Acceptance criteria
Product managers typically outline the conditions required for each user story to pass quality assurance. Those acceptance criteria are key. There are several ways to list them. The most common structures are Given/When/Then and Checklists.
Unit testing
“Unit testing is the testing of code to ensure that it performs the task that it is meant to perform. It tests code at the very lowest level possible — the individual methods of your classes.”
Nick Hodges perfectly described unit testing with this quote.
Test coverage
It is important to understand how much of your feature or app is covered by a given test suite. An 80% test coverage means that 80% of your source code gets executed when running the tests. A 100% test coverage is ideal, but only truly meaningful if the unit tests that make up the coverage are robust.
Regression testing
New code can interact with pre-existing code in unpredictable ways. To catch any potential issues, tests are re-run even if they have already passed. Often, your QA engineer will select the regression tests to run. Those tests are mostly automated due to the frequency at which they must run.
Test automation
There are countless tests to run with every release. To avoid having to repeatedly do this manually, engineers will automate the task. This is key for teams working in continuous delivery.
Dev Ops
Continuous integration
Teams working in continuous integration merge their code daily (or several times a day). This practice surfaces bugs sooner than with others. It also enables more automation and is a prerequisite to continuous delivery.
Continuous delivery
“Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes and experiments — into production, or into the hands of users, safely and quickly in a sustainable way.”
There is no better way to define continuous delivery than continuousdelivery.com does.
Microservices
Microservices is a type of software architecture. An application built as microservices relies on a set of small components interconnected by a network. Those can be added, modified or removed although dependencies must be considered. The main benefits of Microservices are in terms of scalability and reliability.
Docker / Docker containers
Docker is a set of products which delivers software in packages, or containers. Containers keep the software they package completely isolated. They allow for strictly codified communication. The use of docker containers is a popular choice when building microservices.
Data warehouse
Variety of data sources can make data analytics complicated. Often, organisations aggregate information from various sources into one repository. This data warehouse allows analysis of the information it holds unachievable otherwise.
Environment
An environment is a computer or server in which to run an instance of an application. When working on a feature, an engineer will work within their local environment. After that, there are a few ways things could go. Generally though, there are three types of environments: development, staging and production.
Back-End
API
Broadly speaking, an API is used when your app needs to communicate with another service. The API and its documentation determine how your app will be able to access the data held by the target service. I particularly recommend reading Perry Eising’s post on this topic.
Endpoint
Simply put, endpoints allow your app to request specific resources from an API. When a request is sent to the endpoint, a response is expected. It carries the requested digital resource. Endpoints should be listed clearly in their API documentation.
Salt
A salt is random data which is assigned to a password and which is used to hash that password. It is a method of storing passwords more secure than storing it as plaintext.
Queue
Where you’ll be standing inside Pret for your morning coffee (Covid restrictions allowing, of course). Joking aside, queues are very much what they sound like. An ordered collection of items where the oldest item is at the front and the newest at the rear. Think about your printer queue.
Stateful / Stateless
A stateful app stores data about its states from past sessions. In other words, a stateful app has the ability to remember exactly what data it held, when it changed, why and how. A stateless app on the other hand, does not store any information regarding its past states.
Script
Programming often involves repetitive, systematic tasks. In such situations, you might want your team to write a script. A well written, clear set of instructions can automate most processes and save considerable time.
Front End
Library
There is a huge amount of ready-made assets and components available out there. All packaged with standard code neatly organised. They can save front end developers a considerable amount of time as they offer a great base to build on.
Component
Libraries are collections of components. Components are individual pieces of functionality. Checkboxes, sliders, dropdowns, date input fields are all examples of components. As your product grows, make sure to put processes in place to manage your own library of components.
I must reserve a few words to apologise to any engineer reading this for the over simplification, the dumbing down of so many concepts. My intention is only to give product managers a small head start. A grasp which they can use to catch on conversations and in turn, confidently ask questions and learn.
If you’d like to keep this glossary handy, I’ve collated all those definitions in a Google Sheet which you can find below.
I’d like to thank my dear friends and former colleagues Mikhail Prosalov and Lorenzo Iannone for their help reviewing these definitions.
Disclaimer: I curated this list based on vocabulary I encountered over the years. I’d love to understand which of these might not be familiar to you. And most importantly, if there is any addition you think I should make, please do let me know.
