How the product is quickly iterated

Today, on Weibo, I saw someone forwarding pony brother: "Small step fast, rapid iteration" theory, just I recently collected some rapid iterative data, then combined with their own experience to talk about the rapid product iteration. This text may be biased project management, but I think project management is also one of the basic quality of product managers.

About the project

This is not unfamiliar to everyone, each product after BRD, MRD (of course, these two processes are not all product managers can participate), will enter the project stage. In the traditional process of project, we are more to go process, the project responsible for the application, the project team feasibility discussion and analysis, and then convene the General Assembly for the evaluation of the project, responsible for the corresponding changes in accordance with the results of the review, and finally held a vigorous project launch. And the rapid iteration of the project is not so complex, basically 10 minutes a page of the slide can be determined, the general will explain a few questions: Why do we do this thing? Is there any more important work to do? What is the standard for project completion? Where are the risk points for the project? As long as the project team has clarified the answers to these four questions, whether it can be set at a glance.

About the morning meeting

Now most Internet companies have a morning meeting system, in the rapid iterative product management mode, the morning meeting must first be standing, in order to ensure that the Conference is short and efficient, in general, everyone in the team will describe three major questions: What did yesterday, what to do today, what problems were encountered in the work. In the meeting, the product manager should focus on two aspects: the first is whether the work is really done yesterday, the completion of the said here is not the code to write the matter, nor self-test no problem is completed, the so-called completion of a task should be the true meaning of the completion, that is, to meet the needs of users, can immediately deploy to the real environment for use. I've seen too many engineers say that functionality is done, but eventually deploying to the server still requires a lot of testing, and then looking at you and saying, "It's okay on my machine." Second, the product manager should focus on what problems the team members are experiencing in their work, and find ways to help them through the strength of the rest of the team, here I refer to other people rather than product managers, product managers in the process should cultivate the team's ability to cooperate with each other to solve problems with the sense of achievement, trust.

About process Optimization

In the process of rapid product iterations, there are many places where product managers are required to lead the optimization, let's cite a few examples:

1. Thought optimization. In the development process will certainly appear the research and development personnel's opinion and the product manager, the interaction designer's opinion is inconsistent, because from the human nature angle analysis, each role will certainly use own inertia thought to ponder the question, for instance the engineer will tell this Banner on the left program to run the most efficient, And the interaction designer that put on the right will be more consistent with behavior habits, product managers think put in a little more than a bit more clicks, at this time the Product manager must guide everyone to stand at a higher level, more objective angle to find solutions.

2. Code optimization. This is more about code review, which typically uses a daily team-member crossover review and a weekly team to focus on functions review two modes. There is a sentence called workers, code review is the lowest cost of discovering potential bugs and finding functional biases.

3. Document optimization. It is recommended to use a wiki-like system to manage product documentation uniformly, product managers in the process of writing a document not because of fear of trouble to reduce the quality of the document, to know that the product is likely because you write less words to go to the other extreme, probably because of these words, the engineer will need to rework, That's why most engineers want to beat the product manager. Therefore, the product manager in the process of writing documents should be more to the engineer's perspective to write requirements, if you are engineers, see the requirements will appear to understand the deviation? If so, please use more time to improve the requirements of the document, the product manager should always be clear, the nature of the requirements document is not written how literary, Can let engineer correct understanding is kingly, the so-called regardless of black cat white cat, catch mouse is a good cat.

4, Team communication optimization. Product managers should increase their time with team members, choose to sit together at work, or have lunch, etc., and you should always find the opportunity to instill your ideas in the minds of the engineers and resolve their doubts as quietly as possible.

5, process optimization, demand management system, BUG management system, product packaging mechanism is highly intelligent, can allow team members to find the first time they want information.

About product quality

The disadvantage of rapid iteration is that the quality of products is not guaranteed, because the time is limited, often cannot the product robustness to carry on the sufficient test, even sometimes a function completes after the test personnel also only relies on the experience to pass the point, here I suggest that everybody chooses an intelligent BUG management system, System daily through mass mailing to show the bug situation, the product manager himself to have a bug tolerable maximum value, once a day of the number of bugs exceed this value, it is necessary to analyze the reasons and take appropriate measures to solve.

About the summary

After the product is online, we analyze the success of the product line through the data, and summarize the problems encountered in the previous iteration, because the team members of the rapid iteration are not many, so you can speak freely about the problems, evaluate the performance of the members in the process of the score, of course, this score is not related to performance, Our goal is only to hope that the team is better, the team will be good products.

I believe that every internet company has different views on the rapid iterations, this is a matter of the different people, but please understand that the rapid iteration is definitely not the process of modifying the BUG side of the line, and is definitely not the process of decomposing the function. The implementation of fast iterations is conditional:

First, the environment, the surrounding environment in rapid change, the product does not have enough time to carry out demand analysis and related testing;

Second, users, users do not know what they really want, the product needs to be iterative way of trial and error;

Third, cost, in general, the cost of iterative products are very low, and can be quickly updated version.

Can you quickly iterate over your product? Do you already know how to do a quick iteration?