Thinking in Use Cases

08 Oct 2017 » Marketing Team

In this fast-changing world we are living in, we tend to concentrate too much on the details and forget about the big picture. As, probably, many of you, I started by just thinking on how to solve the particular questions my customers had. One day, though, I had one of those enlightenment moments and I started to think in use cases instead. Let me explain you my journey until I realised how important the use cases are.

I am pretty sure most of you reading me know what a “use case” or a “user story” is. In fact, you will probably wonder why am I bringing up this topic, when it is so obvious. Well, it turns out it is not as obvious as it should be and we tend to forget about them. Until you do not really understand the big picture, your marketing efforts will not be as good as they should.

Definitions, definitions, definitions

Before proceeding with the rest of the post, I want to highlight another important detail. If you do a quick search on the Internet, you will find that there is no common definition of terms like “requirement”, “use case” and “user story”. To the contrary, you will even see contradictory definitions. For example, some people derive the requirements from the use cases, whereas others derive the use cases from the requirements. Which came first: the chicken or the egg?

I have found this wiki page very interesting and I will use it as the basis of the rest of the post.

‘User stories capture functionality and output of a system.’

‘Use cases capture the functionality, interaction as well as pre- and post conditions.’

If you prefer a different definition, just replace “use case” with your preferred expression.

Zooming in

zooming in I started my career in the “Adobe world” on client-side, implementing Adobe Analytics. That was many moons ago, when s_code H.24 was the latest release. I then moved to Adobe and continued supporting implementations. At that time, my main focus was to determine whether I needed an eVar or prop, or what code I needed to put in the doPlugins section. My clients tended to tell me directly what they wanted me to do. Only sometimes they would share with me their use cases.

A few years later, I was requested to get trained in Adobe Audience Manager. I knew nothing about display advertising, let alone DMPs. As I started to work with AAM, I learned a lot. My first customer could see I was not fully prepared in my first meeting. But my last AAM customer did not want me to leave the project. Since AAM was so new, thinking in use case became more the norm. It was still a very siloed view, though, probably mirroring my customer’s organisation.

However, now that I look back in time, I realise I did not always have the proper views. You have probably read Sir Isaac Newton’s quote “I was standing on the shoulders of giants”. Well, I was just playing around the feet of the giants and, sometimes, climbing up to the waist. My world was just the Analytics interface, eVars, props, events, ID syncs, DSPs, destinations… Do not get me wrong, I enjoyed that time, I met fantastic customers and I had my fair share of successes. But it also meant I was not focusing on the wider picture.

Zooming out

When I started the training to become a Multi Solution Architect, I had to zoom out. One of the typical challenges an MSA faces initially is how to disconnect from your previous, single-solution role. As it name implies, we need to see the full range of Adobe solutions and 3rd party products involved in a project and we need to architect a solution that caters for the clients marketing requirements. It is not only how to write JavaScript, create a trait or enable an eVar. It is how to combine all of these capabilities to deliver a solution.

With this new perspective, the language changes. Some of my stakeholders could not care less of eVars or ID syncs. What they want is a tool to do complex digital marketing campaigns.

The power of use cases

Last week I read the following tweet:

I could not agree more and it illustrates the transition from just getting a list of tasks from the customer to understanding his needs. One of the best ways to communicate between a customer and a consultant is through user stories and use cases. Let’s start with the following user story:

As a marketeer, I want to target those visitors to my website, who have abandoned their cart before purchasing, both on-site and off-site.

We are not talking about eVars, mboxes or DIL codes. The request is very clear now. It might not be easy to achieve this goal, sometimes it is impossible, but it is clear. From here, we can derive a use case, which we need to fulfil. With this in mind, we can start thinking what eVars we want to use, where to put the mboxes and whether I need the DIL code. But the important thing is that these details come later in the conversation. This applies even if your role is an implementation consultant: you should always start with the bigger picture and understand it.

Now, let’s compare the previous user story with the following request:

I want you to track every single interaction of my visitors with the e-commerce part of my website. This includes the scAdd and purchase events and the products string and I also want additional events to track the value of the cart. You should also put mboxes around all important areas of the website and connect to this list of DSPs.

I am not sure how I can start working with the previous request. Without a better understanding of what the marketeer wants to do, it is very unlikely anybody can delivery something useful.

Related Posts