The Product Lexicon (v1)
There are a lot of terms tossed around when you work in product, and whether you’re new to the PM role or recently joined a company where they have their own interpretation, it helps to have a universal lexicon for clarity of communication.
I’m planning to reference these concepts regularly in future posts, so I figured I’d spell out my standard definitions. I may also occasionally append to this list…
Product Vision
The future state you’re trying to create / achieve by building your product, which is usually not an overnight proposition and requires a multi-year journey.
Product Strategy
The intentional steps you’ll take to achieve the product vision. Imagine there are a multitude of ways to get to the end-state vision - your product strategy is the explicit path you’ve chosen. A good product strategy serves as your decision-making framework, because you can easily answer whether a step makes sense to take (or not).
Product Principles
The manner in which you choose to build products, given all the options and alternatives, are your product principles. These can be thought of as operating guidelines meant to ensure consistency and resolve trade-offs.
Product Team
The cross-functional group on point to define / execute / iterate on a dimension of the strategy, with a PM usually on point as team leader / spokesperson. It takes multiple product teams working in concert to fulfill the product vision. Also, an organizational hierarchy of PMs is not a product team - it’s just the functional reporting structure.
Product Mission
The specific focus area (or charter) of a particular product team that is distinct and unique from other product teams. Ideally, there are clear operating lanes between product teams, because issues arise when there are overlapping (product dependencies) or abandoned (product debt) missions.
Product Goals
As a product team proceeds on its mission, there should be objectives and metrics to measure progress, which we refer to as product goals. Goals should not only have an absolute value (e.g. revenue $ or % growth) but also a time horizon (e.g. quarter or year); one key aspect of a product strategy is an understanding of the timeframe in which the vision must come to fruition, based on market trends, competitor analysis, etc.
Product Personas
The target users of your product or consumers of your service or customers of your business are represented by personas (which should be living profiles that you update as you learn). You may end up building for multiple distinct personas over time, and you may segment by sub-persona as well, but a minimum you should have a sense of who you are creating value for.
Product Use Cases
The specific, repeatable solutions to problems faced by your target personas which are addressed by your product are its use cases. The path to market fit and market share involves solving the right set of use cases to the right degree vs trying to do everything.
Product Functionality
The capabilities and features your product provides comprise its overall functionality. Ideally, 100% of a product’s functionality is geared towards use cases, but realistically you will end up building things that don’t add value or not enough value. When functionality that is of minimal value starts to put a drag on your ability to build or enhance your actual use cases, you end up with product debt. Sometimes, you end up with functionality that unintentionally solves a new use case, and you have (accidental) product innovation.
Product Patterns
A meta-grouping of use cases is referred to as a product pattern. This is common when building a horizontal product, where the same use case can be positioned across different industries, serving different but parallel personas. In these scenarios, the pattern refers to the 20% of the functionality that serves 80% of the horizontal use case, and additional functionality is built (or provided via partnership) to complete the industry- / persona- specific needs.
Product Backlog
The entirety of things you could potentially build are the product backlog. This encompasses original ideas from your team, demands from your customers, requests from prospects, bugs from users, input from partners, etc. Keeping a backlog groomed is a core part of a product team’s hygiene.
Product Roadmap
The specific deliverables that a product team chooses to address portions of the backlog are referred to as the product roadmap. A roadmap can be thought of as a sequencing and prioritization of a subset of the backlog. A roadmap should be intentional and jive with the product strategy; an ad-hoc roadmap implies a lack of clear product strategy. A roadmap should also employ repeatable tactics (via product principles) and result in meaningful outcomes (for product goals).
Product Pillars
A product with multiple facets can also be logically organized into product pillars. These come in handy on a variety of fronts - for example a product strategy can have pillars to break things down for internal alignment and a product roadmap can have pillars to chunk things up for external messaging.
What other terminology do you have in your product dictionary?
further reading / references
Reforge ties together several of these concepts in their Product Strategy Stack
this First Round Review article goes deeper into the “product strategy stack” with concrete examples
childish drawing / interpretation
