As a product person, how to better respond to changes in demand?

How to develop a rigorous project plan for Product Manager say It may not be the hardest thing to do in the project, and it is the most troubling place to deal with the situation outside the Plan. In the actual progress of the project, uncontrolled demand changes often bring heavy burdens and unforeseen risks to the Project. therefore, designing a set of appropriate requirements change management processes and specifications is essential for project and project Managers.

problem Analysis

First of all, I do a brief introduction to the Project: product level, we are a C -terminal products, The demand is mainly from the operation and planning, the product phase is in transition, at this stage mainly to explore the main new functions; project level, because the function is more complex and large, can cut space is small, so each version cycle is longer (each version of the product preparation cycle, the development cycle is about three working days), from product design to research and development and on-line backbone processes are available, as follows:

The author defines the requirements change to include two levels, one in the product design phase: the end of the requirements review, PRD the document is finalized and then changes the requirements, defined as requirements change, second, research and development scheduling end, the final development test on-line plan, after all the unplanned changes are defined as requirements Change.

< Span style= "font-family:calibri;font-size:16px;" >

< Span style= "font-family:calibri;font-size:16px;" > question one: change multiple : first, The biggest problem with the project is a lot of changes in demand, If it's just a big plunge into the process, it's a waste of time, so let's try to analyze the reasons for these changes and see if we can block the changes at the Source. After judging, a significant portion of the change was found because in the subsequent stages of discovery, and then start to modify or add new Requirements.

Question two: change is not the norm : Change is unavoidable problem, we sit down to chat, if it feels good then make this change, this is our previous Practice. however, due to the lack of a clear basic process specification, when a change occurs, the handling of things is often absent-minded, and the following problems arise:

． change demand raised too many people don't know who to listen to

． the change is too late, leaving the project with little Time.

． whether changes are done or not, and when to do so, information is not synchronized between roles

Problem three: The problem poses a risk : The project is too focused on discussing the change itself and the significance of the change, often ignoring the fact that implementation changes often impact the original plan, the lack of a complete risk analysis, when the change implementation, there is no relatively fixed routines and patterns, The implementation process is very loose, lack of some effective monitoring, process risk evolution is unclear.

Solution solutions

When we give the solution, we also need to note that the project management relies on the process and the specification is too strong to make the project operation cumbersome and inefficient, but too weak to make the project slack and Lax. therefore, the design of the corresponding methods need to fully consider a variety of options, choose the simplest way to achieve standardized management.

< Span style= "font-family:calibri;font-size:16px;" > for question one, we decided to optimize the original backbone process, Add a connecting link to make demand confirmation We regulate how changes are approved, how changes are performed in two processes To establish a way to monitor the Project's tolerance to changes in workload

backbone Process Optimisation

according to practical experience on the project, it is found that the requirements review alone cannot fully guarantee that the demand party clearly clarifies all the requirements and that the parties fully understand the requirements the Essential Reason is that PRD does not fully describe the entire scene, and many requirements levels of detail and concatenation may still be incomplete even after the requirement review is Complete. only with the interaction designer to perfect the requirements of the structure of the logical diagram and the scene description, often will find a beginning demand design is not in place, in the case of large version, wait until the entire interactive manuscript is taken out to make changes, change the cost too big / feel also Bad.

therefore, for the more complex design, before the interactive review will be divided into a link to do a review of interactive main scenes . Through the new links, to ensure the sound and perfect demand, reduce the flow of demand changes in the subsequent stages of the Quantity.

This approach applies to planning changes PRD frequent, as well as features that are too complex to accompany large potential change risks in two Scenarios. PRD Frequent changes are not entirely due to functional logic design loopholes, There may be product planning / Business Analysis and other pre-process is not done, in this context, it is useless to add a master scene review, the reader needs careful analysis.

Such an interactive main scene of the review, the specific operation recommendations are as Follows:

． time : This link is arranged at the end of the requirement review, before the interaction review begins, and the proposal is arranged as soon as possible after the requirements review, about 2 business days;

． content: Interactive Understanding Planning PRD, the initial production of interactive manuscript, granularity to reach the main scenarios and complete logic flow, and then convene the main scene review and planning / demand side to confirm, to ensure that the needs of the correct understanding and needs of the Sound.

． participants: demand-presenting Parties (E.G. operations, markets, etc.), planning, interaction

Change specification Clear

the specification of the change process covers two main areas, the first is to define the basic concept of change management, and the second is to identify the steps that need to be executed in order to make changes .

concept of management change >>

< Span style= "font-family:calibri;font-size:16px;" >

< Span style= "font-family:calibri;font-size:16px;" > first analysis of product phase characteristics: we are in the product transformation such a new and old intersection (simple is to maintain the original function, on the other hand more need to explore the design of new features), So the change in demand for this period can be divided into four dimensions: > original core function change > version on-line time > > Original Peripheral function change

< Span style= "font-family:calibri;font-size:16px;" > at the same time, it is not recommended because the emergency needs change to delay the established time, for the project, on-line time is a very serious thing, can not easily change, is the goal of common Protection. therefore, we define the point at which demand changes are frozen and, in principle, do not accept any changes after Freezing. As to how the demand freezing point is set up, different projects need to be analyzed according to the actual situation, for example: point as a frozen spot, and this time is usually about two days before the point of Measurement)

In response to the overall idea of change, in addition to the above practical experience summed up the basic ideas, but also suggested that conditional projects try to set a fixed time to develop iterative time, the cycle if it can reach two weeks an iteration is the most ideal. We also try to iterate one week at a time when responding to changes in demand is significantly more leisurely, but the application scenario is limited, and fine-grained optimization needs are the focus of iterative Processing.

steps to perform the change >>

In fact, how to implement the change, and there is no static routine, but the structure is actually still the same, I give some of the Project's practice for your reference:

． the demand side proposes a change (it is recommended that the same role set by one person to make changes, such as the Operation / market need to specify the unique output requirements change of the interface person), planning to assess the need for change, the proposed change of the plan (recommended change unified by the current version of the plan responsible for the unified collection and Output) ; If you need interaction design, you need to discuss the implementation scenario with the Interaction.

． Planning Notification development, Development students to assess the workload of change, in general, development and planning together to determine whether to implement changes in the current version, if the opinion is not consistent, you need to submit the responsible stakeholder approval decision, But this situation is often less, most of the situation is to rely on product and development to tear a Conclusion.

< Span style= "font-family:calibri;font-size:16px;" > Pk pk Failed changes into the demand pool, Rearrange priorities in the Pool. For the pk

< Span style= "font-family:calibri;font-size:16px;" >   > we're using Jira dashboard review confirm changes in the queue, complete the changes in the allowable range of the project in order of priority + can be changed, the end result may be this: unconsciously, the changes in the queue will slowly increase, one by one without detailed estimates of small points converge into a larger risk.

< Span style= "font-family:calibri;font-size:16px;" > summary

finally, In addition to grooming strategies and process specifications to manage changes and implement changes, it is also necessary to select the right time to guide the team reasons for changes to the disc , continuous improvement of policy and process Specifications. the need to eliminate interference factors, focus on high-frequency changes and analysis of the nature of the production . In addition to supporting continuous improvement, forming a closed loop of the process, it also helps the team to reach a consensus on the reason and solution of the change, and improve the execution of the team management change and the execution of the Change.

Source: Everyone is a product manager

As a product person, how to better respond to changes in demand?