【0 to 1】New product features and operational rhythm

This article shares the experience and reflections of the new project from the perspective of team members. If you are setting up a new project and want to gain experience in product design and team management, this article provides specific suggestions that are valuable for new project teams.

【background】

Some time ago, I published an article titled "Why [we] didn't make this product well?", briefly reviewing the history of new projects I have participated in in the past, covering e-commerce, games, tools and other fields; no matter which project team you are in, you will be subject to constraints in many aspects such as timing, leadership, team, resources, etc., and any failure in any aspect will cause project risks or resistance. I also briefly analyzed the reasons and thoughts in the article, and interested readers can read it.

In today's article, I would like to share my experience in a new project from the perspective of a team member. The content comes from my daily work notes, which I further organized and disassembled for this output.

1. [0 to 1] Product Iteration Thinking

I don’t need to elaborate on new project establishment and market analysis. There are countless models and articles about this on the Internet. In fact, most teams cannot decide what product business they will do. At most, they have the opportunity to participate in discussions about product features. Based on my past work notes, I would like to share the following ideas about new product-related issues, so that you can learn from them:

1. Focus on the core

When doing a new project, we must first clearly understand the product positioning and think about the closed-loop path of the core business based on the positioning, which is what we often call a user experience map or function usage journey.

Design corresponding functions based on what actions (data, information) users need to complete to achieve their goals.

New products focus on core issues, and even the entire product is designed to solve these issues; early versions are iterated around core needs, gradually from simple to complex, from shallow to deep; being careful not to become a function-making machine is something that leaders and teams find difficult to restrain.

2. Maintain your core

The core business path of the product should be a smooth journey with unambiguous flow, unobstructed process, maintained interaction, and clear understanding of the copy. Afterwards, the team will focus on improving results (closed-loop service) and conversion rates (page funnel) for a period of time.

Before the main path is running smoothly (whether the data meets expectations), it is a very difficult and arduous period for the team because they have to iterate quickly and try various possible solutions; during this period, they are also affected by other secondary demands and leadership concerns.

Most teams will shift their focus to avoid the pressure of focus, such as dispersing team strength, starting to handle various requirements, adding various functions or activities (beginning) ; in this way, the core legacy issues will be handed over to a certain person or group to be responsible for, and the result will become their problem or KPI (result) ;

Just imagine, how many people in your department team are still concerned about core indicators and what is our core business? If you don’t gather the team’s strength in the early stage, focus on goals and resources; work together from top to bottom to focus on problems/solve problems, many new risks will be generated, which is also difficult for leaders and teams to control.

3. Highlight the core

The above mentioned are all about the 0 to 1 stage. The team should focus on one thing. After clarifying which stage of the market the product is currently in and which type of users are the target group, we will begin to divert traffic through external traffic channels, and distribute functions and activities to users through operational mechanisms within the product. Finally, we will focus on the funnel conversion of each function/service.

The most difficult part of this process is how to highlight the core and keep users. I summarize the process into three steps: cognition-recognition-subscription. Past experience is to determine what the core selling point of the product business is? Then strongly expose it through operational strategies (preferably with its own unique preferential methods), so that users can have a strong perception of the service process/results. In this way, new users can retain in their minds who you are, what you can do, and it is really like this in a few minutes or more than ten minutes of experience.

At this time, the product needs to adopt a strong operation mechanism, that is, where do I want users to go and what do they do? Instead of analyzing where users go and what they do every day; this is also the thinking error of many teams (let users follow me and complete my expectations; instead of following users and seeing what they do).

It is worth noting that the closed-loop experience of the final fulfillment service cannot be ignored, because early word of mouth is still very important; many new products tend to focus on the rich variety of the first half of the page, and wait for the user to successfully pay, and there are a lot of problems in the second half, such as the core of e-commerce shopping is many pre-sales discounts and good after-sales service; you can't just say that the product is cheaper than Taobao, and then check the order logistics after placing the order, and find that the product is damaged when unpacking, etc., which will reduce everything to zero.

4. Dealing with competition

When doing a project, it is either in the blue ocean field, where the users are new users and the demands are also new demands; or it is in the red ocean field, where the users are the same group of users and the demands are the same group of demands. In this case, the competition is to meet the same demands but with different differentiated positioning to satisfy users from different circles; for example, when it comes to eating, some people like to dine in the restaurant, while others like to order takeout.

Or maybe the needs are the same and the users are the same; what is being compared is the different service features, which can also leave an impression on people; just like in the e-commerce field, JD.com buys electrical appliances/fast logistics, Taobao has rich categories, and the second-tier e-commerce companies each focus on Japan and South Korea, duty-free shops, etc.

When the team finds and polishes its own product features and advantages, it has the confidence to get to the table (marketing push); at this time, a dedicated work method should be adopted; different business teams should be matched with each other and be in charge of different business modules; they only need to consider how to continue to deepen and optimize the business modules they are responsible for; the upper level of leadership should control and push out the cohesive force formed to form a product that meets all requirements.

2. [0 to 1] Thinking about the operation rhythm

1. User operation rhythm

Regardless of the product stage, it makes sense that 20% of users contribute 80% of revenue; therefore, it is important to find out the attributes (job/age/occupation) of the user portraits (interviews/questionnaires/communities) of this 20% user group; then provide targeted service operations and pair active/retention mechanisms for core users.

