Dear Strategy:
“When studying a competitor, how do you really determine the use case for their product?”
I’ll give a little warning up front… the ultimate answer to this question is not going to be groundbreaking. But I didn’t choose it for its simplicity (even though, yes, writing these blogs each week can get a bit exhausting). Instead, I chose this question because I think there may be some misconception about the use of the term “use case,” and I wanted to take this opportunity to clear things up for all of the non-software people out there.
Business terminology is a funny thing. Corporate terms and catchphrases get thrown about from leader to leader, consultant to consultant, and company to company; many times without any real reference to, or knowledge of, their original context or meaning. And through it all, sources are forgotten, definitions are distorted, and interpretations start to run amok over time.
As an example, I can remember, for years, using the term “strategic objectives” synonymously with the term “strategic initiatives,” simply because that’s how I had been taught throughout my corporate career. It wasn’t until I actually researched these terms for the strategy book that I wrote, when I actually realized they had two very different meanings – with “objectives” being the measurable goals you want to achieve, and “initiatives” being the way you intend to achieve them. The point is, these catchy little business terms naturally tend to become confused over time, so it’s always nice when we can take the opportunity to reconcile our understandings and get on the same page when we’re trying to communicate with one another.
Such is the case, as it were, with the term “use case.” Growing up in a career that was centered mostly on tangible products, I had always heard this term used somewhat synonymously with the term “business case,” albeit as seen more from a customer perspective. In other words, “why would a customer use a given product?” In fact, as I would come to learn over time, the term “use case” has its roots firmly planted in the software (i.e. non-tangible product) space and, as it turns out, I and many of my colleagues had been using this term in entirely the wrong context. Or at least wrong to much of the rest of the world’s understanding!
What a use case is supposed to refer to is the way in which one or more individuals or entities (typically called “actors”) would expect to interact with one another within the context of a system. For example, I as a banking customer (Actor #1), expect to interact with my bank (Actor #2) through some type of a banking app (System). All of the different ways that I would expect to interact become individual use cases, which can then be translated into user requirements and a system architecture that can fulfill my needs as a customer. So, my expectations to be able to check balances, deposit checks, contact customer service, etc., all become individual use cases that can then be used to help the bank design a system that will ultimately accommodate all of my needs. Back when I was growing up as a programmer (yes, I actually did program at one point in my life), I was taught that one of my primary jobs was to “outthink the user.” Although I didn’t know it at the time, what I was actually being taught was to develop use cases that would allow me to anticipate what users would expect to do, and then use that information to design a system that would allow them to do it.
“…what a use case is supposed to refer to is the way in which one or more individuals or entities would expect to interact with one another within the context of a system.“
So, back to the question at hand. The reason I wanted to clarify the definition of a “use case” is because I’m not completely convinced that this term is being used in exactly the right way within the context of this question. When thinking about determining competitive use cases, unless I’m missing something, it should be as easy as using their products and observing what functions their systems perform. You can then put together a use case diagram and, if you’re so inclined, make sure that your system covers all of the same bases (and hopefully even more).
But my guess is that this question is not actually referring to use cases in that context at all. My guess is that this question is asking more about understanding why a customer uses your competitor’s product (in the more general sense), rather than how specifically they expect to use it. And just in case my interpretation is correct, let me answer from that direction as well…
If you want to understand why a customer does something, the best thing to do is to simply ask them. Part of a thorough competitive analysis is to not only study your competitors’ products, but also to study their customers. Ask them what they like and what they don’t like. Ask them why they buy what they buy and what might cause them to buy something different. Be careful not to dig into anything confidential, of course, or make anyone feel uncomfortable. But asking users to provide an honest comparison of your products to those of your competitors is completely fair game and, at least in my opinion, should be an integral part of any standard competitive intelligence program.
And, of course, if I misinterpreted the use case for the use of the term “use case,” then my answer is to simply become a user of your competitors’ products so you can learn how to use their products using the use case that they originally intended.
It’s really as simple as that…
Listen to the podcast episode
Dear Strategy: Episode 069
###
Are you interested in strategy workshops for your product, marketing, or business managers? If so, please be sure to visit Strategy Generation Company by clicking the link below:
Bob Caporale is the founder of Strategy Generation Company, the author of Creative Strategy Generation and the host of the Dear Strategy podcast. You can learn more about his work by visiting bobcaporale.com.
