A detailed glossary of technical terms for new product managers

Resources for product managers Tools and pro-tips
, ,
1

Here’s a detailed list of technical terms for new product managers. Things to know to work with engineers with confidence.

I am aware that fresh PMs with non-engineering backgrounds may find the use of technical jargon to be a little intimidating. I believe that this should cover “80/20” of the information a software PM has to be aware of. Please leave a comment below if I’ve missed anything so I can update this list.

API:
Think of a power outlet. It’s an “interface” that lets you draw power from the electrical system. An API (application programming interface) is an interface that allows user interfaces to fetch/save data and process commands for an application. E.g. The Gmail API allows you to send an email on behalf of an account so different email clients can use this functionality.

build pipeline:
a digital conveyor belt where code gets built into an application and tested for quality assurance before publishing it and making it live for users

architecture:
the technical design behind a system that uses a specific set of technologies and trade-offs to achieve a particular user experience

backend:
The set of technologies of an application that are non-user facing. It processes commands and queries for a user interface.

Branches:
Allow engineers to work on different areas of application code without impacting the main branch.

bug:
An instance where the code is not working as expected

client side:
Any code that runs on the browser. All user interface code like buttons and screens run “client side” on a browser. Client side code will have limited processing power depending on the user’s laptop specs.

cloud service provider:
They provide engineers technologies to build applications like servers and databases. Engineers use them because running and maintaining physical hardware for these technologies is costly and tedious. Popular ones are Amazon Web Services (AWS) Google Cloud (GPC) and Microsoft Azure (Azure).

deployment:
When a new version of the application/code gets published.

environment:
Separate versions of the same app that get published to different URLs. A production environment is the version that’s available for users. A staging or test environment is where the app gets tested before being published to users. Local or development environment is the version of the app that an engineer tests on their computer before publishing it to staging and production.

feature flag
:a switch in a code base that allows a product team to turn access for a feature on or off for a selected number of users. E.g. features are published “behind” a feature flag for a group of users for beta testing.

framework:
A common collection of code that engineers will use to build an application quickly. If engineers didn’t use frameworks, they would have to build tools from scratch. It would be a bit like a house builder manufacturing hammers and nails from scratch every time before building a house.

front end:
The part of the app that is user facing that the user directly interacts containing screens and buttons.

Git:
A version control tool engineers use to save and merge different version of the same codebase. It’s a bit like if a group of PMs were editing the same doc at the same time. You would need a tool to reconcile the conflicts and differences.

Github:
Google docs for engineers. Where the team commonly publishes and download their code.

infrastructure:
the lego blocks for building products like severs, databases, storage etc.

logs (logging):
Information that your app generates about its behaviour like how many bugs it’s experiencing or how fast or slow the app is

Pull request (PR):
A way for your developers to submit code to a repository for review before merging it.

refactoring:
When some messy or incoherent code gets tidied up so it’s more comprehensible without changing the app’s core functionality

release:
when a deployment (a new version of the app) is made available to users

repository:
A folder in github containing code for an application. E.g a “repo” for front end and backend

server:
A computer that will contain the code for a website or application and process requests for users using browsers

technical debt:
When there is a bunch of code that is janky in functionality or has a sub optimal design or messy to read and comprehend. Engineers “pay down” tech debt otherwise the code becomes too unruly to make changes easily without inadvertently breaking things

unit testing:
Automated tests that engineers write to verify the app works as expected. This allows you to know something isn’t broken quickly without manually testing the interactions yourself

Was there any tech jargon early in your PM career that you felt too awkward or scared to ask about?

12 Likes
2

I have been in Tech PM world for 2 years. While I know all these… and so many other terms I wish I didn’t most of which come from marketing people’s word if the day calendar, I would have loved this when I started.

Great list.

12 Likes
3

It’s a good list you have, quick and dirty! I’d maybe add a few to the mix as good ones to have too:

  • cache
  • research spike
  • go-no-go
  • logging
11 Likes
4

