Testing user activation fit for diverse use cases

We previously have discussed how to design activation mechanisms for a particular use case. This approach involves working backwards, starting with product value and culminating with acquisition channels and landing pages.

But what about situations when a product has product/market fit for several different use cases? Users will come to the product with different jobs they want to get done. Depending on the use case, these users will have their own “aha moments”, conditions necessary for reaching that moment, and optimal paths to value.

In this article we present an algorithm for checking how well the current activation mechanisms for your product provide the shortest possible route to value, even when there are diverse use cases in play.

→ Test your product management and data skills with this free Growth Skills Assessment Test.

→ Learn data-driven product management in Simulator by GoPractice.

→ Learn growth and realize the maximum potential of your product in Product Growth Simulator.

How value is surfaced in different use cases: an algorithm

Here is a two-part algorithm for checking your activation mechanism:

1. For each use case that brings users to the product, we imagine ourselves in the role of the user.

2. We follow the CJM and analyze every step from that user’s point of view:

• Is this step necessary for reaching an “aha moment” and succeeding for this use case?

• Does the user obtain value? After this step, is the user any closer to solving their problem?

• Does this step deliver added value compared to the alternatives?

Our goal is to determine how optimal this path is at surfacing value for users who have come to the product with a particular job-to-be-done.

We’ll apply this algorithm to a mobile banking product. As we do so, we will discuss the possible product decisions that this kind of analysis might inspire.

Case study: a mobile banking product

You’re working on a next-generation mobile bank.

The product has two key jobs-to-be-done that bring users to the product:

1. Using a debit card to pay for online purchases.

• The card’s added value comes from security (clients put only a limited amount of money on the account linked to the card) and cashback (they receive back a percentage of every purchase).

• About 80% of new users come to the product for this use case.

2. Getting a credit card to cover everyday expenses.

• The added value comes from the bank’s quick credit decision as well as favorable terms.

• About 20% of new users come to the product for this use case.

The banking product has other use cases with product/market fit, but they are complementary to the two key use cases just mentioned.

New users select this particular bank because of the value offered for those two use cases. That’s why we’ll focus on them when reviewing activation mechanisms.

Current product activation mechanism

When designing activation, the team focused on the most common use case: getting a debit card for making online purchases. By following the approach described in this article, they arrived at the following mechanism for onboarding users:

[Hi-res image]

Activation analysis for different mobile bank use cases

Now we refer to the product’s CJM to see how the flow looks for users coming to the product with different jobs-to-be-done.

Here is how we would do this for our mobile bank example.

Use Case #1: Getting a debit card to make online purchases

[Hi-res image]

• User logs in with their phone number. This is a necessary step on the value path: it lets them start using the app.
• User provides personal information that the bank needs. This step is also necessary.
• User is asked whether they want a debit card. This effectively articulates value because, for this use case, the user came to get precisely this card.
• User reviews the bank’s terms and conditions for the debit card. This step is necessary due to legal requirements.
• User selects a bonus category for cashback. This step articulates value because cashback is one of the main reasons people want this card for making online purchases. Even if the user didn’t know about this feature, they will probably be happy to see it.
• User confirms the information entered so far. This step is necessary for both the bank and the user, in order to avoid errors and inconveniences later.
• Bank verifies the user’s card application, which may take some time. This step is necessary because the bank cannot issue a card without performing checks.
• When the card has been approved, the user immediately receives a virtual card and can start making purchases right away. Processing starts for production of the physical card.
• User selects when and where to have the card delivered. Delivery also provides value, since it saves time by avoiding the need to visit a brick-and-mortar branch.
• The card is delivered.
• Now besides the virtual card, the user can use the regular physical (plastic) card to make purchases.

We can conclude that, for this use case, the CJM is straightforward and effective. The user receives the card they want and can even start using their secure virtual card and earning extra cash in their bonus category without waiting for the physical card to arrive. On top of all this, the user receives the card in a way convenient for them.

Use Case #2: Getting a credit card to cover everyday expenses

