Build an e-commerce platform from 0 to 1?

The author of this article summarizes the process and pitfalls of the requirements review meeting for building an e-commerce platform from 0 to 1. I hope it will be helpful to you.

For some new product managers, hosting a product review meeting is a headache. They feel that they did not host the whole meeting very well, but they cannot tell what needs to be improved; or they are not aware of some pitfalls in hosting a meeting and step into them unknowingly, resulting in lower efficiency of the meeting.

I really enjoy the product review meeting. I think it is one of the highlights of a product manager. As the core role of the entire meeting, you are in control of it. But the quality of the meeting also depends entirely on you.

This article uses a project I have previously hosted as an example to introduce the "process" that should be followed in a requirements review meeting. I will then share and communicate with you based on my own experience and some "pitfalls" I discovered when participating in meetings hosted by others.

1. First introduce the purpose, scope, main functional processes, etc. of the project

We host the review meeting to let the participating partners understand what this project is used for, what are the main functions and processes. So when others don’t know enough about your project, you should first give a brief introduction to the project, otherwise they will be confused.

example:

1. As a full-category e-commerce platform, our platform model is to invite merchants to publish products, attract users to generate orders, and pay merchants, etc. This review is mainly for the management backend used within the company;
2. As the input source of data, the management backend first needs the merchant management function to add and manage the merchant's data;
3. After adding merchants, they can upload products through their own merchant backend, and the management backend we use can also upload products and manage and review the products uploaded by merchants, so the product management function is needed;
4. With the product data, the frontend or app can see these products and place orders, so the management backend needs to have an order management function to ship orders and perform other operations;
5. After placing an order, users may also return or exchange goods, so after-sales management functions are needed;
6. Since the order amount paid by the user is first kept by the company, a financial management function is needed to settle the merchant's payment;
7. Take a few minutes to introduce the project in this way according to the flow of data to improve the efficiency of reception by participating partners.

1. Pitfall 1: Talking about functions directly

I have encountered this before when I attended review meetings. For a new project, one of the modules was discussed right at the beginning, and this module was relatively late in the process. The reason was that this module had less content, as if it was only discussed to complete the task.

However, as newbies, the participants don’t even know what the project is used for, what functions it has, and how to use it. Their reception efficiency may be very low, because they may need to listen while guessing what the project is about and then verifying their previous ideas.

It’s like when you read a book. At first you may only know the title but not even the table of contents. You have to fill in the table of contents in your mind as you read.

2. Pitfall 2: Meetings last too long and you forget what you covered

It’s okay for small projects, but if the review time for a large project is as long as several hours or even divided into several days, you need to pay attention to this problem. What I usually do is to write out the menus at all levels on the blackboard in advance, so that it is convenient for the participants to recall the previous content. They can point to the blackboard while talking, and there is no need to switch prototypes back and forth (which is very inconvenient when there are too many prototype pages).

For example, I talked about the tag management function two hours ago. When I talked about adding products in product management, you can select tags for the products, but these tags are added in tag management. I pointed to the corresponding functions of data flow on the blackboard, and thus reviewed it once.

2. Introduce the detailed functions on the page

Adhering to the principle of "how data comes and how data goes", the order is merchant-product-order-after-sales-finance-marketing. This order is the easiest for participating partners to understand. Then, according to the principle of classification, we will introduce the fields on the page.

example:

As shown in the figure, this is the after-sales order details, which consists of 5 parts:

1. Attributes of the after-sales order itself: after-sales order number, application time, etc.;
2. Components of after-sales orders: pictures and reasons selected by users;
3. After-sales order related information: requested product information, corresponding order information, etc.;
4. Each status of after-sales order and its corresponding operations;
5. Operation log.

First, we will introduce the fields in this page by category, so that you can have a general understanding of the components of the page and avoid being dazzled by too many fields when you open the page. Then, we will focus on introducing some key fields and fields related to data flow:

The amount of the refund applied for is calculated based on the actual payment for the product. For example, if the unit price is 100, and you buy 2 items, the payable amount is 200. If you use a 20 coupon, the actual payment is 90, and the amount of the product for which you apply for a refund is 90.

3. Pitfall 3: There is no linkage between functions during introduction, resulting in low acceptance efficiency

After discussing function A, we discuss function B, and then function C... Each module is discussed as an independent entity, but we do not explain the connections between them. Therefore, another advantage of writing out the menus for each level on the blackboard in advance is that you can directly point to the content on the blackboard for easy linkage.

4. Pitfall 4: Too much content on the page and not being able to grasp the key points, mechanically introducing each function

First of all, you need to understand that the purpose of the review meeting is only to guide your colleagues and let them have a general understanding of what the project is about, what the main processes are, what the main functions are, etc. It is impossible for everyone to understand so many processes and fields within a few hours. After the guidance, the prototype should be given to them to review each field one by one and then give them a reply.

If you try to explain everything you want to say at the meeting, the meeting time will be greatly extended, others will become tired of listening, and they will easily lose focus, resulting in reduced efficiency. Therefore, we need to mark the primary and secondary functions and the primary and secondary fields on the page in advance, and just focus on the key points.

3. Answer your friends’ questions

After or during the speech, participants will generally raise their own questions. The demand side, development, testing, and UI stations have different perspectives and ask different questions.

5. Pitfall 5: Being led by the nose when answering questions

The most taboo thing for a product manager as the host of a meeting is a lack of confidence. If you follow whatever others say, you will lose the initiative in the meeting and damage your credibility in the team.

