The Magic of Communicating with Developers: 7 Essential Tech Terms for Junior PMs
Do you remember your first meeting with the development team? I certainly do. We were all speaking the same language, yet I felt like I was listening to an alien jargon. I spent the entire hour nodding my head while internally panicking. When someone said, "We need to sync the API, so the backend needs to restructure the DB schema," I broke into a cold sweat thinking, 'Oh no, what am I supposed to say to that?'
But here is the truth: A Product Manager (PM) does not need to be a developer. We do not have to write the code. However, understanding the "intent" and "context" behind the words they use changes everything. Today, I want to share 7 essential tech terms that transformed my relationship with my dev team, along with the personal lessons I learned along the way.
Table of Contents
1. API: The 'Menu' between services
2. Frontend & Backend: The visible face vs. the hidden engine
3. DB (Database): The massive warehouse of our service
4. Deployment: That heart-pounding moment of going live
5. Scrum: Our daily small promises
6. MVP (Minimum Viable Product): The first step that succeeds by letting go
7. Technical Debt: Interest that must be paid back later
1. API: The 'Menu' between services
"Is that API open?"
When I first heard this, I thought an API was some grand, mysterious gate. In simple terms, think of an API as a 'waiter and a menu.' A customer (user) looks at the menu (requests data) and tells the waiter (API). The waiter then goes to the kitchen (server) and brings the food back to the table.
PM’s Perspective: This is essential when our service connects to external platforms (like Kakao Pay or Google Maps) or when internal systems exchange data.
Questions to Ask: "Is this API public?", "How long does it take to fetch the data?", "What error screen should we show if the API does not respond?"
My Thoughts: Once you understand API specifications, you can judge during the planning phase whether a feature will be easy to apply or if it'll take longer due to external dependencies.
2. Frontend & Backend: The visible face vs. the hidden engine
"This is a backend issue; we need to revise the logic."
This is the distinction between the screen where the user clicks buttons (Frontend) and the logic that calculates and processes things behind the scenes (Backend).
PM’s Perspective: You need to identify if a requested change is just a design fix or if it requires changing how the data is processed internally.
Questions to Ask: "Does this require backend logic changes, or just a UI update?", "Will this put a heavy load on the server?"
My Thoughts: Many PMs make the mistake of saying "That looks easy" just by looking at the design, only to frustrate the developers. A PM who respects the invisible workload of the backend earns the team's trust.
3. DB (Database): The massive warehouse of our service
"We might need to redesign the DB schema."
The DB is the warehouse where data is stored, and the Schema is the 'set of rules' for how that warehouse is organized.
PM’s Perspective If you want to collect new types of data, you must check if there's a "niche" in the DB to hold that information.
Questions to Ask: "Can we add this data to the existing DB structure?", "Will this affect the data retrieval speed?"
My Thoughts: In my early days, I casually asked to display the 'last login date' in addition to the 'sign-up date,' only to find out we had to restructure the entire DB. Never forget that every single piece of data comes with a technical cost.
4. Deployment: That heart-pounding moment of going live
"Can we deploy today?"
Just because a developer finished the code does not mean it's live. Deployment is the process of uploading that code to the actual server so users can see it.
PM’s Perspective: Deployment is a high-risk time when the service might experience downtime or bugs. Coordinating deployment with marketing promotions is your top priority.
Questions to Ask: "Do we have a rollback plan if things go wrong?", "Should we deploy at dawn when user traffic is smallest?"
My Thoughts: Deployment is the most nerve-wracking moment for a PM. Being there for the team with a Great job, everyone or some snacks during a late-night deployment builds incredible camaraderie.
5. Scrum: Our daily small promises
"Let's discuss that in the coming sprint."
Scrum is a framework where we set goals for short periods (usually 1–2 weeks), called Sprints, to develop quickly and iteratively.
PM’s Perspective: This is the compass that tells us where we are in the project timeline.
Questions to Ask: "What's the core goal of this sprint?", "Are there any 'blockers' stopping your progress?"
My Thoughts: Scrum isn't for surveillance; it's for comunication. When a developer** says what they’re doing today, the PM’s role is to ensure that work aligns with the businessgoals.
6. MVP (Minimum Viable Product): The first step that succeeds by letting go
"Let's go with an MVP model for this release."
If you try to include every feature, you'll never launch. An MVP is the version of a new product that allows a team to collect the maximum amount of validated learning with the least effort.
PM’s Perspective: You need the decisiveness to distinguish between 'must-haves' and 'nice-to-haves.'
Questions to Ask: "Does removing this feature hurt the core value of the service?", "What's the fastest way to test our hypothesis?"
My Thoughts: Letting go of features is the hardest job for a PM. It's much more valuable to launch a 60-point MVP on time and see market feedback than to finish a 100-point plan when it's too late.
7. Technical Debt: Interest that must be paid back later
"If we keep going like this, the technical debt will become too high."
If you write "quick and dirty" code to meet a deadline, it'll ultimately cost more (time and labor) to fix later. It’s like credit card debt with high interest.
PM’s Perspective: You must understand the long-term consequences of demanding tight deadlines.
Questions to Ask: "If we implement it this way, will it cause scalability issues later", "How much time should we allocate for refactoring in the coming sprint?"
My Thoughts: A PM who ignores technicaldebt ultimately breaks the service. When developers say they need time to "clean up the code, recognize it as a business risk management task and secure that time for them.
Closing: A PM's True Weapon is the 'Question'
More important than mastering these terms perfectly is the courage to ask when you do not know." Developers trust PMs who try to understand their language. Saying "Is my understanding correct?" or "How does this affect the business goal?" is the ultimate magic for better communication.
I hope these 7 terms make your coming meeting feel a little lighter and more confident.
What's the most frustrating part of communicating with your dev team right now? Leave a comment below, and I’ll be happy to share my thoughts based on my experience!