There’s an overused and overloaded aphorism: words matter. Usually, this phrase is used to state that the selection of words has particular import (true). Yet to a product marketer, the definitions of those words and a company’s alignment around them is much more important. I don’t just mean the terms that you use to market your products (though I’ve had many vigorous arguments about “incident management” versus “incident response” that I’ll save for another day.) I mean the terms that you use inside your company to refer to the various parts of the kit you produce – your firm’s products and solutions. “Products” and “solutions”, though… what the heck do those terms mean, anyway?

We’re all so used to seeing “Products” and “Solutions” as tabs on corporate websites that we barely bat an eye when encountering them, and simply believe that intuitively, we know how these relate to one another and to our product features. But inside a company, we often tend to bandy about the term product to refer to not only actual products, but packaging, features, bundles of features, industry and functional solutions, etc. This imprecision leads to confusion and misalignment. It’s just like how good demand generation organizations get extremely annoyed when the term “campaign” is used to refer to any kind of revenue marketing activity (this is a topic for another day).

While I don’t profess to solve this taxonomic confusion for the entire field of marketing, I do want to share how we define these terms at PagerDuty. We do this to decrease the level of confusion when everyone’s referring to “stuff that we make” by ensuring that the terms in use have a clear level of granularity that doesn’t conflict with others. To lead off, a visual of the hierarchy:

What is…

… a Solution?

A solution has two primary senses – functional and industry (vertical). In both cases, we define a solution as a combination of one or more products and their relevant capabilities that, brought together, will help a customer successfully solve a business problem.

On an as-needed basis, a solution go-to-market is augmented by content that helps a customer achieve success with solving that problem, potentially combined with strategic partner integrations, professional services packages, and so on.

The only difference between a functional solution (for example, DevOps or DevOps Acceleration might be a solution) and a vertical one (Retail, Financial Services, etc.) is that industry solutions tend to be much more marketing-oriented, with less emphasis on actual product content and more inclusion of customer evidence and industry-specific thought leadership to explain how the projection of a set of products & capabilities onto an industry will solve problems inside that industry.

When naming or describing solutions, it’s best to use the customer’s language: commonly accepted terms for the business problem they’re trying to solve. This is often more of an art than a science, as “common terms” often result from vendors creating them, but we tend to err on the side of comprehension rather than trying to break fresh ground.

Is there a difference between a solution and a use case? This is also a matter of hot debate on our team, and depending on which way the wind is blowing, I can be convinced either way. Right now the wind is blowing east, so I’m of the mind that these are essentially the same thing, save for the fact that use cases – how customers, who are sometimes outliers, may be using your product, whether you like it or not – isn’t necessarily as comprehensive or mature as a solution, which is a commonly-accepted way to apply your product to solve an oft-seen business problem. Hence my current view that the difference is really academic.

All of the above is reflected in PagerDuty’s current website navigation under Solutions which looks like this.

… a Product?

A product is a collection of related capabilities that have been grouped together to solve a specific set of customer problems. It may, but does not necessarily, have to be synonymous with a SKU (stock-keeping unit) that you sell to customers. In our case, it is not. Products are also not features. It seems ridiculous to have to state that, but I sometimes hear individuals over-selling features by calling them products (“we have a new product” when what they mean is “we have a new feature”).

For us, products typically have short, descriptive names (one to two words), but that’s an editorial choice and I’ve also heard of other companies naming products in a more amorphous way (I’m looking at you, Akamai Aqua Ion). Where you land on the descriptive versus abstract spectrum depends on your prospects’ comfort level. More abstract product names require more explanation and risk alienating highly technical users.

You’ll notice that in PagerDuty’s website navigation, we don’t use the product name directly but rather, the language of the customer if they were to describe their problem. A customer coming to PagerDuty looking for a product to help with event management, for example, wouldn’t know that our product is called Event Intelligence. But if you click on “Intelligent Event Management”, you’ll end up on a landing page that tells you the product for that problem is Event Intelligence. “Runbook Automation” takes you to a page about Rundeck. And so on.

… a Capability?

Capabilities are a logical aggregation of product features that allow users to perform some task. I think of these more as the product marketer’s version of “jobs to be done”. The only reason these aren’t the same as features is because sometimes you need to take logical bundles of features and put them together in a SKU, and it’s nice to have a construct to refer to these bundles (and “capability bundle” is too long). This term is pretty much inside baseball, to be honest, and not really customer-facing.

… a Feature?

A feature is a distinct, discrete piece of product functionality that allows a user to complete one or more tasks or actions. We have several rules for naming these at PagerDuty, and while you may not have the same rules, I do recommend you establish some. For us, our feature names are simple, pragmatic, descriptive, easily understood by the user, not a proper noun, and favor industry standard terms if they already exist – even if 100% congruence with the industry definition is not achieved. We also try to not needlessly capitalize features; not always a fight I successfully win, but, for example, we don’t capitalize “status dashboard”, “time-based alert grouping”, “on-call scheduling”, “event rules”, and so on.

… a Package or SKU?

A SKU (or in SaaS parlance, a subscription tier) is a bundle of one or more capabilities into a package that a customer can purchase. In SaaS, it’s often common for this bundle to always include some base level product functionality (“the foundation”) whose inclusion in every SKU is implied if not called out. Note that different functional levels of a capability could appear in different packages (e.g. reporting capabilities might be more limited at lower subscription tiers than higher ones).

Conclusion

While some of these taxonomy definitions might sound extremely pedantic, I have found substantial success in using their precision to explain to a variety of stakeholders what level of cardinality I’m speaking at. This is particularly important when guiding peers in revenue marketing, as well as creative agencies, who do not know whether a label refers to a package, solution, feature, capability, etc. and risk over or underselling something by misusing a term.

No organization system can be directly applied to another company’s business – these rules are just what we’ve found to work for us, so don’t take them as gospel. But I do highly recommend establishing a similar hierarchy inside your organization to improve clarity of communication among disparate teams.