Product Management #8: GitHub for Product Managers
If you’re a product manager who doesn’t write code, you’ve probably heard developers mention GitHub in meetings and updates. They might say things like, “It’s on GitHub,” or “Just check the pull request.” And while you nod and smile, deep down you might be thinking, “I have absolutely no idea what that means.”
You’re not alone.
If you’re a product manager who doesn’t come from a tech background, GitHub can feel like one of those things that “belongs to developers.” But here’s the truth — you don’t need to know how to code to understand GitHub. You just need someone to explain it in plain English.
First Things First: What Is GitHub?
Let’s start by clearing up one common point of confusion: Git and GitHub are not the same thing.
Git is a tool that developers use on their computers to keep track of changes in code — kind of like a save button with a time machine. It helps them save their work, go back if something breaks, and work safely without overwriting someone else’s files.
GitHub is where all of that saved work lives. It’s a website — like a shared online folder — where developers upload their code and collaborate with the rest of the team. GitHub brings Git to the cloud, adds tools for working together, and makes it easier to manage everything as a group.
If Git is the engine, GitHub is the car. One does the hard work under the hood, and the other gives you a comfortable way to drive and navigate.
So What Does GitHub Actually Do?
Let’s say your development team is working on a product — maybe it’s a mobile app or a new dashboard. Behind the scenes, they’re writing the code that makes it all run. That code has to live somewhere.
That “somewhere” is GitHub. But GitHub isn’t just storage — it’s a place where your team can:
- Save their changes
- Keep track of what’s new
- Review each other’s work
- Discuss bugs or new features
- Stay organized without sending endless emails or files
Think of GitHub like Google Drive, but for code. Instead of docs and spreadsheets, your team is saving features, fixes, and all the small building blocks of your product. And it’s all organized, versioned, and trackable.
Okay… But Why Should You Care?
Because as a product manager, your job is to guide the direction of the product. You’re the one who listens to users, decides what needs to be built next, and makes sure the work matches what the business needs.
If your developers are doing all that building inside GitHub, then GitHub is basically your window into the workshop. You may not be holding the tools, but it helps to know what’s being built, what’s done, and what’s still in progress.
You don’t need to understand the code. But you do need to understand the system your team uses to manage it.
GitHub gives you visibility, and with that, you gain clarity and control — without adding more meetings or status updates.
Let Me Explain GitHub Using a Story
Let’s pretend your team is writing a cookbook together. Everyone is in charge of different sections: one person is working on pasta, someone else is handling desserts, and someone is rewriting the vegan recipes.
Now imagine trying to manage this as a team using a single Word file — everyone emailing different versions back and forth. It would be chaos. Someone’s changes would get lost. You’d waste hours figuring out which file is the latest.
So instead, you create a system: each person works on their own copy, makes notes about what they changed, and then asks to add their section back into the master copy once they’re done.
That system is what GitHub provides. But instead of recipes, your team is working with code.
Now, Let’s Break Down the Key Parts (Still Using the Cookbook Example)
The Repository (or Repo)
The cookbook itself — the one everyone is working on — lives inside something called a repository, or “repo” for short. It’s just a digital folder. It holds everything — recipes, notes, images, formatting guidelines — all the pieces of the project.
A Branch
When someone wants to make a change, they don’t touch the main version right away. Instead, they create a branch — their own private copy where they can experiment, fix, or add things without messing up the original. This lets multiple people work at the same time without stepping on each other’s toes.
A Commit
Every time someone makes a change, they save it along with a message that explains what they did. GitHub calls that a commit. Think of it like a sticky note:
“Changed the frosting instructions — it was too sweet.”
Get Pamudi Guruge’s stories in your inbox
Join Medium for free to get updates from this writer.
These commit messages help the team know what’s been done and why.
A Pull Request (PR)
Once that person is happy with their changes, they raise their hand and say, “Hey, I’d like to add this back into the main book.” This is called a pull request — or PR. It’s not automatic. Other team members get a chance to look at the changes, make suggestions, or ask questions before anything is merged in.
People review it. They might leave comments. Someone might say: “We already have a brownie recipe — can we merge yours with that?”
Once it’s all good, it gets approved and added to the master cookbook.
An Issue
Sometimes while reviewing, you realize something’s missing — maybe a recipe left out the cooking temperature. You flag it. GitHub calls that an issue — basically a to-do or reminder. It could be about a bug, a request, or something that needs attention. You assign it, discuss it, and track its progress.
A Project Board
To keep everything organized, especially when there are a lot of issues, GitHub gives you a project board — a place where you can see what’s “To Do,” what’s “In Progress,” and what’s “Done.” It works just like a whiteboard or Trello board, giving everyone a clear sense of where things stand.
So… What Can You Do on GitHub?
You’re not writing recipes. You’re managing the entire cookbook. Here’s how GitHub can help you do your job better:
You Can Create Issues
Let’s say a client wants a new button on the mobile app. Instead of sending an email or waiting for the next meeting, just create an Issue in GitHub.
Write it like this: “Add a Save button on the mobile checkout screen.”
This helps the devs know exactly what needs doing, and it’s tracked right there in the same place where they’re working.
You Can Watch Pull Requests
When a developer says a new feature is ready, they’ll open a pull request.
You can read the description to understand what’s changed. You might leave a comment like: “Let’s rename this field to match what we promised in the UI mockups.”
You don’t have to approve anything. Just being part of the discussion helps avoid surprises later.
You Can Track Progress
Instead of pinging your tech lead 5 times a week, just look at:
- The Project Board to see what’s moving
- The Pull Requests to see what’s ready
- The Commits to see what’s changing.
This saves time and keeps you in sync with your developers — without hovering.
You Don’t Need to Code. You Just Need to Look.
There’s a misconception that GitHub is a tool only developers need to worry about. That’s not true anymore. GitHub is where the product lives while it’s being built.
If you’re managing a product, it makes sense to know what’s going on in there.
You don’t need to understand every line of code. You don’t need to learn Git commands. But you do need to know how your team is working — and GitHub gives you that insight.
Think of it like checking the kitchen during dinner service. You may not be the chef, but being present lets you lead more effectively.
So the next time someone says, “It’s in GitHub,” don’t be afraid to dive in. You’ll be surprised how much you can learn — and how much smoother your collaboration with the tech team becomes.
