Product Management is big on jargon and acronyms rule. Lean, agile, Scrum, Kanban, PM, MVP, GTM, USP, beta, alpha, sprint, story points, backlog, grooming, retrospective, INVEST, DoR, DoD, ROI, etc. It goes on and on. “Let’s review the DoR checklist for the upcoming sprint’s backlog after today’s scrum.” Huh? “Grooming” is my favorite. Why not pruning or trimming or log-scaping?
Everyone is big on these terms, probably due to the feeling of being “in the know” and part of a skilled community as well as due to the creativity of the people involved in product management. There is also likely an aspect of using jargon to back up some of your value – similar to the world of finance. Those CDOs don’t sell themselves! And yes, there is definitely value in standardizing a glossary of terms for common and valuable processes in an agile environment where documentation is ideally kept to a minimum.
There is few other examples where, on a daily basis, a team can physically start with absolutely nothing but an idea and produce something of value. Think of all the apps and websites you rely on and use every day. Describing the processes that result in those outcomes has created these terms. However, you do not have to use them. They are not mandatory and trying to insert them into every sentence is not something I would recommend. Especially if speaking with team members or stakeholders outside of the product management sphere of influence. Tailor your speaking style to your audience. That’s a good general rule to live by.
As with most things, a comfort level and familiarity with some of the terms and acronyms can help move an idea or conversation forward as well as help you organize your processes. This in turn can help you create a consistent approach to successful product development.
Let’s get into what some of these product management terms and acronyms mean:
Lean – mindset of avoiding waste. Reviewing processes and continuously improving them for greater efficiency. Can be applied to your commute to work or making pasta or creating a new car or web application.
Agile – quickly and continuously improving by being responsive and flexible while avoiding waste. Built on the Lean mindset, Agile is a framework designed for digital product development and the idea that focus should be on interaction and deliverables that are flexible enough to take into account frequent feedback and improve or fail quickly.
SCRUM – a delivery team working on the “how” of delivering a product and applying a standardized methodology to that process of creation. Scrum is designed to be an Agile framework. The steps followed by the team allow for frequent iterations through feedback loops and methods to account for changes in task priority. Don’t fall for the process trap with Scrum. It is easy to focus on the process itself and veer away from the focus on actual value, interactions and feedback.
Kanban – an organized task list. A visual representation of tasks that need to be done, are being done and are done. A board telling a story, more on that later. Can be used standalone or with Scrum (Scrumban) to help keep the team organized and manage tasks.
PM – person memorizing and utilizing product management jargon and acronyms. Referred to as a “Product Manager” and responsible for “what” the team will be creating and “why” it is being created. PM should not be driving the “how”.
MVP – “Minimum Viable Product” is anything that helps you test a hypothesis and gather feedback so you can iterate faster and more effectively. It is a misunderstood term that should not be used. It may create a perception of a functional product. It usually is NOT a release or a functional version of your feature or product. “Minimum Viable Increment” may be a better term. It can be something as simple as a survey or email with a link that gauges interest. Another example is a button which leads to a “feature coming soon” page that measures the interest in the feature without committing you to actually developing it further. Amazon uses this test method frequently.
GTM – “How do we sell this thing?” The “go-to-market” strategy is the plan to capture a share of the marketplace and start generating value for, and from, customers and end users.
USP – the key benefit created by your product that makes it competitive in the marketplace. This benefit can be driven by a new way of doing things or an improved way of doing this. Uber for example improved on what the taxi industry was already doing for decades by adding features which created a significant convenience benefit. It is the benefit NOT the feature!
Beta – the version of your product you want a few people that know, like and trust you (supportive external stakeholders) to test as they will likely find new issues and have valuable feedback. These should be the end users of the product using it as intended in the “real” environment. It is the version after the version the internal team already tested, alpha, provided to a small group of end users that will hopefully catch anything missed as well as provide feedback about the user experience, user interface and overall usability and perceived value.
Alpha – the version of your product ready for internal testing and the first “shake down” to locate bugs and any issues with the user experience.
Scrum Master – the person supporting the Scrum team and clearing the path for them to be more effective. This includes helping them follow, maintain and update the flows and processes they agreed on as they evolve. It is not a managerial position. The “Master” refers to “mastering the processes” not the team.
Product Owner – the person taking in feedback, updates and information from a variety of sources and determining the priority of tasks by applying decision making processes and subject matter expertise. The role is intended to allow the development team to focus on the work of creation by consistently prioritizing all tasks and entering them into a queue or backlog.
Product Backlog – a list of product features to be delivered by the development team.
Sprint – usually a two week period (can be anywhere from one to four weeks) where the development team creates features prioritized for that specific period.
Feature – a valuable piece or component of the product as determined by the Product Owner and valued by the customer or end user.
Story – a description of a feature or task. A story should be clear, feasible and testable. A story is clear if all team members have a shared understanding of what it means. A story is feasible if it can be completed in one sprint, according to the “Definition of Done”. An item is testable if there is an effective way to determine if the functionality works as expected.
DoD – “Definition of Done” is a understanding by the team as to what constitutes a completed backlog story or task. This may take the form of a checklist that a completed task or feature is checked against. If not “done” the task goes back into the backlog to be redefined and reworked as needed.
DoR – “Definition of Ready” is an understanding by the team as to what constitutes an acceptable task or story for an upcoming Sprint or development time frame. This usually includes a checklist, criteria and templates that are followed in order to meet “ready” requirements. “INVEST” is one such set of criteria.
INVEST – The task or story is independent of other tasks or stories, it is negotiable and can be changed, it is valuable in terms of ROI and to the customer or end user, it is estimable in terms of its effort, it is small enough to fit within the sprint or iteration and it can be tested.
ROI – “return on investment” in terms of the effort and time dedicated to a feature or story or task and the value it will generate once completed and in use by the customer or end user (internal or external).
Story Board – often takes the form of Post-It notes on a wall or white board and is used to describe what is to be done, what is in progress and what is done. A story board must be accessible and visible by all internal team members – including if it is a digital version. Kanban is an example of a story board methodology to move items from “to-do”” to “done”.
Story Points – a standardized way to gauge a difficulty of a story or task. Each story is awarded a number of points based on the effort required to deliver it. A story that is less defined, or vague, will have more story points as more effort will be required during development to give it definition (research for example).
Grooming – organizing the backlog, including removing, or “parking”, aged or no longer relevant items, analyzing feedback, integrating lessons learnt, deciding what to do next, splitting high point value stories into smaller ones, preparing stories (is it clear, feasible and testable?)
Retrospective – the review after a sprint or boxed time interval where the development team worked on various tasks or stories. The retrospective is intended to be a session where lessons learned are noted and improvements to processes can be made. This may include how interactions are handled, story points are assigned, to DoD and DoR adjustments among many other changes.
That’s a good start, there are many more! The key is not in knowing the jargon but focusing on interactions between team members and your customers so value can be generated by working on small pieces of your product and letting it out “into the wild” as frequently as possible to help you learn and improve.
Author: Ved Nikolic