PM Jargon Demystified

When I began my transition from the advocacy world into product management, I was overwhelmed by the amount of jargon I encountered. Jargon is a constant across all industries, but I had been steeped in a very different space for over a decade–so I’ve had tons to learn in a short amount of time. 

I wanted to share some of the key terms that I needed to learn during this transition, and their counterparts from my previous experience where applicable. This is a non-comprehensive glossary list based on notes I’ve taken over the past months and years. There is a wealth of information freely and publicly available to those interested in transitioning into product–some of which I link out to below. 

What other terms or concepts would you add? Let me know!

A Very Incomplete PM Glossary:

A/B testing: Presenting alternative versions of a design or feature and measuring what users respond best to; comparing two options against each other to identify the best performer.  

Acceptance criteria: What PMs and Engineers use to validate what’s built out. For example, a feature (i.e. a simple blue button) can’t get released into production until that criteria is met (i.e. text size, content, placement). 

Agile: A ubiquitous methodology for managing software development processes. Best place to understand agile is to read the short Agile Manifesto. 

Backlog: A list of work/features that isn’t currently being worked on or prioritized. If possible, you want to have a healthy/full backlog.  

Cannibalization: When two products from the same company compete with each other. Ideally avoided!

Customer validation: Often an iterative process to help inform product decisions, to ensure assumptions are validated early in the product development lifecycle. Validation should focus on the market, the problem you’re solving, and the product itself. ProductPlan has a helpful overview here.

Feature creep: Adding so many features that the value of the product itself declines. I knew of this as “scope creep” in my previous work—but this term is also used in development. Scope creep in software development impacts how quickly the dev team is able to deliver on features–something to be on the lookout for, as it can also impact morale. 

Go-to-market strategy: A detailed plan for how to execute a product release (including marketing / promotion of the product), and how to convince customers to purchase the product. 

Job To Be Done (JTBD): A great framework for articulating customer knowledge, focusing on what a customer wishes to accomplish or progress in a particular circumstance. Each JTBD lays out the situation, the motivation, and the ideal outcome. Check out this great read on replacing user stories with JTBD. 

Lean software development (LSD): This is another agile framework / approach to software development, focused on optimization of effort and resources. The Lean Startup does a great job of explaining this in further detail.  

Minimum viable product (MVP): This is related to lean software development, and is all about validating assumptions before committing to a full-fledged product. An MVP varies greatly depending on context: it could be a simple wireframe, or a partially built-out application. Again, The Lean Startup has a really helpful overview of this concept in different contexts. 

North star metric: A single critical metric that gets at the core value that your product is providing customers. For example: when Netflix was young and focused on addressing retention, their north star metric was the % of customers placing 3 or more titles in their queue during their first session on the site; read more here.

OKRs: Objectives and Key Results. A key goal management system that identifies and defines a qualitative objective (meant to inspire and rally a team) and pairs it with measurable and quantifiable results. Two great reads on OKRs are Radical Focus and Measure What Matters.

Pivot: Fairly self-explanatory. A shift in strategy or direction based on new market findings, competition, or new findings on customer needs. This concept was also used in my previous work.

Product life cycle: There are a ton of variations out there on this, and every company has its own version – but the product life cycle refers to the phases and processes needed to take a product from a concept to its launch. I like this layout of these iterative phases, which will often overlap and not necessarily occur in order. Discover→Define→Define→Design→Develop→Deliver→Debrief (and then back to discovery)

Product specs: One of the few outputs a PM is responsible for. Basically, a blueprint and key requirements for building new features, functionalities, or products. Product specs should include the problem you’re trying to solve, the goals, use cases, a timeline, and any tradeoffs. 

Retrospective: A meeting, typically at the end of a sprint, for the team to discuss what’s working, what’s not working, and any changes in practice. In my opinion, this is one of the most critical meetings (if used effectively) in the Agile process. 

RICE: This is a super helpful framework for prioritizing and assessing project ideas using four factors: reach, impact, confidence, effort. You can read more about RICE here. 

Roadmap: This is a plan of work that shows prioritization, sequencing, and rough costs. It should include steps in the process and key milestones, and helps give a sense of the scale of work. It helps give the team a baseline to track progress against, too. A long-term roadmap is helpful because it can illustrate if you’re on track to achieve goals within your timeframe–but know that it will likely change along the way. In my previous work, I would reference roadmaps as proposals.  

Scrum poker / T-shirt sizing / Fibonacci estimates: The team gives rough effort estimates for new work using an agreed-upon scale (e.g. 1 point = 1 day of dev work). If team members have wildly different estimates, that can be a conversation starter as different folks will have different and distinct context. 

Sprint: This is an agile concept that refers to the length of time to work on the latest prioritized features. Depending on the team, one sprint could be 1 week, 2 weeks, 3 weeks etc.

Story mapping: This is where you arrange different user stories (or JTBD, if you’ve replaced user stories with those) in chronological order based on when a user might engage in a particular task.

Strategy: This is a high-level document that is informed by the vision (which is how I sometimes referred to analogous outputs in my previous work), and details what the business hopes to accomplish with a particular product–and how. Strategy will help prioritization for the roadmap, and the two should be aligned.  

Technical debt: Tech debt exists in every single project – but the degree to which it’s present varies. Tech debt will increase if speed of delivery is prioritized over stability and robustness. A helpful metaphor for understanding technical debt is financial debt. For example, a line of credit will allow you to own and use an item right now, with the understanding that you’ll need to pay the full price and any accumulated interest in the future. 

Touch points: Any time a user / customer comes into contact with your product or brand. Touch points might be visualized through a customer journey map.  

Vanity metrics: These are metrics that might look great at first glance, but don’t actually translate into meaningful results. At the risk of over-referencing this book, The Lean Startup is a great place to learn more. 

Wireframe: This is a simple sketch of a website, app interface, or product layout. Check out my other blog post if you’d like to see a wireframe I created! And if you’ve ever wondered why they’re called wireframes, look no further.