An effective demand review meeting

Do you remember how many "needs review" you have participated in? Whether you are a host-led, or as a wingman, the "needs of the review meeting" scene is to make people unknown. And the product manager is in this one after another "needs review meeting" in the honed, is a real brush monster upgrade process. It is said that the "demand review", also known as "tearing the assembly", you can feel the picture of the feeling.

The Product Manager organizes the "needs review meeting" similar to the multi-party talks, the participants are easy to enter the role after the "independent" mood, the formation of positive and negative or even multi-faction, and finally from the "discussion" into the "debate", a bit similar to the "Flower said" form. Product managers in this "debate" process, and constantly show their views, hoping to gain more recognition, but many product managers in this "debate" the process of their own scars, very embarrassed.

About the personal goals of the requirements review meeting

Product managers need to be clear about what their personal goals are in this "demand review". The goal is to set up for themselves, rather than for the team to formulate, plainly, through the "needs review" to achieve what effect.

For example: Let the development team, Test team students can identify themselves this iteration of the product plan, this is a very pragmatic goal.

For example: Let the development team, Test team know themselves and the designers in the product planning stage to do a lot of effort and try, this is a display design team goals.

For example: to the development team, testing team to demonstrate their rigorous thinking logic and excellent product design capabilities, this is a personal goal.

Although the starting point is different, these are considered as preconditions.

On the principle of "Requirements review Meeting" one, "don't try to transplant your ideas into someone else's brain."

First of all, the product manager needs to make it clear that we hold a "needs review" not to "transplant ideas" into other people's brains, but to run through "guidance" and "discussion" to get a product solution that everyone recognizes.

I have participated in a lot of "needs review meeting", product managers are holding "transplant idea", "persuade you" attitude in the need to preach, product managers racked their brains to "transplant" to develop, test the classmate's brain, can imagine the process is how painful; Convincing "each other, is bound to find the most extreme cases of their own experience in the project to support their views, it is conceivable how hot the process."

In fact, the product manager and development team, testing team should be a "cooperation" process, that is, in the Product manager's basic program, continuous optimization and adjustment process, if the development of students have better ideas, product managers should be adopted. But the reality is, many product managers because of the "face" problem, always feel the need to listen to me, others say "right" or "not" I do not care, has been unilaterally adhere to their own. That's not necessary, is it?

Second, "Don't be too tangled in different points of view, wasting time"

We are guided by the idea of "seeking common ground" to "discuss" the issue, that is to say, the same direction, small details can have different views, and encourage everyone to express their views, product manager's "open" mentality is very important.

Throughout the needs of the review process must have a lot of big and small problems, for mutual recognition of the place we confirmed after the quick, for each other do not recognize the place we no longer tangled, if the discussion for more than 5 minutes still no conclusion, the product manager to write down this problem, first carry out the following content, Finally, we'll go back and discuss the controversial issues.

I went through a very grueling "needs review", which lasted from 13:30 until around 19:00, because the product manager did not control the time of the discussion, and the granularity of the detailed discussion, which led to a long and very general effect on the demand review front.

"To give everyone a clear background and objective of this demand review"

Many product managers at the beginning of the "Requirements review" when the interaction process, functional feature, which is taboo. How did you get into your process when you were not aware of the situation? How can we find the details inside? How can you approve of your plan?

So the product manager in the first need to give everyone "FM", let everyone to a channel up. In fact, the need for product managers in the "needs review" before the start of the interaction and function, but to introduce our version to "Do What, why," What is the value of the three aspects (in fact, do product planning to consider), which is the so-called background and goals.

Here in fact also conforms to the "pyramid principle" in the background → contradiction → problem-solution of the thinking mode, I have in the previous article to do a detailed description. You can click to view: Product Manager Essential Skills: Pyramid thinking.

Iv. "No matter how bad the situation is, product manager should not be worrying, not red-faced, can not be abusive"

In the "Requirements review" site will inevitably encounter a variety of unexpected situations, no matter what happens, product managers need to remember two words " Patience ", regardless of any point of view should be calm and objective expression, do not control yourself, put some ideas with their own subjective color, so that a simple incident complex.

