SMART Use Cases
07 May 2024 » Opinion
My first post of the year, where I talk about use cases vs capabilities, has been very successful. Even last week a coworker mentioned it to me, 4 months after publishing it. The interest in this topic has kept me thinking about what else I could write about. Then I had a flash, an idea where I realized that there are certain parallelisms between SMART goals and use cases, and I am going to explore them.
SMART goals
If you do an Internet search for SMART goals, you are going to find countless results on this topic. Since I have become a part-time manager, I have personally changed the way I see goals and I always remind my reports and me to write them the SMART way:
- Specific. Generic goals are useless. If I say “I want to become a better person”, I am not setting a goal, as anything I do can make me feel better.
- Measurable. I want to be able to quantify when I have achieved my goal and document it in the goal. For example: increase sales of product XYZ by 5%.
- Achievable. I will never achieve my goals if I set the bar too high, I have to be realistic and put the bar at a level that I can reach.
- Relevant. My goals need to be relevant to me, not my parents, not the rest of society. If you do not believe in your goals, why are you running towards them?
- Time-bound. You have to set a deadline to reach your goal. Otherwise, we all know we will procrastinate.
Keep these descriptions in your mind for the rest of the post.
SMART use cases
Having understood SMART goals, I started to think: could use cases be also SMART? Should we start applying similar concepts to use cases? I have done an Internet search and there is nothing about this approach. I am going to enter unchartered waters, but I am sure it will be worth it. Come with me!
Specific
It goes without saying that use cases must be specific. Vague, unclear, generic use cases lead to poor or useless implementations. If you are a developer, I am sure you have been in situations where the customer is unsatisfied with the result of your deliverables, just because you had to make too many assumptions. If you are a marketer, for the benefit of everybody, I recommend that your use cases are as crystal clear and target something very concrete.
Let’s see a couple of examples:
- Unspecific use case: upsell from service A to service B.
- Specific use case: encourage customers using service A, who have started the registration of service B but did not finish the process, to complete the process via a personalized email reminder, with tips on how to finish the process based on where the user fell out.
By being specific in your use case, you are also defining the segment. A good use case targets a section of the population, not everybody.
Alternatively, I see some people using the word strategic instead of specific, which is also very appropriate for use cases. Maybe there is room to combine the two: strategic and specific.
Measurable
Do I really have to explain in the 21st century why a use case has to be measurable?
Even if you do not want to put a target value, you must calculate various metrics related to the use cases: number of products/services sold, revenue, attributed marketing cost, number of customers, etc. One of the main reasons why Adobe Analytics has been successful is because it focuses on these measures.
Achievable
As with a goal, you must be able to implement your use cases. For example, if your use case relies on data that you do not have, you will never succeed. This also applies to any targets the use case includes: your market studies should show what you can expect and whether you can get to the expected outcomes.
It will also help with your credibility. If you design use cases that you later implement and bring value to the company, you will be well-regarded. On the other hand, if you propose grandiose use cases that you never implement, your management will not be precisely happy.
Results-based
I am departing from relevant in this case, and using another option for the R. Yes, use cases should be relevant, but this is obvious: if my company sells software, my use cases will not focus on electric cars. On the other hand, use cases should be results-based, they should focus on getting the consumer to do something.
This concept can also be applied if the use case did not achieve the desired result, as you can then analyze why it did not. With the learnings from your analysis, you can reformulate the use case, or change some of the marketing activities.
Time/cost limited
I do not think that the concept of time-bound can be applied to use cases the same way it is applied to goals. Instead, another option for T that some authors suggest, time/cost limited, seems to be more appropriate.:
- You cannot spend infinite time implementing a use case, it needs to go live at some point.
- You have a budget for your use case, so the cost is limited to this budget.
I want to clarify that these limitations are for the implementation of the use case. Once it is running, if it is bringing a decent ROI (remember, the use case is measurable), you will want to keep it running, which will require additional time and money for its maintenance.
Final thoughts
The more I think about SMART use cases, the more I see how it makes sense. What do you think? Do you have another approach for use cases? Would you use other variations for the acronym?
Image generated by Adobe Firefly