How product managers control the progress of product development

Product development is undoubtedly a complex thing , In its “ I don't know ” The process of , Which are the most critical stages , Managing those core processes well can help improve the competitiveness of products ？ In this paper , The author has revealed the answers to these questions for us .

01

It is said that , There is a data in the field of software development ,50% The progress of the above projects will be delayed , Most new product development projects are like “ Step on the watermelon skin , Where to slide is where ”, There are very few R & D projects that can be completed according to the plan .

Above, 《 How does the product manager plan the product development path 》 It explains why we always release the wrong products , The next step is to solve the problem of R & D process management , Especially the R & D projects of new products .

The first question is ： How to grasp which key nodes can effectively manage progress ？
The second question is ： What are the pitfalls in the R & D process , And how to solve these pits ？
The answer to the first question , It looks very obvious —— It is nothing more than the management of key nodes , stay PMP The management concept of is the input to key milestones 、 Output management .

Famous software engineering expert B.Boehm stay 1983 Seven basic principles of software engineering were put forward in , Three of them are ：

Strict management with phased life cycle plan .
Insist on stage review .
Implement strict product control .
The fourth is —— The results should be clearly reviewed .

The software development process is divided into several stages , Make the task of each stage relatively independent , You can collaborate with different roles and responsibilities , Thus, the difficulty and complexity of the whole software development process are reduced .

Each stage can adopt scientific management technology and good technical methods , And before the end of each phase, it can be reviewed from the two dimensions of technology and management , Only after passing the test can we formally enter the next stage of work （ In fact, part of the work is parallel , Not a dead serial mechanism , However, whether the downstream achievements meet the set goals depends on the upstream design ）, This ensures that the whole process is carried out in an orderly manner , The quality is guaranteed , It also provides the maintainability of software products .

But the key is how to divide the stages ？

My point is this ：4 One review point and one acceptance point .

（1） Requirements review

Review of requirements , The answer is “ What is the problem we are going to solve ？” This is the key question . If you don't know what the problem is , Just try to solve this problem , It can only be a waste of time , The end result is likely to be meaningless .

This stage , It is necessary to raise questions about the nature of the problem 、 source 、 A systematic explanation of objectives and scale , Clarify ambiguities , Correct misunderstandings , Make sure users （ Customer ） Consistent with the understanding of the R & D team .

（2） Interactive review

Yes “ Interaction ” Review of , The key question to answer is ：“ In a nutshell , How to solve this problem ？”

The reason to use “ Interaction ” This word is used because only interaction is more perceptible 、 Feel the specific solution to the problem .

This stage , Flow charts are often used 、 Prototype map 、 State diagrams and other tools to describe the various possibilities of the entire product , Estimate the cost of each option 、 Benefits and experiences , Weigh the pros and cons of a heavier solution .

in fact , Behind the interaction is the interface 、 The complex logic of the data layer , This is also the most easily despised problem , Because it's invisible .

（3） Visual review

A review of vision , Is to consider how to propose a normative and consistent design language .

“ The beauty and ugliness ” It is an individual's subjective feeling , We tend to fall into “ Too ugly ” In the quagmire of . In the process of software development , Visual design needs to establish a set of professional norms and mechanisms , You can't rely solely on intuition .

（4） Use case review

Use case review is to set the measurement standard for the output , How to verify the satisfaction of deliverables and user needs .

The key task at this stage is to write correct and easy to understand 、 Easy to maintain scenario detection logic , Including various normal and abnormal data states , Logical state , Forward and reverse scene States, etc . The R & D team should review the coverage and granularity of use cases during product development , And the sooner the whole process, the better .

meanwhile , The use case itself is dynamically maintained , Update maintenance timely and reach agreement within the team .

（5） Acceptance release

Product acceptance is the result verification and archiving for final delivery , This includes collecting complete records of the project , Ensure that the product meets the needs of users and businesses , And archive relevant documents , It also includes the audit of the project .

This is the final link , It is a centralized audit process , It includes contract closure and management closure , In fact, it is also a very complicated process . There must be many people who want to complain about the history of blood and tears in the acceptance process , It is often thought that we have finished “ What to do ”, The result is not new demand , I just didn't reach the contract goal , It is impossible to accept .

Every stage of the product development process , There are significant risks ,PM We must have a clear understanding , We should also strive to make achievements in the professional field of project management .