So when answering, you need to first analyze why others ask this question. Is it because the function is not easy to use? Development is difficult and you don’t want to do it? Development time too long? Or is there a flaw in the design of data flow? If what the other party says makes sense, is the solution he proposes the best option? Is there a better solution?

Of course, we should also listen to other people's opinions and find a better solution. This is very important. Product managers need to consider the delicate relationship with the team. If you are too strong, people will think you are too arbitrary; if you are too weak, people will think you are not confident enough and thus doubt your professionalism.

6. Pitfall 6: Discussions take too long and the pace of the meeting is not controlled

Some new product managers tend to get entangled with each other on a small point in the meeting, such as disagreement on the placement of a button, whether the title should be left-aligned or right-aligned, etc. This is easy to say, but when you meet people who question you in a conference with so many people, you may feel unconvinced and want to win when driven by emotions, so remember to manage your emotions.

If you encounter some ambiguous functions that you really cannot come to a conclusion immediately, what you should do at this time is to write them down and discuss them after the meeting.

For example, I have encountered friends who argued with me about whether product information should be saved in segments or one by one after adding. This not only involves technical costs, but also involves the user experience and risks during use. It is also necessary to analyze the frequency of possible risks and whether they are controllable. There is no way to give an immediate answer. What you need to do at this time is to write it down first, and then find the person in charge of the relevant department to communicate after the meeting.

7. Pitfall 7: The sound has no ups and downs, and the atmosphere is not controlled

This can be considered as an external skill for a product manager. Hosting a review meeting is the same as giving a speech. The purpose is to make others listen to what you say and feel comfortable listening to it, so the rhythm of sentence breaks and the degree of ups and downs when speaking have an impact.

For example, when I talk about unimportant content such as the after-sales order number and application time in the picture above, I will speak at a faster pace without stopping. When I encounter fields that require calculations such as amounts and have specific calculation methods, I will raise my voice to let everyone know that this is the key point.

I have observed that when the meeting was halfway through, some friends started to get distracted and play with their phones. I suddenly raised the volume, and those distracted friends immediately looked at the projection screen.

8. Pitfall 8: No interaction during the meeting

It is not good to have discussions that last too long at a meeting, but it is also not good to have no interaction at all. If the participants are rather dull and you just keep talking to yourself, people will feel that you are just there to read words, which is rather stiff.

Generally, after I finish talking about an important page or an important field, I will ask if there are any questions. If no one answers, I will ask the person in charge of the relevant front-end or back-end, and when I ask a specific person, someone will answer. But don't ask in a blunt manner every time. You can make some jokes to liven up the atmosphere. These are all small tips to improve the efficiency of meeting communication.

9. Pitfall 9: Nonverbal Behavior

This one is a matter of personal opinion. Your eyes, movements, and sitting/standing posture may affect the atmosphere of the entire meeting. I have seen introverted product managers who sat properly throughout the entire meeting because they were nervous, and their voices were neither too loud nor too low. They gave me the impression that they were not confident, and the meeting atmosphere was rather dull.

I usually like to stand when I am hosting a meeting because I am the controller of the entire meeting. Standing gives me a feeling of looking down, and it also helps everyone's attention to be quickly shifted to me when I raise my volume. When I talk about key points, I sometimes walk to the projection screen and point at it. This helps to enhance everyone's impression of that point.

4. Confirm each developer’s time

If the review meeting is to review prototype requirements for developers, it is necessary to confirm the team's respective time after the presentation.

However, it should be noted that what is usually formulated in the meeting is to determine the approximate time nodes or approximate project plans, so that everyone has an idea of ​​what should be completed in what time period; and the real specific progress plan needs to be formulated after the meeting, because the detailed project management plan needs to be accurate to every day for every person.

There are two situations:

1. The launch time has been determined

First, assign specific modules to specific developers (for example, A develops product management, B develops order management, and C writes test cases for financial management), determine the approximate working hours required for each (not only the time to write the interface but also the time to interface), and summarize to evaluate whether the development, testing and acceptance can be completed before the launch time.

• If possible: first make a rough milestone plan, what tasks will be completed at what time nodes, so that everyone is prepared;
• If not: first find out the reason, not enough working hours? Do we need to work overtime? Do we need to re-prioritize and cut some functions first? Are there alternative solutions to replace some functions that take longer to develop? We can even consider adding more people. Is the current technology not sufficient to realize some functions? Can it be put on hold temporarily or an alternative solution be found?

2. Not yet determined

It is also necessary to divide the work, determine the working hours separately, summarize, and then check whether the approximate completion time meets expectations or meets the expectations of superiors. If there is no compliance, you need to find the conflict point first and then coordinate as mentioned above.

5. Review after the meeting

The post-meeting review is very important. I usually review the good and bad aspects of the entire meeting:

• Which areas have higher participation rates?
• Why did everyone start to lose focus in the second half of the meeting?
• Was the meeting delayed because the discussion took too long?
• Have you ever spoken too fast and your speech was passed before everyone understood it?
• Do you tend to overly deny or interrupt other people’s ideas when discussing with them?
• Have you ever missed out on some important parts of a field due to nervousness caused by lack of preparation?
• …

It can usually be reflected through the expressions and atmosphere of the classmates, just like a teacher observes the facial expressions of students when giving a lecture. Hosting a requirements review meeting is not like doing math problems, where you can solve the answer just by knowing the formula. I think it is like calligraphy. You know how to write beautifully, but you can't write it if you haven't practiced. So it is better to practice more, summarize more, be well prepared, and be confident enough.