The first phase of the three phases of the requirements review: Before the requirements review meeting

Product managers need to be aware of several points at this stage.

1. 3 days in advance with the development, testing, design and other teams to coordinate time to ensure that key players have time to participate in the final determination of the "needs of the review meeting" schedule, set up the conference room, issue meeting invitations, and pull good rtx work discussion group known to everyone. In simple terms: Which version, who, where, meeting.
2. 2 days prior to the "Product interaction prototype", "Product requirements document" through the mail and in the format of the RTX discussion group sent to the meeting members, and strict requirements of the participants must take time to review the relevant documents, and ask their own questions.
3. 1 days in advance to collect all the questions about the content of this review, a summary of the problem after one by one answer, in the form of mail unified reply to everyone. Revise the document according to the question, and finally remind you of the time and place of the "Need review meeting".

This is the "demand review" of gold 72 hours. We have to take advantage of this 72 hours, in advance to prepare, will greatly improve the "demand review" efficiency, but also can effectively reduce the risk of injury and the risk of the product manager.

Phase II: "Requirements Review Meeting"

"Needs review meeting" plainly is a face-to "seminar", so the "middle" this link is the most important, not to neglect. Because we've already made a lot of preparations, it's good to relax and be a talk show.

1. Tell us what the story of this iteration is for the user (what to do), what the story is (why), what the user can get from reading the story (what value). This is also a standard background and the way of the goal statement, do not come up directly to talk about interaction, speaking functions, but also to recall their own for this "demand review meeting" of the personal goals.
2. Well, we went to the real topic and started to explain the function points of this iteration, the product interaction prototype, the product requirements document, each function point explained, everything, do not have any omission. The order of explanation must start from the function point first, then the prototype, finally is the requirement document, a point and the surface of the process.

In this case, we generally encounter these kinds of situations.

The first: You agree with my plan, this is the most ideal situation, but also the product manager's most expected situation, roll up the sleeves to start the job.

The second kind: You agree with my plan, but you have a better idea, it is a very harmonious situation, the whole screen full of love, optimize the details, will only make product logic and strategy more complete, this situation is even better than the first.

The Third Kind: you do not agree with my plan, you have a better idea, OK, we in this situation first discuss the background and goals, these do you agree? If the target is recognised, let's listen to your plan, and if it does, I'll adjust it and then roll up the sleeves and dry it. If you do not recognize the goal, I need to constantly persuade you (here to control the time), let you recognize the goal, and then roll up the sleeves to dry, but this is rarely seen.

The fourth kind: You don't approve of my plan, but you also have no better idea, this ... Are you sure this man is not infernal? This situation is also very rare.

③ after the storm, we can see some of the light, a little Ann, Victory is ours. This time The demand review meeting "is actually nearing the end, just to mention, about the details of the problem of particle size discussion, the two sides must stand on the same level of discussion, the conclusion of the place is no longer repeated, only discuss the same latitude problem, not I am still talking to you about functional requirements, you have to discuss with me where the pointer should be.

Oh, yes, all the questions discussed are written in the book.

Phase III: After the "Demand review Meeting"

① after the meeting in time to output minutes, lists clear issues or points of contention, has formed a conclusion of the place will not repeat, to determine the issues continue to find the relevant person to discuss, until the final conclusion.

② Finally, a gorgeous e-mail is known to all members of the Conference, the content of the message includes the dispute points and conclusions of the requirements review, the most important thing is to send the updated requirements of the document to everyone.

③ finally finally, urge development, test students evaluation development, test cycle, give time node.

Above, a laborious "needs review meeting" finally completed, from the beginning of the organization to the final confirmation email, without a product manager's sweat and tears, but a good "demand review will" for the healthy growth of the product to help, so more pay is worth it.

From the current practice, the product manager in the "needs review" on the best opening is self-summary, and put on yogurt. Generally more complex iterations, in the opening time I will first summed up in the last version as a product manager, their own fault what, do not think this is not lost Wannna, in fact, the development and testing students are also very concerned about the product, so want to know what the product level decisions are to which is wrong. And that attitude is very much to be recognized by them. We do not often say, product such as character? That's what this means.

An effective demand review meeting