Whether it's 2B still 2C Project , Whether it's an internal project or an outsourced project , No matter what development model your organization uses , The key nodes and key deliverables of the product development process must be firmly monitored .

02

1. Requirements review ： What to do
Requirements review , It is aimed at the collected ideas from various channels 、 opinion 、 Needs and suggestions, etc , Summarize with the right tools 、 carding 、 After analysis and sorting , The final product work to be completed at present or in the future .

Input

Demand source channel in the process of new product or product iteration , It usually includes users 、 competitors 、 supplier 、 Sales terminal . It also includes problems left over from the previous iteration or temporarily trimmed 、 function , as well as bug.

There is another important channel , It is a new design concept driven by the product itself , New technology framework .

Product managers should establish a demand pool that is easy to maintain , Collect and process data from multiple sources in a timely manner “ demand ”.

review

The requirements review stage is usually initiated by the product manager or project manager , Mainly aimed at ” The feasibility of “ review , Ensure that the team has the ability to meet specific requirements within a certain period of time , Instead of putting forward unrealistic action plans .

The tools used in the whole process include the requirements pool 、KANO Model 、 Four quadrant rule 、 Intersection analysis 、 Mind mapping 、 Swimlane diagram 、 Prototype map 、 Milepost .

Output

The final output of requirements review includes 4 A document ：

1. Updated product requirements pool ： After the requirement review, the product requirement pool list must be updated , Some demands will be rejected , Some requirements will be included in the iteration plan , Some requirements will adjust their priorities , The product manager must ensure that a complete and clear list of requirements is maintained .

2. User storyboards ： Manage user requirements in the form of scenario stories , It helps to stimulate the creativity of the team , So as to find a better solution .

3. Business process framework ： In the low fidelity stage , Product managers need to quickly present solutions to problems , Don't get caught up in details too early , Instead, try to find more solutions .

4、 Product iteration path ： Any review of requirements , It is possible to send changes to the iteration path of the product , Update the product path in time in the team , It is designed from market to brand 、 The whole process from operation to after-sales .

2. Interactive review ： How do you do it?
Requirements review , Is the process of defining the problem , Interactive review is a specific solution to the problem , The emphasis is on the product functional realization aiming at the specific problems . After interactive review of product functions , We have officially entered the development phase of this iterative process .

It is more common for us to combine the two review points , There are no harsh distinctions , But there are essential differences between the two stages .

Input

1. User storyboards ： Clear user scenarios can help teams restore real scenarios , So as to reflect on the product solutions , Enhance product experience .

2. flow chart ： Including business processes 、 Data logic and state transition relations .

3. product PRD：PRD Don't worry too much about documentation “ Four ways to write fennel ”, Prototype + The method of notes is very efficient , If you need a template , You can find it in this article ： To abandon completely WORD！ Teach you how to use Axure Fast output of high quality PRD.

4. Iterative path ： Update the product path in time in the team .

review

Interactive review , It is a solution integrity check , Including scenarios 、 Logic 、 user 、 Integrity of content , It also includes interactive closed-loop experience inspection .

meanwhile , In this should , You also need to break down complete work tasks , Evaluate the resource needs and schedule feasibility of the entire iteration process .

in fact , The assessment of progress has already started in the requirements phase , The reason why it needs to be reviewed repeatedly is based on the consideration of requirements change and solution optimization .

Output

1、 product PRD： Reviewed PRD, There may still be detailed supplements and improvements , The product manager is responsible for maintaining a complete and clear online PRD.

2、 Version milestone ： The team should use ”PBS“ Instead of ”WBS“, Specify the specific resources and time nodes for each task .

3、 Product demand pool ： Review at any stage , May bring new problems and demands , They may come from the creativity of the team itself , It helps to improve the team's sense of mission and responsibility , In some cases , The requirements resulting from the review may greatly improve the product .

3. Visual review ： What to make
Vision and interaction should be considered in two different stages , Help the team focus on solving specific problems .

Input

See... Of the interactive review ”PRD“.

review

Review of visual design , It is easier to fall into subjective intuition ,” Too ugly “ Is the easiest word to think of , It often depends on the first sensory perception , The actual user's usage scenarios are often ignored .

therefore , In the process of visual design, it is more necessary to clarify the tonality of the product , How to establish consistent and normative design ideas , This depends more on the designer's own skills and aesthetic literacy .
Output

