I recently wrote about how many tech companies struggle to turn awareness into demand because of an unclear value proposition. A very useful approach to solving this problem is to create a library of use cases, with each use case showing—very clearly and in language your prospects recognize and relate to—how whatever it is that you sell solves a business problem.

And wouldn’t you know it—we recently had the pleasure of helping SSIMWAVE create such a use case library. I want to share the process, in the hope that it helps you in your own initiatives.

Background and Project Objective

SSIMWAVE is a recognized technology leader in the video production and delivery industry: they’ve won a Primetime Engineering Emmy for their Viewer Experience metric—SSIMPLUS—they’ve gained certification from Dolby Vision, and they’re recognized by the American Society of Cinematographers. Plus, the academic foundation of their technology has been cited more than 60,000 times in research.

SSIMWAVE’s Chief Revenue Officer, Carlos Hernandez, reached out and explained that within a larger messaging update, they wanted to clearly showcase SSIMWAVE’s real-world practical business value.

As part of this initiative, they wanted Cromulent to help create a library of use cases to link the specific business problems their prospects faced to SSIMWAVE’s own solutions.

After meeting with Carlos and SSIMWAVE’s Marketing Manager, Maria Alexandrova, we agreed that the Cromulent Marketing deliverables would consist of a collection of use case infosheets, grouped into different use case families, suitable for digital distribution (e.g., web, email) and printing. Cromulent would handle all writing, graphics, design, including facilitation of brainstorming sessions with the SSIMWAVE team.

To ensure message consistency and to maximize utility, Maria would repurpose these use case infosheets into web copy, presentation material, campaign messaging, and other resources.

Seeking to Understand

I was broadly familiar with SSIMWAVE (a dozen or more of my former colleagues work there) but didn’t know any details, so I really needed to understand what they did, why it mattered, and to whom it mattered.

To effectively show how technology can solve a problem—and to accurately explain why a particular technology is better-suited than alternatives—it’s important to understand how that technology works (not to do too much horn-tootin’, but Cromulent really excels in this regard).

We started off this use case project by having a few in-depth discussions with Carlos Bacquet, a Solution Architect. We got right into the details, including particular algorithms, whiteboarding architectures, examining trade-offs, playing with demos, exploring the roadmap, discussing alternative approaches—you get the idea. My goal at this stage was to really, truly understand what SSIMWAVE does and, to a fairly detailed extent, how they do it.

Fortunately, I was well-positioned for these crash-courses, as I have extensive experience with telecommunications technology marketing and—as luck would have it—I was concurrently writing a paper on video encoding for another client.

Next, we met a few times as a group—usually just Carlos B, Carlos H, Maria, and myself, but also occasionally joined by others—so that I could understand the real-world value.

• Why does all that technology matter? What business problem does it solve?
• To whom does it matter? What titles? In what departments? In what companies? In what industry segments?

An Outsider’s Perspective and the Power of “So What?”

Two powerful assets in these conversations are:

• My outsider perspective
• My willingness to ask “So what?”

Being an outsider, I can naively ask lots of questions and challenge all sorts of assumptions that people and organizations don’t even realize they have. What seems obvious, or a given, to them might be alien and peculiar to me.

And asking “So what?” to a very annoying degree is a great way to get to the ground truth of why something matters—why it has business value.

Thankfully, everyone was very patient with me and took care to explain things in great detail—no matter how basic or how deep the answer had to be, and regardless of whether it was about SSIMWAVE’s technology, industry technology and processes, terminology, the big and small differences between all the players in the video ecosystem, etc. I’m very grateful to have been able to tap into this domain knowledge!

Getting Right to the Heart of the Matter: Showing Value

Use cases have to clearly communicate why what you do is valuable. Typically, that means a use case needs to show how what you do helps your prospect:

• Save money: Reduce the amount they spend (whether in capital or operational outlays) on something (a process, a solution—and so on), without unacceptably compromising their existing results and/or without introducing an unappealingly large burden of additional complexity
• Make money: Increase their returns by allowing them to do something new (and presumably valuable) or to improve their efficiency with some existing and sufficiently valuable activity
• Solve a known problem / address a known need: Permit them to do something which they need to do (for example, gain a crucial set of data or piece of information, comply with a regulation, and so on—maybe they don’t want to, necessarily, but they need to)

An all-too-common, but much weaker, value proposition is to help them learn about something. Why is it weaker? Because if the value was clear to them already, then it would really be in the “solve a problem” bucket; instead, you need to expend time and energy educating the prospect as to why this information you can provide is valuable (even though they, as experts, have so far failed to recognize the value).

In my experience, the underlying cause of why many companies struggle to convey their value proposition is the simple and devastating truth that those same companies don’t truly understand their value proposition. They’re often on the right track, but too frequently they stop short, relying on prospects to connect dots or assuming that value is clear when there are still layers to be pulled back.

