Use Cases vs Capabilities
14 Jan 2024 » Opinion
First post of 2024! Throughout my career at Adobe, I have seen from time to time a conflict between the two potential approaches when implementing a new technology: base it on use cases or base it on capabilities. I have a very hard time when I have to face this discussion with my customers, as I understand both sides and see the benefits of both approaches. However, the choice will have a deep impact on the future usage of the tool.
Definitions
I would like to start with the definitions. These are the definitions that I have liked the most, found somewhere in the wilderness of the Internet:
Use case
A description of a potential scenario in which a system receives an external request (such as user input) and responds to it.
Capability
The capacity to be used, treated, or developed for a specific purpose.
Let me draw your attention to two key differences between these two definitions:
- The concept of use case focuses on the end user, while a capability is centered around the technology.
- A use case is more specific, whereas a capability is more generic.
The conflict
Now that we have done the introductions, let’s go to the reason for this post, the conflict between these two approaches.
When we start the implementation of an Adobe tool, we ask the customer for their use cases. Our statement of work is usually very specific about the number of use cases and their complexity. We also have strategists and business consultants to help the customer with their use cases.
However, many customers request that we just enable the capability and that they will take care of everything else. In the case of AEP, for example, this means that the customer wants to dump all their data into AEP and decide what they want to do with it in the future. This is typical of many IT departments, but I have also heard it from the marketing team. They claim that they do not want to be constrained by a data model built only for a limited number of use cases.
As I said at the beginning, I have an issue with the conflict between the previous two paragraphs. I completely understand the customers’ request to just enable the capability and I would love to do just that. It is always a pain if you have implemented a solution for N use cases and, later, you get a new one that does not fit the existing implementation. Would it not be great if there was a generic enough implementation that supported all present and future use cases?
Some examples
To illustrate why the approach of just delivering capabilities does not work, let me share some examples.
Many years ago, I was working with a European customer. Our main stakeholder was the IT department. They wanted me to build the architecture for their Adobe Experience Cloud. This was before the Adobe Experience Platform (AEP) existed. We repeatedly asked the IT director to speak with the marketing team, but he did not allow us to do so. After many months in the project, we had made very little progress and there was zero adoption. I know that, after I left the project, there was some very limited engagement with the marketing department, which allowed us to progress only a bit.
Another example I have is a retailer who did a full AEP implementation with a partner. They just modeled AEP to mimic their internal CRM database. When they offered the capability to the business, none of the use cases the business came up with could be delivered.
For the last example, I will refer to non-Adobe technology. I wanted to showcase this other technology so that it is clear that this is not an Adobe issue. There is this popular Enterprise Resource Planner (ERP), who everybody I spoke with in the past, would tell me about the limitations of this technology and how frustrated they were. They wanted to do something and the ERP could not do it, no matter how basic the ask was. Then, I spoke with an acquaintance, who works as an implementation consultant of this technology. It turns out that, during the discovery phase, customers do not usually provide enough details about what they want, so she has to guess some parameters or use typical values. My take is that these customers think that the obvious requirements do not need to be spelled out. The end result is that the implementation often lacks features the customers are expecting.
Always start with the use cases
The Adobe consulting team has seen too many times how just enabling the capability does not work. Our collective experience has shown us that the best results are achieved when implementations are based on use cases.
If you need some munition to convince your stakeholders, here you have some ideas:
- You will have seen how I like to often start my posts with the why. Well, the use cases encapsulate this why, the reason behind the implementation. A capability has no concept of why.
- With use cases, you have a goal and it can be measured. Once a use case is delivered, it can be pushed to production and metrics can be gathered. These metrics can be used to calculate a return on the investment. It is way harder to come up with metrics for a capability and, more often than not, none exist.
- The key to the success of any new technology is adoption. We need to build what the marketing team needs and the way to articulate these needs is through use cases.
- There is always the option to expand in the future. I know that AEP is not the best tool to modify an existing implementation, but the same can be said of any complex tool.
- What is better, to have an amazing capability that nobody uses or an implementation that only caters to N use cases, but which are bringing a lot of revenue to the company?
Photo by Unseen Studio on Unsplash