Visual design can have an impact on iteration progress , In particular, complex animation design often requires more R & D resources and time , Product managers need to consider the input-output ratio of resources and time .

In some cases , Too complex design is easy to lose more than gain .

4. Use case review ： What are the criteria for doing well
To make end users satisfied with the product , The most powerful measure is to clearly state the expectations of end users , In order to verify these expectations and confirm their effectiveness .

Test cases reflect the requirements to be verified . But in fact , It is often difficult for us to ensure that all requirements are verified （ Test cases may not cover the full range of requirements ）, How to find the key requirements is related to the success or failure of the project .

The depth and breadth of the test , Have an impact on the project , As the number of test cases increases , The more confident the team is about product quality and testing process . The other side of this double-edged sword is , This means that it requires more resources and time , The test workload is proportional to the number of test cases .
Input

See... Of the interactive review PRD、 Visual documentation .

review

1. The business layer ： Including all scenarios involved in this iteration 、 technological process 、 data 、 Content integrity and exception handling , Compared to the use case of the forward process , Testing of reverse processes is often more critical .

The test coverage of the business layer is the core of the product , Directly determine whether the product meets the needs of users .

2. Interaction layer ： Mainly for the test of product operation experience , Including copywriting guidance 、 Operation jump 、 Navigation layout, etc , The interaction layer is the core of the experience .

3. Visual layer ： Use cases usually only detect integrity , This part tests designers rather than testers .

Output

The test case ： Use cases are metrics for evaluating test results and criteria for analyzing defects , There should be a standard document template for writing test cases , And it should meet the specification requirements of the team . The test engineer must output a complete test report at the product acceptance stage based on the use case .
As a valuable document for product iteration , Test cases need to be updated and improved , It is necessary to discover and supplement the incompleteness of use case writing in time , Minimize the possibility of missing measurement .

However , In reality, test cases are often overlooked , Even discarded at random .

2. Version milestone ： The review of test cases is likely to lead to milestone changes , Use cases themselves are more than just tests of deliverables , In fact, it is also the test of product design , At the stage of use case writing and review, defects and loopholes in the design itself should be found as much as possible , Not just for the deliverables .

5. Acceptance release ： Have you achieved your goal
Product acceptance is to check whether all work or activities within the scope specified in the project plan have been completed , Is the deliverable satisfactory , And record the verification results in a series of activities in the acceptance document .
Input

see ” Reviewed PRD“、” Visual documentation of the review “、” Reviewed test cases “.

review

Product acceptance needs to be completed many times , from debug Version to beta Version on to release Version is a complicated process .

The product manager must lead the whole process , From product function to interactive experience , And vision must be carefully reviewed , This stage should organize the development 、 Design 、 The test is right bug Scope of impact 、 Multiple rounds of severity assessment , And give specific solutions and improvement programs .

Output

The most important documents in the acceptance release phase include 3 Share ：

Version update log ： Describe specific functional updates .
2. Updated product requirements pool ： The product manager must pay attention to the problems and bug Treatment measures for , In assessing and balancing resources 、 Progress and quality , Update the product requirement list synchronously within the team , Ensure that there are clear records and planned measures for the remaining problems , Instead of trying to cover up possible problems .

3. Iteration summary ： Make a summary of this iteration , To unite the team , It is also a measure to improve the skill level of the team .

Postscript

Management of software product development process , It's about the whole process “ What has been accomplished , How to complete , How successful the result is , Good or bad ” Systematic description of , There are many theoretical systems in the whole field to help us optimize and improve our work , But there are some major challenges in software development to some extent , To make it different .

This process needs constant iteration and improvement , Don't imagine that there is a way to build a “ Utopia ”, It's improvisation , Judge the hour and size up the situation , Slowly regulate 、 adjustment , Make it conform to the various constraints of reality —— The resources of your organization 、 Strategy and culture .

Product managers are facing different products , Under different organizations , The particularity of the environment should be fully considered , The methods of process management vary greatly , In some cases, there are a lot of accidental events , You need to be ready to adapt to the extra work caused by unknown and uncertain reasons .

Different organizations , There are even completely different criteria for defining product success , Is it successful to finish on time and within budget ？ Not necessarily . Maybe it's customer satisfaction ？ For you personally , How to handle the project to achieve the goal , Make sure that the benefits of this project are more than the costs , Is a kind of success .