Until I was satisfied that I, as an outsider, understood the real business value and could explain it to someone unfamiliar with SSIMWAVE and the wider industry, I’d just ask “So what?” (or some variation, to avoid being too annoying). I like to think that this incessant questioning helped us all to better understand the real value.

Producing the Use Case Library

Before engaging with Cromulent, SSIMWAVE had explored their solutions and determined that they could reasonably claim to have around a dozen entries in their use case library. To help convey those use cases without overwhelming prospects, the plan was to split them into three families. Because of my stubborn questioning, we ended up dropping a few which were initially planned, but we replaced them with some others which were ‘discovered’ through conversation. We also stuck with three families, but the families changed in slightly nuanced ways.

After the many meetings we conducted to develop the atomic building blocks of knowledge—technology, business problems, solutions, etc.—the actual fingers-to-keyboard part of the project was pretty straightforward.

I wrote out content for each use case, including:

• an action-oriented title
• a value statement/headline
• a problem explanation
• (if applicable) an exploration of typical approaches or alternatives
• an explanation of SSIMWAVE’s solution and benefits—for some use cases this component was a features and benefits combination and for others it was more of a step-by-step explanation of how (at a high level) to execute the use case
• a diagram showing where SSIMWAVE’s solution fits into the prospect’s existing video delivery workflow

(I also drafted similar content for each of the three use case families.)

True story! As a starting point, I used our very own Use Case Library template document, which you can find on our Resources page.

Once this content was reviewed by the SSIMWAVE team for messaging alignment, appropriate use of terminology, language familiar to prospects, and technical accuracy, we iterated a few times to tighten it as much as possible.

This content became the front page of each use case infosheet.

The front pages all follow the same basic layout (see the collage at the top of the page), with small differences based upon content length, the diagram, and other unique characteristics. Each use case family had its own colour scheme, reflected subtly in design touches (again, the collage shows what I mean), while staying true to the sleek look of SSIMWAVE’s existing material and website. My idea here was that if all the infosheets were tossed onto the floor, without knowing the specifics any casual observer could see that certain ones grouped together. A small touch, but a nice one in my view.

We elected to go with a common back page for each infosheet, focused on creating differentiation versus perceived alternatives by providing an overview of SSIMWAVE’s technology.

My thinking was that the front page would show how a solution like SSIMWAVE’s (an accurate video quality score) could be used to solve a business problem, and then the back page strongly showed that SSIMWAVE’s technology is the best implementation of a video quality score. SSIMWAVE’s technology can be a bit overwhelming, so I wanted to really distill it down into a clear, understandable explanation which anticipates and answers prospects’ questions, while also creating some separation from perceived alternatives.

Putting the Use Cases to Work

The use case infosheets serve as convenient resources to send ahead of meetings and as follow-ups to conversations.

Plus, as planned, Maria has put the use cases to work on the SSIMWAVE website…

…and within some ongoing campaigns (check out SSIMWAVE’s LinkedIn page).

Summarizing the Process

Readers of this site know that I like to be thorough; by explaining the process involved in creating valuable marketing content, I hope to show that there’s no quick-fix or short-cut. Nevertheless, I know that readers like handy-dandy summaries, so if you’re embarking on creating your own use case library then here’s what I recommend:

• Really, truly understand what you do, from a technical and almost thermodynamic level: you won’t be able to compare your own solution to alternatives or to understand how it solves problems unless you get into the details
• Don’t stop ‘til you value-prop: Ask “So what?” until you really, truly understand why what you do is valuable (and to whom)—don’t stop until you know how what you do helps someone save money, make money, solve a known problem / address a known need (or, much more weakly, learn about something)

Only when you’ve satisfied those two needs can you get organized:

• Identify all the distinct business problems you solve: these become your use cases (and yes, sometimes you’ll have more than one way of delivering a value proposition…but now we’re getting into more complex library structure and navigation)
• If you’ve got more than, say, 5 or 6 use cases, then see if you can separate them into use case families based on some characteristic: for example, short-term and long-term, or capex savings vs opex reduction, or small efficiency gains vs large-scale new ways of doing something—every situation is different, so I’m not going to recommend some one-model-fits-all approach

Now you can write them up! I recommend an action-oriented title and using a clear value statement as the subheading. You’ll also likely want to:

• summarize the problem (both to show that you understand it and to establish a common understanding of the situation)
• acknowledge alternative approaches (while maybe pointing out their limitations)
• clearly explain the benefits of your approach
• highlight why your implementation of your approach is best (because others might have gone about solving the problem in a similar way, and you need to start differentiating!)

Note: if you’re super-duper interested in creating a use case library, then you might also want to check out this post about how we helped develop a full solution and use case library for Bridgit.