"Isn't it just a small need? Why are you so slow?" "Your requirement cannot be listed in the App, so the project will not be approved." "The requirement document written by your product is not the effect we want. What we value is..." "Queuing up, not enough r&d people, the schedule has already reached the middle of next month." "The functional test has been passed, but there is no plan to launch the App in the near future. It will be launched at the beginning of next month." "During the special period, no App containing this content will be approved."Copy the code

It’s too difficult. How many difficulties and obstacles should a requirement go through from the proposal, to project approval, to the completion of research and development and to the official launch? What hurts more than the long launch process is that the function is finally launched and the optimal window period is missed, so the result is not the desired effect.

  • Business department: the market is constantly changing, so we must speed up the response to demand and keep up with market hot spots in time
  • Operation department: There are thousands of operation theories. App cannot obtain user portraits, so it cannot support fine operation. And the speed of product iteration severely limits the launch of the operation plan
  • Product department: With a flood of demands and endless prioritization, the App is becoming more redundant and lacks highlights due to blindly following business requirements
  • R&d department: schedule, understaffed, rush, constantly do requirements, there is no spare energy to review code, optimize architecture, improve performance

Is this really a knot? Is there no way to satisfy multiple demands at once?

There are! Let’s try grayscale publishing!

What is grayscale publishing?

Gray publishing is traditionally defined as a smooth transition between black and white. A/B testing can be carried out on it, that is, some users continue to use product feature A and some users start to use product feature B. If users have no objection to B, the scope can be gradually expanded to migrate all users to B. In today’s world of “growth hacking” and refined operations, grayscale publishing is more than just a publishing method. It can:

  • Quickly validate marketing plans or product ideas, and achieve more experimentation with lower costs

  • Provide numerical proof for new function verification, and replace subjective judgment with scientific experiment

  • “Pilot” the new function in advance, and get a clearer what to do next through experimental group comparison

  • “Tracking” user feedback and “killing” unpopular features in the cradle

  • Shorten r & D testing process and accelerate team agility

In fact, although grayscale release looks “wonderful”, few teams can improve the overall transformation of App through grayscale in the real environment due to the complicated design process of grayscale experiment.

The difficulties include:

  • Since gray scale requires experimental group and normal group, the research and development workload cannot be directly reduced in the process of designing experimental group

  • The App lacks a “data grabber”, and it is difficult to obtain effective, real and timely user feedback after gray scale is put into the App

  • There are few options for grayscale publishing, and the App itself can only achieve an uncontrollable grayscale range through limited tools

  • Gray scale is more suitable for limited small functions, such as button color and text fine tuning, which can only improve part of the business conversion rate

  • Such as the large version of gray, limited by tools, and into the gray range is difficult to control the cycle

How to do a grayscale release?

Let’s review the difficulties in grayscale release again. To sum up, nothing more than:

  • Grayscale functionality also needs to be developed, corresponding to a complete development process, which seems inevitable
  • Grayscale release needs more rigorous scheme design, for what people, grayscale what content, how to analyze and use the results of analysis, which need to be skilled in business, understand products and users to elaborate design
  • Grayscale release coverage should be more accurate, coverage methods must be diverse and can meet the needs of grayscale scheme
  • Data after grayscale publication must be properly recorded
  • Grayscale publishing should not be limited to small features, only for H5 page publishing, not for larger, richer business scenarios

All of these can be solved in the fan Tai small program open platform.

Let’s take a look at the design and development process of grayscale publishing:

In the grayscale release process, once the business personnel put forward the corresponding business requirements, they can immediately put into the corresponding RESEARCH and development process, the benefits of this process are:

  • Business functions (small programs) are developed internally independently, without requiring too much development manpower, and demand response time is greatly reduced

  • Small programs only need to complete internal testing and review. The hot update mechanism of small programs can bypass the long review cycle of App application market and quickly complete the online function

  • Grayscale experiment design and landing, from developers to business personnel, business personnel to design grayscale range, grayscale rules, will be able to better complete the experimental group setting and practice

  • Implement agile iterations of functionality and business without letting a good idea go to dust, and the next business breakout point may lie behind that little idea

Fantai small program open platform gray release composition

1. Rich and visual rule configuration to meet personalized release Settings

Fantai small program open platform will be complex rules configuration visualization, just a few simple steps, you can complete personalized business rules Settings. These Settings can be the most common user list, age, city; It can also be some technical indicators, such as mobile phone model, system version; You can also add rules with business characteristics, such as whether you are a premium paying user or whether you are associated with other products of the company.

2, the simple grayscale release creation process, so that the grayscale experiment is best reflected

Built on the rule base, fantai according to a variety of grayscale release scenarios, extracted the most complete, the most easy-to-use, the most scientific grayscale release scheme creation process. In this process, business personnel select the small program version that has been developed and tested, and select the corresponding release time window, rules, rules between rules and miss processing according to the gray scheme.

Once the gray scheme is successfully created, it can be synchronized to the App in real time without waiting for functional review again. For the release with high timeliness requirements, the most direct and real-time data feedback can be obtained. In the event of bad feedback, the content of the applet can be immediately “rolled back” to the existing version.

3. The SDK sandbox automatically reports relevant data, realizing a complete closed loop of gray release

There is no need for every small program to carry out business development, Fantai released the small program runtime SDK, for some common data, automatic collection and reporting; At the same time, for small programs that need to send back complex business data, the most accurate data can be reported and sent back only after a little development because of the STANDARD data reporting protocol of SDK.

Come and try it! With fantai small program open platform, to achieve all your ideas of “thousands of faces”!