Glossary

Two sets of jargon—product and tech. Look it up, and you won't be lost in meetings.

This field is dense with jargon, but only a handful of terms come up often. Learn these few dozen and you'll follow most meetings without dropping off. The terms below are grouped by scenario, not alphabetically—the real use case is hearing a term in a meeting, then looking up which part of the work it belongs to. The phrase after each term is its practical meaning, not the official definition.

Needs and users

PRD (Product Requirements Document): a requirement written so other people can act on it—for the developer, the designer, and the tester. Persona: a one-sentence sketch of your target user—not a specific real person, but the typical representative of the kind of person you serve. Pain point: the thing that's genuinely hurting users right now; it's the reason your product exists. Scenario: when and in what context a user would reach for your feature—the part most often forgotten when writing requirements. User story: a requirement phrased as "as a [who], I want [what], so that [benefit]," which forces you to name the beneficiary. Priority: the ordering of a pile of requirements, usually by importance times urgency or by KANO tiering; an unsorted backlog is just a wish list.

Product and design

MVP (Minimum Viable Product): the smallest set of features that can test your assumption—not a stripped-down version. Prototype: a low-fidelity sketch of screens, for discussing the flow, not for looking good. Interaction: how the user and the product talk to each other—what you click, what happens, how it responds. UX (user experience): how the whole journey feels after it's done. Information architecture: how content is organized and how users find it; navigation and categories live on this layer. Usability test: having real users complete tasks and watching where they get stuck—far more reliable than clicking through it yourself, because you're not the target user. These words get mixed up a lot. Keep one rule: MVPs are for validation, prototypes are for discussion, and UX is for revisiting after launch.

Development and launch

Frontend and backend: what runs in the user's browser, and what runs on the server. API (interface): the contract between frontend and backend—you give me this, I give you that. Integration: wiring the frontend and backend together and walking through the flow; mismatched understandings of the contract surface here. Rollout (gradual release): give it to a small slice of users first, go wide only if nothing breaks. Rollback: when a launch goes wrong, revert to the previous version. Iteration: not endless tweaking—small steps, with something shipped every round. Launch (release): the moment a new version reaches users; everything before it counts as pending launch. Tracking (instrumentation): code that records user behavior inside the product; without it, you're blind the moment the product goes out. Bug: behavior that doesn't match expectations. Requirement freeze: no more requirement changes once development starts; changes start a new round. Those last two are the words you'll most often argue about with engineers.

Data and growth

Conversion rate: the share of users who move to the next step; you can measure it at every step. Retention: the share of users still around after a period—a better signal of product value than new-user acquisition. North star metric: the single number that best represents the value your product creates; the whole company watches it. A/B test: run two versions at the same time and let the data pick one. DAU/MAU: daily and monthly active users. The higher the share of monthly actives who show up daily, the stronger the habit. Funnel: drawing every step from entry to completed action, to see where users leak out. Repeat purchase rate: how soon a buyer buys again; e-commerce and subscription businesses watch it closely. Vanity metrics: numbers that look good going up, like signups; what you should actually watch are the numbers tied to money and retention.