@AngieGoodwin, That’s a great idea, will add these. Thanks!

11 Likes
5

Instead of focusing on AWS maybe talk about what a cloud service provider is and then use AWS as an example. Not all teams use AWS. There is also Google Cloud (GPC) and Microsoft Azure (Azure). Many more, but those are just behind AWS in terms of popularity amongst enterprises.

Logs: System-generated information about your applications behaviours. These can be related to system events and errors.

Runtime: The execution of code in an environment and calling compute resources to run it.

Continuous Integration/Continuous Delivery (CI/CD): Automation for your development teams for code changes and deployment.

Pull request (PR): A way for your developers to submit code to a repository for review before merging it.

Branches: Allow developers to work on different areas of application code without impacting the main branch.

Should also probably embellish on the differences between main/master and feature branches.

10 Likes
6

@DhirajMehta, Excellent feedback. I agree, makes more sense to describe cloud providers in general.

9 Likes
7

“Bug: a fault, error, or flaw in the app.”

No. Please edit.

A bug is specifically: code not executing as intended.

This does NOT include design changes, things stakeholders forgot or misinterpretations.

10 Likes
8

@YuriRoman, if you suggest that the problem was with the code rather than how you expressed the request, you risk offending a developer.

New PMs must argue whether the development team should have reasonably interpreted the requirements differently.

10 Likes
9

Well, it has other implications as well depending how toxic and org is and the metrics, they use to measure performance.

9 Likes
10

As the voice of the customer, it’s not always a meaningful distinction.

If the intent of a product is to turn a picture from yellow to blue, but the customer thinks it looks more teal than blue, then from the customer perspective, the application is not behaving as expected and this is a bug. How you resolve it from the company-perspective (bug fix, enhancement, etc) is not meaningful to the customer, just that the output they see is blue, or that the documentation reflects that the color code is #008080.

For my money, a high-performing team focuses on customer impacts and is less bogged down by quibbling on definitions.

9 Likes
11

@AmyWalker, so this isn’t a distinction. It’s a technical fact.

You don’t need to joust with customers, but you DO need to make sure management knows the difference between a code problem and a discovery miss.

Especially when too many PMs POs and BAs blame their shortfalls on engineering.

9 Likes
12

@YuriRoman, totally with you there. Context matters.

9 Likes
13

At my company we use the following internal definitions:

Bug: something is not working as intended or not following agreed upon spec.

Request: something that someone (could be a customer, could be internal staff, etc.) wishes worked differently than it currently does, even if the implementation was in accordance with the agreed upon specs.

These definitions were put forth by our engineers and allows there to be clarity re: whether something is the engineers mistake or not.

7 Likes
14

I like your definition better actually. Will update, thanks!

6 Likes
15

@AngelaBlue, Well, it’s not mine. It’s just the base actual definition :slight_smile:

6 Likes
16

100%. I see so many “bugs” that are really UX/design misses or people not liking how something works. I introduced a triage process that cut our bug backlog down 30-40%, reducing developer work, reducing “bug fixes” that are really design or product feedback that would otherwise never be seen by anyone other than the developers.

5 Likes
17

A few addons to the list:

  • Cron job - a piece of code that runs on a regular time interval

  • UAT: User Acceptance Testing

  • SME’s: Subject Matter Experts or Small Medium Enterprises

Hope these are helpful as well.

4 Likes
18

Release should always come after deployment. A release is something that is made available to the final consumer or target market. Something is published or staged during a deployment so that it can be used by everyone. Deployment is an internal (tech team) release, and a release is the real end user release, to put it crudely.

3 Likes
19

comprehensive
Incomplete and/or lacking in detail.

On a serious note, this is actually a really good starting point for new Associate PMs who, contrary to what some of us think should happen, come straight out of university with a degree in English or something.

2 Likes
20

Haha hmmm yeah comprehensive wasn’t the right word for it… I meant to say like “the almost complete high-level guide” implying there’s a ton of definitions but not all.

But to be fair, I was pretty blazed when I wrote this.

1 Like