How I use anti-use cases to set clear product expectations

A disconnect between what my product team ships and what our wider sales/marketing teams think we shipped is a huge deal.

If marketing doesn't know what our product can do, how can they market it? If sales don't know the limitations of our features, how can they pitch them?

While there isn’t a single fix to this challenge, one of the unlocks for me has been introducing anti-use cases.

Here's how I use anti-use cases to align our teams.

First, what are use cases?

Before we talk about anti-anything, let's quickly cover use cases.

I like Reforge's definition:

Use cases are an articulation of the problems our product is solving and who it is solving them for.

In the same post, Reforge share these two handy use case examples for Pinterest:

Use case example by Reforge

Hopefully, it is immediately clear how useful use cases are. They help:

• align teams,

• understand user problems,

• understand user behaviour,

• prioritise enhancements (or features),

And more.

So what are anti-use cases?

To no one's surprise, anti-use cases are... the exact opposite:

Anti-use cases are an articulation of the problems our product is not trying to solve and who it is not trying to solve them for.

Using Pinterest again, I can extrapolate the following problem:

• I need a bespoke home design for my living room.

Pinterest may want to avoid this use case. Solving it would require a new set of features, bespoke account managers, image recognition, 3D renders, etc. So, Pinterest might make this an anti-use case to say "We are not trying to solve this problem".

This clarifies communication. As PMs, we have intimate knowledge of our platform, its capabilities, and our overall product strategy.

But everyone else might not.

With anti-use cases, we can provide further context to our fellow marketing and sales colleagues: This is what we do. This is what don't do.

The exciting new tech trap (and how anti-use cases help)

My intuition is the more buzzword-y the tech, the more valuable anti-use cases are.

Let's say we're working on a no-code website builder and our use cases are:

1. I need to build a one-page website for my small business.

2. I have no design or coding skills and need to build a website.

Great. We know who our product is for.

But wait.

Jimmy from sales comes strutting towards your desk. He just closed the Bank of England as a new customer. Champagne all around!

"Oh, by the way," he says, "they need":

• Nine categories around markets, education, financial stability, and more.

• To publish ~1,000 new articles per year.

• A page with a dynamic list of events pulled from their database.

• A page to promote their museum & book tours.

• 24/7 SLA & ISO27001 certification.

"We have a no-code website builder, right? They have no design or technical skills, so they're perfect for our use case #2!"

Hopefully, you see where I'm going with this.

An anti-use case here would have helped:

• I need to build a website with over 100 pages, a blog, and an e-commerce functionality without a single line of code.

While this problem is valid, this isn’t something our imaginary no-code builder wants to be able to handle.

By the way, this is particularly relevant for all the shiny new ✨powered by AI✨ products. Remember: the more buzzword-y, the more valuable anti-use cases are.

How I use anti-use cases

Here are four tactical ways I apply anti-use cases with my product:

1. Strategic initiative documents. This is the level between product strategy & PRDs. As I define the use cases for a feature, I also define anti-use cases.

2. GTM briefs. I add anti-use cases to my SPACER (under Abilities/Limitations). This is important as marketing & sales will run with this document.

3. Internal product training. When I'm hosting an internal training session on a specific feature, I'll include a section on anti-use cases.

4. Keep an ear out and communicate immediately. If I repeatedly hear people misinterpret the capabilities of a feature, I flag it and write an anti-use case.

You won't need anti-use cases for every new feature. Sometimes the use cases are clear enough.

But communicating clear product expectations is incredibly important this responsibility sits with product.