Do you know what features App development can really improve customer retention rate?

[[148029]]

Original English text: The Next Feature Fallacy: The fallacy that the next new feature will suddenly make people use your product

App developers often fall into such a misunderstanding. When the background data performance is not good, they always think that adding one more function to the App can improve customer retention rate! But is this true? Can adding any function improve customer retention rate? If not, how should the App be improved to make the background data chart look better?

"Next feature obsession": A misconception that developing new features is the way to maintain customer retention.

For those project managers who like to develop products, when the project is not going well, they subconsciously want to do more with the product. The cycle of "release-failure-rerelease" is repeated again and again, but people often ignore the fact that this method does not work at all and is of little use except wasting the energy and time of developers.

Let’s talk numbers. See the following figure to see why “next feature obsession” is a wrong way of thinking.

The above chart shows the change in customer retention rate from the initial browsing state of a product, to the registration as a user, and then to one month after using the product. From the chart, we can clearly see how it has dropped precipitously. This is a standard and most common customer retention rate evolution process, which can be supported by a large number of cases and data.

For a web app, the average numbers are as follows:

• Suppose 1,000 users visit the homepage and experience your product.
• 20% will register
• 80% of the above group of people will complete the beginner guide
• 40% of the above people will log in again the next day after registration.
• 20% of the above group will log in in the second week after registration
• 10% of the above group will log in again 30 days after registration

In other words, after 30 days, out of 1,000 visitors, only 20 users become real daily active users.

Of course, sometimes things get better than the above, especially if the app has built a great brand, has a lot of traffic, and can achieve a higher real user conversion rate among the traffic, or the data on the first, seventh, and thirtieth days are 2 to 3 times the numbers I published above. (Often in the field of communication apps.) But even if there are such exceptions, almost everyone will frown when looking at these numbers, and feel deeply worried and frustrated.

It is precisely because of this that the "next feature obsession" takes advantage of the situation. It makes people easily believe that as long as the new features of the product are developed, a series of digital indicators will become better accordingly. However, people often make the following two mistakes in developing new features:

1. Too few people will use this feature. Often, the target group for this feature is users who are already active in the app, or users who have already stayed, rather than non-users or new users.

2. It does not help people get more engaged in the use of the app. In particular, this feature is positioned as a "very important" and "critical" feature, but it is excluded from the novice teaching link and becomes an optional option for users.

The ideas behind these features are good, they all want to increase user engagement. But if people don’t use them often, then they can’t make that bad curve look a little bit better. In other words, a new feature launched on the seventh day will definitely not be used more often than a feature that appeared in the novice phase. Because the chart above has shown the result, only 4% of users will eventually see the existence of this new feature.

The focus of developing functions should be on the "newbie stage"

At this point, there is no need to elaborate on how important the "newbie phase" is. If the product manager does not use the most correct way to convey to users what the app is for and how to use it, then no matter how hard the subsequent repair work is done, it will be of no use!

When Twitter was first introduced to the market, the onboarding process was that after you registered, you were directly directed to an empty news feed page, and then a text box was left for you to fill in whatever you wanted to say. Of course, this made it easier for you to figure out what the entire product was like, and gave you enough freedom to decide what to do next, but it has to be admitted that this design was very poor. Today, Twitter guides new users to follow a series of accounts after they register. This functional design shows Twitter's positioning from the beginning, and it focuses on becoming a reader.

The Wall of Engagement

Another point to note is that you should not aim the appeal of new features at increasing user engagement in the product. Here we should mention the concept of a "wall of engagement", that is, there is a clear line in the process of the product constantly guiding users to use the product in depth. Behind this "wall", the functions pursue the behavior of users truly integrating with the product, such as posting a job, creating a new project, or storing files in a folder. In front of the "wall", the functions do not require much engagement to bring value, such as browsing the information flow, commenting on certain photos, clicking on a link, etc. If you create a lot of functions behind the "wall", these functions are indeed amazing, but only very, very few people can use these functions behind this wall, and these functions cannot fix the curve, that is, improve customer retention!

So how do you choose what the “next feature” is?

If you want to fix the curve above, you must have a very deep understanding of the user's product usage cycle.

The first thing that must be considered is to expand the coverage of this feature as much as possible, that is, the beneficiary population. Almost everyone who comes into contact with the product will be affected by this new feature. This is the golden rule! In other words, new features that should be developed must be targeted at non-users and casual browsers. The reason is too simple. Because the base of this group of people is so large, there is great development potential. This also means that energy and focus should be placed on the login page, the order of the onboarding process, and the initial "out-of-the-box" experience. These features are very, very critical, but they are often not given enough attention.

Similarly, you need to really understand what the user's next behavior is after they have come into contact with the product, so as to truly "activate" them at a certain stage and make them real daily active users. For social networking platforms, guiding them to follow or add friends is the most critical step, because doing so can easily lead to a positive cycle; for a "software as a service" (SaaS) application, it should be loading JavaScript tags on the right page; for a blog product, it should be convenient for people to name the blog, choose a theme, and write the first blog. Take out the new user onboarding stage separately for various designs and guidance, and try to keep the stages as simple as possible. The clearer the product appeal is, the more likely it is to guarantee a fairly good user conversion rate.

When a product is still in the early stages of development, product developers have too many choices and freedom in developing the next function. People often place too much hope on the "next function", but the result is often disappointing. In fact, the "next function" must have a more thoughtful design, more careful thinking, and more detailed and reliable research to support it, in order to bring a beautiful real user conversion rate to an app.