Tell me about projects from 0- 1

As the saying goes, there are more projects than problems. Products are used to solve problems, so what problems will be encountered during the project? Write down and record those routines. I also hope to talk to you about how you solved it.

1. Initial stage of the project-product (strategic level) planning and demand collection stage.

In the initial stage of a product, it usually goes through the stage of demand collection, so where is the source of demand? The source of demand is feedback from leaders, business departments, operation departments and customer service departments. And the requirements of people inside and outside the company. What do you need to adjust through data analysis, product business layer adjustment, basic framework adjustment, product reconstruction and so on. Are the sources of demand. Then you will face more demand in this process. First of all, the demand put forward by the leaders. The needs of leaders usually have two directions. One is what function to do in the general direction or what kind of platform to do. One direction is that the process at the interactive layer level is not smooth, the color is not good, the button position is not good, and so on. We call it "fine-tuning demand" internally, hahaha. For me, the adjustment of the general direction will follow the leadership. Because the leadership knows the forefront of the industry best. Even if the wrong decision of the leader has to be carried out. Because we must try and make mistakes. Keep trying this market. For the other direction, I usually go back and collect data silently and analyze what can be improved step by step through iteration. Secondly, the demand put forward by the business department always starts from its own point of view, or it depends on what others are like in the market. I don't know whether this is suitable for the current development of our company, and I can't wait to tell you this function today, and I can't wait to use it tomorrow. You said you coordinated as a product. What do you think you should do? Then you should have the ability to control and judge the overall situation by yourself. You should judge what can and can't be done. Operation department, customer service department and other requirements. I have to distinguish project levels according to the company's strategic needs, project needs and product needs. Now the general project is divided into five levels, which is enough.

2. Product design stage-prototype design and business flow chart design.

In the design stage, the process of product prototype, business and product flow chart is a process of repeated communication, confirmation and adjustment. There will be controversy in this process. This function is not what I want. Not here. I shouldn't have done this. It's all problems. At this time, you should have enough product experience, have a lot of similar product thinking and have seen the practices of similar products in the market. For example, the business wants this function, but it is not complicated or difficult to do. What should I do? Is there any other way? To give a practical example, our customer return visit system wants to return to a customer in a few days, and wants to automatically prompt the customer to return in two or three days. After our own analysis, we can see that the customer management system in the market actually needs a function of returning to the schedule.

3. The prototype of requirements can be basically determined. The following is the design of interactive level of visual draft.

At this stage, there will be some arguments with designers about opinions and practices. If conditions permit, you can do user research and A/B testing. If there is data support, you can do it according to the data results. In fact, I have always said that you are right about the design level and interaction level. It's best to do something and listen to the views of users.

4. After the high-fidelity prototype is produced, it is the development stage.

At this stage, you should have PRD documents and high-fidelity prototype seat output and development to communicate and explain the requirements. At this stage, development needs to evaluate what kind of technical framework and technical voice these requirements adopt. I will encounter this function can not be done, it is more difficult to do, it takes a long time to achieve. What should I do? As a product, you need promotion to make it. First of all, I know some technical knowledge points. Before the requirements review meeting, I have to check it myself. Whether the mastery of function logic is reasonable or not, and whether the function really needs to be changed. In the requirements review meeting, when everyone is looking at your business flow chart, product framework diagram and requirements prototype, you should explain the requirements in a third-party tone and learn to tell stories. Never say that I think this function is very simple, and there is little personal subjective consciousness. Use data support and user opinions to guide requirements. Some product managers with development background are prone to make such mistakes. You can do it, right?

5. Project testing stage-professional tester testing, full staff testing.

Products will also encounter some problems in the testing stage, and sometimes they will encounter requirements changes in the testing stage, which is the most troublesome thing, and will also be encountered in the development process, especially in the development process. These requirements should be treated in two, depending on whether they can be added when the development progress allows, those big changes can not be added, and whether they can be added in the next iteration. At this time, it is necessary to take a good look at whether the previous demand research, user research, visual design, interaction have done user research, and whether there are any mistakes in the research process. Explain that the previous direction is wrong. Generally, don't add big requirements in the testing phase, otherwise the project will be in an endless state of revision. It is better to go online as soon as possible to verify the requirements and make further iterations and improvements.

At this stage, you will encounter some problems, such as what to do if the effect does not meet the actual needs, which will piss you off. Attach importance to node control and node quality evaluation and acceptance during the project. Avoid entering the next link, the project is out of control, and the project is in an embarrassing situation that it will not go online.

6. After the project goes online-the product enters the user's use stage.

Some products do not do user demand research in the early stage, and some users will feedback the wrong process path, bugs and so on. Pay attention to collecting user feedback and data indicator feedback. Some product functions have also been added, and the user utilization rate is not high, so it is impossible to promote users more. Then we have to reflect on whether the entrance is too deep for users to find easily. Or the threshold is too high. Should be adjusted in time.

In the final project, there are more than questions. As the person in charge of the product, you have to face all kinds of problems, and you have to know a little about 18 kinds of martial arts. Good at coordination and communication. Most of them look at and describe problems from an objective perspective. There is no problem that cannot be solved. Let's have a heart-to-heart talk. Let's put it bluntly, don't worry about anything. All for work. It's all a pot of porridge, and if something goes wrong, you have to be alone. Just as a product, you are just a representative. If something goes wrong, you will bear it. With glory, it is a team. You are not alone. In the process of product project development, we will face all kinds of problems. Only by thinking about the above problems will the risk point management in the process of project development be involved here. We won't talk about it this time. If there is a problem, let's solve it. Don't talk about anything else.