Article directory
Demand often comes from pain points. When we find a pain point, we use user research to discover the huge market behind the pain point. At this time, we need to find out which part we can solve and understand the needs of this part of users. This The process is the process of defining user needs. In this process, we need to figure out the user roles, usage scenarios, and user problems. The combination of these three aspects is what we often call user needs.
After we figure out the needs of users, we need to provide a product solution to meet the needs of users. When providing solutions, we can not only consider the needs of users, but also need to consider the needs of strategy, the needs of the boss, and the needs of product operation. Demand, business personnel demand, competition demand, as a product manager's own value demand, etc. Based on these demands, we will build a product. In this product plan, there will be many product functions. This function is what we often say about the product. Demand, see the figure below:
When we confirm the product demand, the product enters the implementation stage from the demand stage, and the next step is how to manage the product demand. Requirements management is divided into three parts: delivering requirements, developing requirements implementation plans, and managing requirements changes.
delivery demand
The product manager cannot fully implement the product plan on his own. It is necessary to coordinate R&D, testing, design and other staff to jointly complete the product requirements. At this time, we need to sort out the product requirements and communicate them to those we need to coordinate. People, this process is the process of delivering requirements, which is completed in two steps: submitting requirements and reviewing requirements.
Step 1: Submit your request
Submitting requirements is to fully and clearly inform the small partners who need to cooperate with the product requirements, so that they can clearly understand the requirements of the product, generally through the following four deliverables:
1. Flowchart
(1) Business flow chart
It is designed based on business logic and generally includes main processes and functional modules to illustrate the business logic of the product, as shown in the figure below:
(2) Functional flow chart
It is designed based on user tasks, including user roles, key nodes of the operation process, status, judgment, results, etc., as shown in the following figure:
2. Structure diagram
(1) Functional structure diagram
Sort out the product function points, as shown in the figure below:
(2) Information structure diagram
The product information structure diagram lists the information fields required by the product, the content displayed on the page when drawing the prototype diagram, and the reference basis for the programmer to design the data structure. As shown below:
3. Prototype
The prototype diagram is a display description of the product interface information structure, jump logic and interactive functions. Through the product prototype, the abstract product can be concreted to make the product easier to understand. The product prototype is generally composed of wireframes, and in most of the industry People use axure for production. Some companies have interaction designers, and the prototyping work is undertaken by interaction designers. Most Internet companies do not have interaction designers, so product prototypes are generally completed by product managers, as shown in the following figure:
4. Product requirements document
The product requirements document mainly describes the detailed requirements of the product in the form of text. It is used in conjunction with flowcharts, structural diagrams, and product prototypes to illustrate product requirements. The core content is to implement each product function and user role, interface, process, The interaction, logic, rules and other contents are described in detail, mainly for R&D personnel, using word to write and read.
Step 2: Requirements Review
After submitting the product requirements, it is necessary to organize research, operation, design, testing and other personnel to review the product requirements. During the review process, the product objectives, background, problems, ideas, solutions, etc. are introduced. The purpose of the review is to In order to make the product more perfect and more feasible, another purpose is to allow all the personnel involved in the implementation to recognize the product requirements and reach a consensus on the goal. Only the product requirements that are recognized and reviewed by all the participants can be developed, and the review is the product A very important part of the work, if this part of the work is not done well, the probability of friction and modification requirements in the development process is very high.
Develop a demand implementation plan
After the requirements review is passed, the implementation can begin. Before the implementation, it is necessary to work with the specific executor to determine the implementation plan, which generally includes the following situations.
1. Determine the development plan with R&D
Mainly include:
Who will do it?
When do you start doing it?
When will it be done?
When is the test?
When will the beta version go live?
When is the official version online?
2. Determine the UI design plan with the designer
Mainly include:
Who will design?
When did you start designing?
When is the main style coming out?
When will the design be completed?
3. Determine the operation plan with the operator
Mainly include:
Who will run it?
When will the trial operation start?
Operational planning and resource preparation?
Here are three things to pay particular attention to:
1. Identify stakeholders
The realization of each requirement must be specific to a certain person, and it cannot be specious, otherwise, no one will be found if there is a problem in the end;
2. Identify the key time points in the work
For example, when will R&D start, when will it be tested, and when will it end?
3. Risk factors should be considered in the plan, and ways to avoid it should be discussed with the executive members in advance
For example, in the planning arrangement, considering the following factors such as demand changes, personnel changes, and technical implementation difficulties, the schedule should be looser, so that there is time to adjust if unexpected situations occur. The partners discussed using the 10-minute standing morning meeting every day to control the work content of the execution process, and asked everyone to talk about the progress of the previous day's work, whether there was any delay or if there was anything that could not be solved by themselves, and then talk about today's work Work plan, whether there are any difficulties and need help, by controlling the work content and progress of each day to ensure that product requirements can be realized according to the plan, this method is used in many Internet companies.
Manage demand changes
After the requirements review is completed, the product will be sealed, and the demand pool will be frozen. No matter what the requirements are, they will not be added to this version. In principle, the requirements cannot be changed, but sometimes due to some objective factors, the requirements Changes are unavoidable, such as changes in the market environment, ill-conceived before, functions are forgotten, technical implementation is more difficult than estimated and other factors, so managing product requirements changes is also an important task of product requirements management, the following Describe how to manage requirements changes.
1. Analyze the needs
There are three common types of requirement changes: adding, deleting and changing. When a new requirement is generated, first we use the method of requirement analysis mentioned earlier, from pain point - user requirement - product requirement - to the review process. Analyze the demand, confirm the value of the demand, and see if the demand is a real demand or a pseudo-demand. Only reliable requirements have the need for changes and the meaning of discussion. Here, it is necessary to prevent changing the demand from pat on the head, and pat the head once or twice. Yes, you can often change your needs at will, your credibility will drop, and your ability will be questioned by colleagues.
2. Analyze the feasibility of changes
Changing requirements usually means adjusting resources, reassigning tasks, and revising previous work results, sometimes at a high cost. If requirements are changed at every turn, the project may never be completed on time. To change requirements, we can start from the following Two aspects to evaluate:
(1) Consider the cost factors brought about by changes in demand
Requirement change means that a lot of work needs to be done outside the plan, and extra work requires additional investment. If the development of the product that can be completed in 2 months, after the requirement change becomes 3 months, it will be an extra month. The investment of manpower, material resources and financial resources, whether it is a large company or a small company, each project has a budget. If the budget is overrun due to changes in requirements, even if the product development is completed, it will not be worth the loss. Therefore, when evaluating whether the requirements need to be changed, consider The size of the cost of the change.
(2) Consider the opportunity cost of the market
Most demand changes will affect the launch time of the product. The launch time of the product directly determines the time to put it into market operation and promotion. If a favorable time window is missed, the product is perfect, but it also loses the advantages of market promotion. Opportunity, this is also not desirable, so when considering the change requirements, we must also consider market factors, not just look at the function.
3. Change requirements
After careful analysis and evaluation of the changed requirements, it is finally determined that a requirement change needs to be made, and then the requirement change can be implemented. At this time, two aspects of work need to be done:
(1) Adjust related documents
The product manager needs to adjust the product process, functional structure, prototype diagram and requirement document after the requirement has been changed;
(2) Communication and coordination
Coordinate relevant participants, inform them of demand changes in a timely manner, and let them make corresponding adjustments to their work in a timely manner.