Guiding Customers to Well-Scoped Use Cases

“Why do you want to use Immuta?”

Although they can typically answer questions about technologies they use, the users accessing data, and the data itself, some customers struggle to answer why they want to use Immuta when they lack a clear, well-scoped use case; they don’t always know why they want Immuta.

It’s essential that we identify this confusion quickly and guide these users to specific, clear use cases to help them see the value of Immuta and know how they will be incorporating Immuta into their workflow. To help them do this, we need to add one more facet to the three categories we’ve already established from the Sample POV:

Why is data being accessed?

Examples of Poorly Defined Use Cases

Adding that additional layer sounds simple, but it can be difficult to discern customers who have good use cases for Immuta from those who don’t. To help you identify these customers, let’s look at some sample responses of customers who don’t have a good sense of their use case:

  • We want Immuta because we need data governance.
  • We want Immuta because we need to decrease our time-to-data.
  • We want Immuta because we have CCPA/GDPR regulations we have to enforce.

What patterns do you notice in the responses here?

  • most obviously: each response used the word “because.”
  • most importantly: the need described in the “because” clause is abstract (data governance) or vague/too general (e.g., decrease time-to-data, GDPR regulations)

None of these responses answer what data they’re analyzing, why they’re analyzing the data, or who is analyzing the data. Nor do the responses indicate the business value offered by the data analysis or Immuta itself (which may also indicate that they don’t have a good sense of what Immuta is or what it can concretely do).

Although Immuta does all of the things described above, if users don’t understand more specifically what they’re using Immuta for, they won’t see the value in it (or the value of adjusting their current workflow to incorporate Immuta), and it’s likely that they (and we) won’t be successful.

Examples of Well-Defined Use Cases

Let’s take a look at a few well-scoped and well-defined use case statements for contrast:

  • We want to use Immuta for masking sensitive fields in our quarterly customer surveys.
  • We want to use Immuta for enforcing differential privacy on our data in internal audit projects.

The grammatical shift from because to for is significant here, even though it’s subtle.

In these statements, all the responses in the for clause are concrete and specific, stating what data is being analyzed, how it needs to be protected (which implies who will be using the data), and why the data is being analyzed.

Guiding Customers to Better Use Cases

Although not infallible as a litmus test (since they could provide concrete examples in a “because” clause and vague, abstract examples in a “for” clause), we can use because and for as signals to identify when a customer doesn’t have a clear use case. In such instances, we need to guide customers toward for statements, like those in the examples above. Instead of asking why a customer is using Immuta, ask them what they want to use Immuta for. This small change shifts the conversation to concrete, measurable use cases, such as specific policies, projects, or technical/business use cases (e.g., differential privacy), whereas asking them why they want to use Immuta may encourage because statements, which can lead to vague, abstract, or generalized responses (e.g., data governance).

Shifting the conversation to the concrete and specific allows us, in turn, to be more specific in our guidance and demonstrations of Immuta with customers, and then we can identify potential areas of weakness/challenges early and/or to get them to value quickly.

Additional Questions to Ask

If customers still struggle articulating their use case clearly, ask specific questions, like these:

  • What projects/data/business use cases do you want to use Immuta for?
  • What data will be accessed?
  • Who will be accessing data?
  • Why is data being accessed?

Activity: Identify the Use Case

Using the checklist above as a guide, determine if the following use cases are examples of good use cases or bad use cases. For the poor use cases, what questions could you ask to guide them to better responses?