By Simon Sovič, Senior Product Manager
You are in sprint planning. The tech lead mentions a race condition, the backend engineer flags a blocking dependency, and someone asks whether the new feature needs to be behind a feature flag. Everyone nods. You nod too. But half of what was said went over your head.
That knowledge gap costs you credibility, slows down conversations, and leads to miswritten requirements. This glossary covers 35 development terms you will encounter regularly as a product manager, explained in plain English with enough context to use them correctly in conversation.
Why Product Managers Need a Working Vocabulary in Development
You do not need to write code. But you do need to understand what engineers are telling you, ask informed questions, and write requirements that do not create confusion. A shared vocabulary removes friction from every interaction between product and engineering.
Many PMs treat technical conversations as a soft skill problem. It is not. It is a language problem. When you know what "idempotent" or "technical debt" actually means, you write better Product requirements documents And run tighter discovery sessions.
The terms below are grouped by category so you can absorb them in context rather than as a random list.
Agile and Process Terms
These are the words that appear in every planning meeting. Misunderstanding them leads to poorly scoped work and missed expectations.
- Sprint- A fixed time window, usually one or two weeks, during which the team commits to completing a defined set of work. Sprints create predictable delivery rhythm.
- Scrum- An agile framework that structures work into sprints, with defined rituals like daily standups, sprint planning, retrospectives, and reviews.
- Kanban- A flow-based approach to work management. Instead of fixed sprints, work items move through stages on a board (to do, in progress, done). Common in ops and support teams.
- Backlog- The prioritized list of everything the team could work on. Product managers own the product backlog. There is also a sprint backlog, which is the subset pulled into a sprint.
- Velocity- A measure of how much work a team completes in a sprint, usually tracked in story points. Useful for forecasting delivery timelines, not for comparing teams.
- Story Points- A relative unit used to estimate the effort required for a task. The number is not hours. It reflects complexity, uncertainty, and effort combined.
- User Story- A short description of a feature from the user's perspective. Format: "As a [user type], I want [action] so that [benefit]."
- Acceptance Criteria- The conditions a feature must meet for the team to consider it done. Written by the PM, agreed with engineers before development starts.
- Definition of Done (DoD)- A shared team agreement on what "done" means for any task. Includes code review, testing, documentation, and deployment steps.
- Epic- A large body of work that contains multiple user stories. Epics map to features or initiatives; stories map to individual pieces of functionality.
- Retrospective (Retro)- A team meeting at the end of each sprint to reflect on what went well, what did not, and what to change. PMs participate but do not own this meeting.
- Standup- A short daily team sync, typically 15 minutes. Each person covers what they did yesterday, what they plan today, and any blockers.
Architecture and System Design Terms
These terms come up when engineers discuss how a system is built. Understanding them helps you assess risk, estimate effort, and prioritize infrastructure work alongside feature work.
- API (Application Programming Interface)- A defined contract that allows two software systems to communicate. When your product integrates with a payment provider or analytics tool, it uses an API.
- REST- Representational State Transfer. A common style for building APIs. REST APIs use standard HTTP methods (GET, POST, PUT, DELETE) and are the default for most web services.
- Microservices- An architecture pattern where a product is built as a collection of small, independent services rather than one large application (a monolith). Each service handles one function and can be deployed independently.
- Monolith- A single, tightly coupled application where all components are bundled together. Easier to start with, harder to scale and change later.
- Database (DB)- The system that stores and retrieves data. Relational databases (SQL) store structured data in tables. Non-relational databases (NoSQL) store data in more flexible formats.
- Latency- The time it takes for a request to travel from a user's device to the server and back. High latency makes products feel slow, which directly affects user retention.
- Scalability- A system's ability to handle increased load without breaking or slowing down. Relevant when you plan features that could drive significant traffic spikes.
- Cache- Temporarily stored data that allows the system to respond faster by not re-fetching data it already has. When something shows stale data, clearing the cache is usually the first fix.
- Webhook- A way for one system to notify another in real time when something happens. Instead of constantly asking "did anything change?" (polling), the other system pushes a notification automatically.
Development Workflow Terms
These terms describe how engineers write, review, test, and ship code. Knowing them helps you understand where a feature is in its journey and what could slow it down.
- Repository (Repo)- The version-controlled folder where all code for a project lives. Engineers commit changes to the repo. GitHub, GitLab, and Bitbucket are common hosting platforms.
- Branch- A parallel version of the codebase where a developer makes changes without affecting the main code. Features are built on branches and merged in after review.
- Pull Request (PR) / Merge Request (MR)- A request from a developer to merge their branch into the main codebase. It triggers a code review process before the change is accepted.
- Code Review- The process where other engineers inspect a pull request for bugs, quality issues, and alignment with standards before it is merged.
- CI/CD (Continuous Integration / Continuous Delivery)- CI automatically tests code when it is committed. CD automatically deploys tested code to production or a staging environment. Together, they reduce the risk of shipping broken changes.
- Staging Environment- A test environment that mirrors production. Features are deployed here for QA and review before going live to real users.
- Feature Flag- A configuration switch that lets you enable or disable a feature without deploying new code. Useful for gradual rollouts, A/B tests, and instant rollbacks.
- Rollback- Reverting a deployed change to a previous stable version. When a release causes issues, a rollback is the fastest way to stop the bleeding.
- Technical Debt- Work that was deferred or done quickly that needs to be cleaned up later. It accumulates interest: the longer you wait, the more expensive it becomes to fix. PMs need to budget time for debt reduction alongside feature work.
Quality and Performance Terms
These terms surface in bug reports, post-mortems, and release decisions. They help you make informed calls about what ships and when.
- Bug- Unintended behavior in a product. Bugs are classified by severity (critical, major, minor) which helps prioritize fixes against new features.
- Race Condition- A bug that occurs when two processes try to access or modify the same resource simultaneously and the order of operations matters. Intermittent and hard to reproduce.
- Idempotent- An operation that produces the same result no matter how many times you run it. An idempotent API endpoint will not create duplicate records if called twice. Relevant when designing payment flows or form submissions.
- Regression- A bug introduced by a new change that breaks something that previously worked. Regression testing checks for this before a release ships.
- QA (Quality Assurance)- The process of systematically testing a product to find bugs before they reach users. QA can be manual (a person tests it) or automated (scripts run tests automatically).
Quick Reference Table: Terms at a Glance
| Term | Category | Why It Matters to PMs |
|---|---|---|
| Sprint | Process | Sets delivery cadence and planning rhythm |
| Backlog | Process | The PM owns and prioritizes this |
| Acceptance Criteria | Process | Defines when a feature is considered done |
| API | Architecture | Core to any integration or platform decision |
| Feature Flag | Workflow | Enables controlled rollouts and instant rollbacks |
| Technical Debt | Workflow | Must be balanced against feature delivery |
| CI/CD | Workflow | Affects how fast and safely teams can ship |
| Latency | Architecture | Directly affects user experience and retention |
| Regression | Quality | Key risk in every release decision |
| QA | Quality | Gate between development and user impact |
How Product Managers Should Use These Terms With Developers
Knowing definitions is the start. Using the language correctly in context is what builds trust with engineering teams.
A few practices that help in practice:
- Ask, do not pretend.If an engineer uses a term you do not recognize, ask what they mean in this specific context. Engineers respect PMs who ask good questions more than those who nod along and write the wrong requirements.
- Use terms in your writing.When you write tickets or specs, use precise language. "This endpoint should be idempotent" is clearer than "do not create duplicates."
- Do not use terms as decorations.Using jargon incorrectly damages credibility faster than not knowing it. If you are not sure, describe the behavior you need instead.
- Translate for stakeholders.When reporting to leadership or non-technical stakeholders, translate technical language back into impact. "We need to address technical debt in the auth service" becomes "we need two weeks to fix our login system before it starts causing outages."
Strong collaboration between product and engineering is one of the most consistent predictors of shipping quality products on time. If you want to understand what that collaboration looks like day to day, This guide on how a product manager should collaborate with developers Goes deeper into the working relationship beyond vocabulary.
Understanding technical language is also one of the Core skills that separates strong product managers from average ones. It is not about being a developer. It is about being a credible partner to your engineering team.
If you are building product skills from scratch or leading product at an early-stage company, the Product management guide for startups Covers how to set up processes that scale without slowing your team down.
FAQ
Do product managers need to know how to code?
No. Product managers do not need to write code to be effective. What you need is enough technical literacy to understand trade-offs, ask informed questions, and write requirements that engineers can act on without constant back-and-forth. Knowing the vocabulary in this glossary is a good baseline.
What is the difference between a bug and technical debt?
A bug is unintended behavior that breaks something for the user. Technical debt is intentional or accidental shortcuts in code that make the system harder to change over time. Debt does not always break anything immediately, but it slows down future development and increases the risk of bugs. Both require dedicated time in the roadmap.
What does it mean when an engineer says something is a "blocker"?
A blocker is anything that prevents a developer from progressing on their current task. It might be a dependency on another team's work, an unresolved design question, a missing API credential, or a bug in a shared service. As a product manager, unblocking your team as fast as possible is one of your most valuable contributions to delivery speed.
How should a product manager handle technical debt requests from engineers?
Treat technical debt like any other investment. Ask what the current cost is (how much does it slow down development, what is the bug risk) and what the benefit of fixing it is (how much faster will the team move, what risk does it remove). Build a case for the time needed and include debt work in sprint planning alongside features, rather than letting it pile up indefinitely.
What is a feature flag and why do product managers care about it?
A feature flag is a switch in the code that lets you turn a feature on or off without a new deployment. Product managers care because feature flags enable gradual rollouts (release to 5% of users first), A/B tests (split traffic between two versions), and instant rollbacks (turn the feature off if something goes wrong). They separate deployment from release, which gives product teams much more control over how features reach users.
Published with SuperDuperSEO