Fission event planning and promotion plan!

When reviewing requirements, we all hope that the functions we design can be praised by our superiors and recognized by our colleagues. But if our ideas are not clear when we design a product, we may not be convincing and be stumped by other people's questions. Here I would like to share with you my own experience in planning the function of a fission activity.

1. Determine the project background and objectives

The first project I received after joining the company was to design a public class fission function.

After getting a specific project, the first thing you need to know is why such a project should be set up? What is the project background and objectives?

The background of this project is that the company’s current traffic acquisition costs are very high and product growth has reached a bottleneck. In order to reduce the company's traffic acquisition costs, a small fission function needs to be added to this product version iteration. The project goal is to increase the number of fission business cards.

2. Break down the goals to make them clearer

Breaking down goals can make unclear tasks clearer, and you will have more ideas and direction when doing things.

Figure: Project goal breakdown

Judging from the results after breaking down the project goals, the number of sharers, sharing frequency, number of people being shared with, and conversion rate can all be used as design starting points and decision-making factors. In the process of sorting out the scenarios, it is necessary to focus on these starting points.

3. Sorting out fission scenarios and looking for opportunities

After sorting out the details of the traffic conversion process in the real business scene, we should start brainstorming the corresponding scenarios and needs of the sharers based on the research facts, rank the needs priority, and select the highest priority needs for in-depth design.

This time, we mainly focus on the fission of new users such as trial course students for two reasons:

1. The company currently has a large proportion of this type of users and has not fully utilized them.
2. Since I have conducted pre-sales on-site research but not yet after-sales on-site research, I have some understanding of the students who have taken the trial classes and those who have pre-registered for the full-price classes, but I do not have a full understanding of the class process for the full-price class students.

The sharing scenarios are summarized as follows:

Figure: Thought guide for sorting out fission scenarios

In the figure, the branches are sorted and organized according to user-scenario-demand opportunity points. First, continue to diverge your thoughts and don't rush to deny your previous ideas. The next step is to organize and converge. The fission scenario opportunity points are marked in red.

4. Prioritize and select the scenes to be done first

After sorting out the scenarios from the perspective of the event sharer, start to prioritize specific needs. How to prioritize starts from the following dimensions:

• Frequency of demand and number of people sharing;
• Development difficulty and effect;
• Sharing willingness strength.

Dimension proportion score: 1-5 points, each dimension score: 1-5 points.

Total score = dimension proportion score * score of each dimension.

Finally, refer to the results to consider which scenario to do first.

The results are summarized in an intuitive table as follows:

After completing the table, we came up with a relatively objective evaluation basis.

In fact, the advantage of listing a rigorous table here is that when reviewing the requirements, you can explain with reason and logic why you choose to do this requirement first, which is more convincing. However, you should not completely follow the priority ranking in the table. You still need to screen the scenarios based on the actual situation.

Finally, we chose the first version for a buy-one-get-one-free promotion, which means that users who purchase the paid open course will have the opportunity to give it to a friend for free. Generally speaking, this activity scenario is aimed at the largest number of participants. Don’t pursue perfection first. Quickly launch an activity to test the effect, and then gradually expand the activity to cover each segmented scenario in the future.

5. Flowchart and Prototype

1. Flowchart

After selecting the specific scenario to be designed, the drawing of the flowchart is of utmost importance and must not be omitted. Because only when the flowchart is sorted out, the subsequent prototype and demand review will be easier. And the flowchart can also let participants know clearly how the business works.

Before drawing a flowchart, you should sort out the following elements:

• Users: How many types of users will participate? Systems can also act as participants.
• Tasks: What are the things these users want to accomplish?
• Data: How does data flow in this process?
• Special status: What should I do if a problem occurs?

Figure: Flowchart

In fact, there is no very fixed rule for which flowcharts to display. It still needs to be judged based on the actual project. For example, for the fission tool I am currently working on, how to store the fissioned traffic and how to follow up before sales are the key considerations in the process. But if it is an e-commerce product, you need to consider more about how to deal with various special situations.

The ultimate goal of the flowchart is to enable better communication with developers, as long as this goal is achieved.

2. Prototype

Once the flowchart is organized smoothly, the prototype diagram will be very simple. Specifically count the number of pages that need to be prototyped in the flowchart, which should be consistent with the business process, with a clear page structure and a unified interface.

I won’t spend too much time going into the details of prototype design here. The focus of this article is still on the basic process routines for functional design of new products.

6. PRD Document

Once the flow chart and prototype diagram are finalized, they need to be written into a PRD document.

The PRD document is the product requirement document, which is mainly a document for technical personnel to read. They need to refer to this document for the visual design and development of the product. Therefore, the most core part of the PRD document is the description of the functional part, which needs to take into account various abnormal situations and product details. The more you consider, the faster and more quality your development will be.

The documentation will vary slightly depending on the situation of each company and team. But in general, a complete PRD document usually contains the following parts:

• Demand introduction (demand background, product features);
• Functional details (product function structure diagram, business process diagram, page flow diagram, main function description);
• Performance requirements;
• Product operation plan.

As mentioned before, the description of the functional details is the core of the PRD document and occupies the largest part. A very simple criterion for judging is the number of words. The more words there are, the more situations you need to take into account. Here I summarize the following types of descriptions:

1. Value selection rules: that is, the fields on the front end of the product take the corresponding fields.
2. Restrictions: including display range, limit value, format, sorting, etc.
3. Status: default status, common status, special status.
4. Operations: common operations, special operations, and incorrect operations.
5. Feedback: including prompts, jumps, interactions, etc.

When you first start writing requirement documents, you will find that you always fail to consider everything and the documents you write are often criticized by all parties. This is a very normal situation. Don’t be discouraged when you encounter this situation, because this is an opportunity for you to continue trial and error and grow rapidly. Listen to opinions from all parties, create a new review document for yourself, write down all the problems in a timely manner, and try to avoid them next time.

You can see that the review document I wrote for the first time really has a lot of problems~ But I must go through this process to grow~

Figure: My review document

VII. Conclusion

As a newcomer, I can fully understand the confusion that new product developers feel when they first get the task.

At this time, you must not start working right away. You must sort out your thoughts, list a step-by-step plan, form a framework for doing things in your mind, and constantly reflect, summarize, and optimize this framework. Only in this way can you become more and more efficient.

Author: Kitty Wen

Source: Xiaomaowen