When I first entered into the product management and software development industry, something that frustrated me was a lack of documentation from product managers, to product managers, on how to understand the way software is built.
There is a tendency for product managers to have worked as software engineers in their past careers. That is not my experience, so learning what I needed to know tech wise took some work.
Fortunately, it turns out that most of the best characteristics of being a product manager really have nothing to do with engineering (a topic for another time). However, speaking the language of technology is still vital to success. You need to have the vernacular to keep up with the people you work with, and in product development, a majority of the time that means software engineers.
There is an endless amount of things to know. As someone who struggled at first to find the information I needed to learn, I feel I owe it to prospective product managers to provide some insight and documentation on common and useful software concepts. I’ll be using writing a cookbook as the primary analogy:
Repository: A repository is like the bookshelf in a library. Repositories are organized by the different functions that the code has, so for example you may have a bookshelf for repeating actions (jobs), each application, your backend code, or your frontend code. Depending on the company and product, this is broken down differently.
Branches: These are like chapters in a cookbook. There is a master branch, which is like the current version of the cookbook. It’s out in bookstores, being used by many happy chefs. But let’s say you want to update a chapter because you have discovered a new recipe for macaroni and cheese. Then, you would need to take a copy of the current chapter, edit it, and then put it back in the book, making sure it still makes sense with the rest of the book. This is what it means to have a code branch - an engineer might use their branch to experiment with something different, using the master branch (current version of the book) as their point of truth and latest version.
Staging environment: This is like a preview of the new version of the cookbook. It’s a place to practice and make sure the new chapter looks good. It allows friends and family to take a peek and make sure the rest of the book still reads okay.
Pull Requests: Ok, you are done with your edited chapter of the book. But you need an editor to make sure that when it gets added back into the new cookbook, it doesn’t completely contradict anything (breaking code). So you make a pull request to have your updated version reviewed for incorporation.
Merging: This is related to pull requests. After the chapter has been reviewed, it has to be added to the book directly.
Commits: Commits are done by developers the way a writer might click “save” in a word document to move their work forward.
Issues/Tasks: Most development is broken down into small components, called either issues or tasks, depending on the software you use (Github vs. Jira). So this is like breaking down your chapter into an outline, and then accomplishing parts of that outline for your chapter in chunks at a time, instead of writing the whole thing at once.
QA: This is like fact checking your chapter. You make sure that nothing you have written contradicts anything that already exists or is just factually wrong. This usually is done by developers after the code has been written.
Acceptance: Sometimes called user acceptance testing (UAT), this asks the question of - does the code meet the user need? Does this chapter on macaroni and cheese actually tell the right story and give the right information about how to make the best noodles? This is usually done by product managers or other business stakeholders to confirm that the code written makes sense for how it will be applied in the real world.
Servers: This is like a writer’s brain. It is where all the important information about a software is stored. There are cloud servers, like Amazon Web Services (AWS), or companies might own their own, real brick and mortar servers (that often live on server farms).
Cron Jobs: This is like a writer’s editor, checking in at the same time everyday to see how progress is going. Essentially, jobs are recurring processes.
Databases: This is like a writer’s vocabulary and wisdom about cooking. Behind most software, there is a database, which stores all information coming into and out of the software. For example, if you sign up for a service on a website, you can bet that data is being stored in a database, so that it can be called upon for other tasks (emailing you marketing, setting up your billing information, and so on). Many databases are relational and written in a SQL language (MySQL, PostgreSQL). The most important thing to know about relational databases is that a primary key links to a foreign key - kind of like an index in a book, if you have one piece of information in one table that you want to understand to another piece of information in another table, you use the relationship between primary and foreign keys to link those pieces of information.
If you are a product manager, what else would you add to this list?