The same acquisition channels are at work as in the previous use case. The difference is that the triggers and contexts causing the need for this banking product (i.e., favorable credit terms with the ability to cover everyday expenses) have not been included in the activation flow. Let’s look step by step:

[Hi-res image]

• The first step is like in the other use case. User logs in with their phone number. This is a necessary step on the value path that lets them start using the app.
• The second step is also the same. User provides personal information that the bank needs. This step is necessary.
• User is asked whether they want a debit card. This step does not lead to value, since the user wants to receive a different type of card.
• User reviews the bank’s terms and conditions for the debit card. This step is necessary for receiving a debit card. It does not lead to value since it forces the user to perform actions unrelated to the card they actually want.
• User selects a bonus category for cashback. This step does a good job of surfacing value for the debit card, but unfortunately it does not lead to value in the credit card scenario.
• User confirms the information entered so far. This is another unneeded step that takes the user in the wrong direction and does not lead to value.
• Bank verifies the user’s debit card application, which may take some time. This step is necessary for a user wanting a debit card, but this user wants a credit card. This step does not lead to value.
• When the card has been approved, the user immediately gets a virtual card and can start using it for purchases. But the user is getting a card they don’t want and they haven’t even started the process of applying for the card they do want. This step does not lead to value.
• At long last, the user can start applying for another banking product, such as a credit card. This step returns the user to the value path but at this point they are likely annoyed after having to perform so many unnecessary actions.
• Don’t forget that the debit card process is still ongoing and distracting the user from the value they want: the user is being asked to arrange a time and place for delivery of the physical debit card.
• Meanwhile, they start the process for obtaining a credit card, which is very similar to the process for a debit card. This path will lead to value but it’s safe to say that having to repeat all these actions (even if it’s for the card they actually want) will result in a very irritated user.
• After reviewing the terms and conditions, the user indicates a desired credit limit and confirms the information they’ve entered.
• An application is sent to the bank for the second time. This takes time and is necessary for issuing a credit card.
• Finally, after the credit card application is approved, the user gets a virtual card that they can start using. Then they set up card delivery—this time, for the type of card that they actually want.

For this use case, the CJM is clearly suboptimal.

The user (assuming they make it to the end of the value path and don’t drop out along the way) still gets the credit card they want. But to do that, they had to also perform lots of needless actions and apply for a debit card they didn’t want. The virtual card and convenient delivery are high points, but they will likely be overshadowed by a cumbersome experience.

Analyzing and improving activation mechanisms

Our analysis showed that the current activation mechanism is designed for users wanting a debit card, at the expense of those who want a credit card.

The triggers and contexts for the needs of the latter have been ignored. Credit card users have to slog through a large number of steps that are not relevant to them. The time to value becomes considerably longer.

The problem is clear. The team now needs to decide what to do about it:

• Solution #1: Use information about traffic sources to drop the user into the correct flow based on which ad brought the user in.
• Solution #2: Add a step to the start of the activation flow for the user to explicitly indicate which product they want.

The problem with the first solution is that many users come thanks to word of mouth. For them, there’s no way to know in advance which product they’ve come looking for.

That’s why Solution #2 was ultimately chosen. The new CJM looked like this:

[Hi-res image]

During the third step the user is now asked which product they want. This puts them on the shortest path to value. Each step on the path either effectively provides value or is necessary (can’t be removed).

Benefits for activation

This example is a simplified version of a real-life case.

After these modifications, the time to value for the first use case is virtually unchanged. The time to value for the second use case, however, is now much shorter.

The activation rate for Use Case #1 is unchanged. This is expected. But activation in Use Case #2 grew significantly.

Think about user jobs, not features

The main value of this approach is in forcing product managers and teams to put themselves in the user’s shoes. They start looking at the product in terms of what the user is trying to accomplish.

For many teams, this is already a big step. Otherwise, they may stay stuck in a narrow features-and-specifications mindset that does not resonate with users during activation.

As we’ve written previously, product features are valuable only in the context of what the user is trying to do with the product. Crafting the product experience around each potential job-to-be-done improves activation and surfaces value in more effective ways.