Recently, I have been participating in various requirements review meetings, and I have contacted many new product people, and I found that many new product people who have just started are not very good at requirements review meetings, and often the meeting time is not controlled, and the results do not meet expectations. Take this opportunity to make a small review of your own experience, first, to form SOP, and second, to provide ideas for new product people. This time, it is planned to describe from three aspects: before, during and after the review, and I hope that every product manager can grow into a unique person.
1. Before the review: do not play the unprepared staff
When attending a PM training course, the instructor said that the purpose of the meeting is to reach an agreement on relevant issues through communication.
The same is true for requirements review meetings, where the most important purpose is to ensure that the solution to the requirements is understood by the relevant personnel involved in R&D, testing, and even leadership. Since it is a meeting, the following matters must be clarified before organizing the meeting: the background, theme, time, participants, and key points that need to be discussed. This article focuses on sorting out the "background of the meeting" and "the key points that need to be discussed" by newcomers to the product.
1) Notify the participants and send relevant materials.
Before the meeting, we often mention to notify the relevant participants, after notifying everyone, Pippi suggested that everyone will use the requirements of the review meeting: requirements business scenarios, business process diagrams, page wireframe diagrams, status description diagrams, etc., to ensure that everyone knows what the content of the review is, and can quickly connect the business in the brain with the help of information or sort out their doubts or points of interest in advance, so that they can keep up with the product manager's ideas during the review.
If time permits, you can also collect the content that everyone has doubts about and the special scenes that are not covered in advance, prepare the plan, and discuss it in a unified meeting.
2) Throw out the key solutions or scenarios to be discussed in advance.
The important point to discuss is that there may be scenarios in this requirement where it is not clear whether this solution is needed due to technology, resources, or other constraints. This must be sorted out before the meeting, and ensure that the relevant core personnel in the team know that this is the focus of this discussion, so that everyone can prepare their ideas in advance and avoid colleagues having a "What is he doing" confusion during the discussion.
3) Reach an agreement with the supervisor on the overall design ideas and schemes.
Products that have organized requirements meetings know that review meetings are often cross-departmental, and it is not easy to coordinate the time of so many people, so the most important thing in the meeting is efficiency. How can we improve efficiency? The so-called "catch the thief and catch the king first", before organizing everyone to go to the meeting, we must agree with the relevant leaders on your design ideas, difficulties and solutions for this review.
The benefits of getting the boss in advance are numerous.
- Avoid the leader directly "attacking" you at the meeting, affecting your mentality and subsequent performance, and sometimes get the boss, he will also help you fight the crowd during the review.
- With the endorsement of the leader, colleagues such as R&D will basically directly "agree" with your plan, which sounds a bit of a "fox and fake tiger" feeling, but the primary goal of the work is to complete the task;
- With an alliance, your meetings will go smoothly, and over time you will become more confident and more handy.
Second, the meeting: from top to bottom, gradually deepening
After the previous preparations, we have basically succeeded 40%, and the next step is to pay attention to the following points when reviewing.
- We have sent the relevant materials to the participants before the meeting, in order to avoid everyone has not seen it or has forgotten it for a long time, we should quickly sort out the business goals of this requirement before officially entering the functional details.
- Make sure that everyone is clear about the business goals, and then connect the business logic, note that this link needs to be connected to the business logic, not your page function logic. If the process involves proper nouns or special scenarios, it should be explained emphatically.
- After sorting out the business logic, you also need to describe the roles or positions involved in the business, so that everyone can clarify how many positions or roles are involved in the business and what each person is responsible for.
- After sorting out the business, you should enter the requirements design, and before entering the detailed design, the product manager should first connect and explain the page group.
- After the above links, everyone has built a preliminary form of the relationship network of requirements, roles, pages, etc., and the next thing we want to do is the key part of this requirements review, and it is also the part that consumes the most everyone's energy - the detailed review of each page and each function.
Usually when I review a page, I follow the following lines:
1) Describe the business goals that the page needs to achieve, what the user wants to accomplish through the page, and what effect it will achieve. Secondly, describe who will operate the page, what these people do through the page function, and whether the page needs to be controlled by data permissions.
Most of the time, we will also mix several things together and say, if you are well prepared, when the role or business is complex, you can make a simple user portrait table, and explain the relationship between roles, functions, and data. There are many ways, you can choose what you are good at, the purpose is to make things clear.
In short, don't get caught up in the details as soon as you come in. It's like a big black block on the booth, and the people in the audience don't know what this big pimple is, so you start to say the button inside, and the final result is "the chicken and the duck talk, and the appearance is separated", which is also the reason why many friends are puzzled that everyone has no problem during the review, and why it suddenly makes all kinds of reasons when the development and implementation are not reasonable.
2) The most important thing: explain the functional requirements one by one!!
When explaining the function, the product can first explain the scenario of the function, then explain the prerequisites for its operation, and then talk about what the system should respond to or deal with after the operation, and if it involves a state change, it should also describe its state change.
For example, to explain the function of adding a new invoice, I often say something like this:
After receiving the sales invoice offline, the inventory operator will log in to the system, create a delivery application, click: [New] button, gradually fill in the relevant fields of delivery and receipt information, verify that all the information is filled in and save it, and if it does not meet the rules described in the demand document, give a prompt according to the document.
After the save is successful, the status of the invoice is updated to "To be submitted".
In addition, when the inventory of the goods selected by the operator is insufficient, the system should inform the contact information of the warehouse keeper and procurement personnel of the goods at the same time when adding a reminder of insufficient goods, so as to facilitate their telephone communication. This is also stated in the requirements document.
3) Supplement the overall description
After all the functions of the current page are described, if the page has some other supplementary rules, the description should be synchronized, such as: list sorting rules, interface adaptation color requirements, font requirements, and third-party interfaces.
4) Q&A and discussion
After the above links are over, the requirements of the page have basically ended, and we will enter the Q&A session to ask if you have any objections or incomprehensions to the requirements, and answer them step by step. If you have any questions or content that needs to be focused on before the meeting, you can also put it in this link.
When reviewing new products, you must keep telling yourself: I am the ancient Greek god of demand, and they have to listen to me first. I have participated in several reviews recently, and the newcomers are constantly interrupted, often when talking about this feature, others are asking questions about that scene, the rhythm is completely disrupted, and it is very painful for me to speak, and my colleagues are also very confused.
3. After the review: check and fill in the gaps, and end perfectly
I believe that after the first two parts are over, many product people have finally let go of their suspense, after all, our requirements review meeting has been completed by 90%, but don't forget to start and finish.
The review meeting is over, but the requirements review is not over. Product managers also need to quickly make changes to the details of the requirements based on input from all parties and synchronize the results to the relevant parties. Here's a tip to work quickly to avoid procrastination and forgetting parts of the content.
Fourth, the full text is summarized
Finally, to summarize the full text, organize a good requirements review meeting to focus on the following points:
This article was originally published by @皮皮是个宠物 on Everyone is a Product Manager. Reproduction without permission is prohibited
The title image is from Unsplash and is licensed under CC0
The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.