Core users require long-term operations. As the product continues to develop, the user base begins to show levels and will gradually be diluted and stratified, just like the pyramid model we often talk about. Here we point out that users can be divided into different levels from different dimensions, such as new users-old users, non-paying users-paying users, etc., and N pyramids can be divided according to different operational needs; this is convenient for the team to understand and maintain operations.

If the team has limited manpower and resources, it is also acceptable to adopt a gradually sinking operation approach (from the top of the tower step by step downwards); not everyone needs to be operated, and not everyone should provide services; decisiveness in operations is also important.

2. Activity operation rhythm

My experience in operating new product building activities is to lay the trunk first and then add the leaves. How to understand it? The rhythm of product building activities should first be combined with the AARRR model (or other models) to design the overall product node activities; secondly, consider other node activities.

3. Lay the trunk

Take e-commerce as an example. If the main process of users is to complete the first order - stay active - continue to repurchase - retain and attract new users; then what activities should be configured for new users to place their first order? After the user places an order, what functions/activities should be configured to keep active? After receiving the goods, what activities are there to encourage users to continue to repurchase? And finally, can the users who remain be enabled to guide the business to attract new users?

If the above main links and supporting operational mechanisms are not running smoothly, don’t consider other aspects; it is necessary to ensure that there are no operational breakpoints in the user’s core business path, and there are operational mechanisms everywhere to guide users where to go and what to do.

But in the projects I have experienced, there are usually two approaches. One approach is to do everything at once. That is, if the above problem is indeed an operational problem, immediately raise the demand and add all these activities to the page. The other approach is to place the first order to do a new user activity, and to attract new users to do an invitation activity, which is almost the same; then run off to work on other operational activity plans.

If you think about it carefully, the two operation rhythm plans above are only half right, that is, they seem to have everything in place; but in fact they are still superficial operations; either users encounter breakpoints everywhere in the actual use process and there is no operation strategy; or they are laid out flatly to users, with functions/activities scattered across various pages. Although they are all exposed in this way, I am afraid that they will only operate whichever one they remember in the future.

4. Leaves

For any project product, there are countless large and small activities. Based on team resources, we usually do lightweight activities first (daily, festivals, etc.), which can be quickly implemented in the form of H5, and then gradually transition to support Rubik's Cube/Lego in the background, so that operators can freely build lightweight activities. This can first ensure that the operation is flexible and running. Finally, the operation strategy of the backbone link is matched, and lightweight activities can be supported at any time, then we can start to challenge large activities (anniversary celebrations, big sales, etc.).

Another experience I can share is the understanding and application of activities. We know that with the development of the Internet, there are many kinds of activities, such as blind boxes, raffles, capsule toys, group buying, flash sales, N yuan selection, etc. Different activities have different attributes, such as attracting new customers, promoting orders, making up orders, clearing inventory, etc. Combining data and user preferences, I can also write a review article on what path/node to use and what activity mechanism to use. If readers are interested, I can summarize it later.

3. [0 to 1] Teamwork Thinking

1. Functional planning rhythm

We have discussed the product and operation rhythm ideas above. Now let's talk about the function planning rhythm. I will roughly divide the product business into hard power and soft power. For example, after building the core functions and supporting operation mechanisms (hard), we will start to think about how to sell more business and how to increase the average order value, which is classified as efficiency improvement (soft). At this time, we need to build message reach, marketing reach mechanisms, etc.

There are many contents and scenarios that need to be considered in terms of soft power, but as long as we sort them out by categories, we can improve them one by one. Of course, if the team has abundant manpower and resources, the functions and operating mechanisms (soft) will generally be matched.

If it is a supporting project, it is recommended to make good use of collaborative documents to maintain it, such as which functions are affected by which messages, which nodes will have marketing push, etc.; in this way, during the process of continuous iteration and optimization, you can trace the source; otherwise, the more you do, the more chaotic it will be, and you will not know where you are.

2. Functional operation rhythm

When it comes to functional support, when we propose a new functional requirement, we should think about: what problem do users/we need a certain function to solve/what information do we need to collect; what is the user journey of this function; the rhythm of product and operation should be synchronized, without any gaps.

For example, if you want users to use this function, what can they get? How to participate, spread, etc., there must be an operation mechanism; the product considers how to simplify the process? How to attract people to continue to interact? What are the risks and obstacles? Operations should think about how to implement the contact mechanism and activity strategy (hard)?

Including the need for functional iteration, if it is missing or insufficient, it should be launched carefully; otherwise, after the launch, a dry function will be left there, either the function is not perfect, or there is no operational atmosphere; no one will feel comfortable if it is dead or alive; if it is really not possible, the person in charge should be restricted to supplement the content at what time; otherwise, some functions are really launched after they are launched.

IV. Conclusion

Whether it is the work rhythm of product operation or the rhythm of team collaboration/management, in the actual work process, you will always encounter new problems and new challenges; an article either gives specific review experience for specific problems, or summarizes the experience and shares the experience; after all, historical experience can only touch the tip of the iceberg. I hope this corner of this article will help or inspire you.

Author: Cat Xiaoli

Official account: Operation Growth (yunyingxq)