This diagram means that if it takes only 1 unit time to correct an error in the requirements phase, it will take 5 times in the design phase, 10 times in the coding phase, 20-50 times in the testing phase and 200 times in the operation and maintenance phase. In fact, the reason is very simple. After all, the demand phase is just an armchair strategist. With the deepening of the development stage, there will be more and more artificial products, more and more things that need to be changed and overturned, and the cost will naturally be higher.
Because users are at different levels of the organization, it is inevitable that blind people will touch the elephant, resulting in one-sided demand and even different users have different views. Because of this, we also need to analyze and sort out the needs of users, so as to sort out a more accurate description of the needs. For example, for a product with 100 users, if the demand only affects 1 user (don't tell me this user is the boss), and the demand is contrary to the interests of other users, then it can be considered that the demand is rejected.
Product managers often get such an answer when communicating with the company, but we have to understand whether the "demand" or "solution" cannot be realized. Comrade Lao Li has made it very clear in his article (moved by interest: /s/MQ mr5 jgb DSR-npmtdw 8 aa), and I'm here to convey my understanding with "Buddha offering flowers". Demand can be compared to a goal, and once it is determined, it will not be changed at will. Scheme is the way and path to realize demand, and there is usually more than one scheme to realize demand. For example, there are many ways to eat. We can choose to order takeout according to our own situation, eat in the canteen or simply go out to eat. We can decide whether to eat simple fast food or delicious food according to the money in our pockets.
Therefore, the evaluation of needs and schemes should start from different latitudes. Theoretically, the demand assessment is the work of the product manager, while the scheme assessment is jointly completed by the product manager and the development company. The evaluation of demand should be considered from its rationality, frequency and value, while the scheme should be evaluated from the perspective of feasibility, including difficulty, cost (input resources and time) and so on.
When evaluating requirements, we can temporarily ignore the implementation scheme and only look at whether the requirements are reasonable, the frequency of occurrence and what value they have produced. Once the requirement itself is determined to be reasonable and valuable, the implementation scheme will be considered. Otherwise, in the face of a "false demand", no matter how perfect the scheme is, it can't play its value. When looking for a solution, always remember that the solution is a service demand, and the perfect solution is not necessarily the optimal solution. We should also consider the difficulty of the scheme and the balance between the resources invested and the time cost. Take JD.COM 618 for example. If a demand is to meet the promotion activities of 6 18, and the schedule of development and evaluation is already after 6 18 in order to pursue a perfect scheme, then this scheme has deviated from the original intention of the demand.
Great product managers are not satisfied with just waiting for demand, but should create demand, find demand and meet demand. Create products according to demand, improve products and services, and be a demand creator. The real demand has nothing to do with traditional marketing methods. Creating demand is to create an understanding of the emotional demands of people and users. The process of creating demand is the process of demand management, and it is also the process of information collection, synthesis, storage, processing, mining and value creation. The real demand is hidden in the relationship between human factors and a series of other factors.
Finally, I recommend a book "Demand-the Fundamental Power to Create Great Business Legends".
End.