How to use mechanism to reduce risk in product management

In the follow-up of some projects, often encountered some common problems, it is a problem, the following to the summary of these issues, can also remind themselves to avoid the encounter when overwhelmed.

Problem：

1, the initial stage of the project, product principles have been meeting unified, happy, but in the medium term in the product in principle there are differences. Even when the product is facing the line, there are others to give the product new positioning.

2, product design, in the product demand and positioning has been confirmed, entangled in the "do not meet the needs, deviation positioning" design details, deadlock, waste time, drag down energy.

3, cross-sectoral cooperation projects, design department submitted work results, often by their own upper or left and right to overturn, even if the product benefits, but hurt the whole project, hurt their own.

Depending on these questions, you need to ask a lot of why.

Why the initial unification of product principles, the medium-term but there are differences in principle? What are the necessary conditions for the person who initiates the disagreement?

First need to ask the company: Product responsibility System, in the end there is no clear and implementation? In fact, the product personnel already should also, the long-term responsibility to the product, bear on their own body. However, if there is no strong recognition of the ownership of the product responsibility system at the level of the company and the director level, we will never be able to play a role in the critical moment, but only to glance around.

In the case of product responsibility system is not clear, even if the core members of the team meeting to confirm the product principles, there will never be a strong role in the product principles to carry out every stage, the initial product positioning and product principles of the meeting confirmed that there is no strength, but only on the surface of the reunification.

The reason is very simple, when all the wind and the road, all the roads to Rome, the group of tourists must follow the beauty guide on the OK. When inattention setbacks, guide even familiar with the road in the sinister, is still not unable to disguise themselves as a team of bodhisattvas, not the idea of the big guys. (Tacit understanding, can overcome this problem.) But in the big company's camp, want to cultivate a tacit understanding and complete project team, generally can not be asked. But the tacit product group still has. )

In the above case, what are the necessary conditions for initiating the disagreement? First, the long-term follow-up products, understand the initial product principles and positioning, the second is to understand the focus of the whole team and product market situation, rather than only familiar with their own department of Management. Sadly, people who are familiar with the above two points often do not make unreliable decisions and harm the whole project.

Now that you have identified the product requirements, why do you have "not meet the requirements, deviate from positioning" design details? Why waste time on such issues?

This problem appears very normal, when the designer did not do sufficient analysis of the competition, and did not fully understand the product situation, the design will always appear deviations. As long as the product staff to explain the requirements and change the reasons to persuade designers to return to demand. Terrible is "deadlocked", designers insist that the design details are correct, reliable, in line with product requirements, product personnel are unable to identify. Stalemate, should put aside the problem, and continue to promote the project, rather than on this issue of entanglement one afternoon, but also a variety of user research, application examples moved out to say.

The final decision, if still deadlocked, then who is responsible for the product long-term, who made the decision. Who is responsible for the product's long-term return?

Why the "work result" can be overturned? who gave the author "right to submit" and who gave the overthrown "right to overthrow"?

The first question to ask is: Is there no clear "confirmation level" workflow, or just verbal clarity, superficial understanding?

For example, a design draft, of course, to be directly responsible for a confirmation, no problem, and then hand over to the next step to implement. Then this person in charge a needs to assess whether or not they can guarantee that this confirmation result is the final result. If there is no guarantee, then submit to the previous level of the person responsible, let him confirm. However, if the head of the upper level has authorized the person in charge of the authorization, should not be after a has been confirmed, rashly overturned the confirmation results.

In this process of validation, it is important to make sure that the "corresponding design work requires a corresponding level of validation" before each project is implemented. Confirmation level "is not clear, the first thing should be reviewed is not the quality of design did not meet the requirements, but why there is such a process of loopholes, so that does not conform to the design quality of things to advance to the next step. If the loopholes are not blocked, they will not be eligible for repeated intervention, thus hurting the team and dragging themselves down.

On the contrary, when the confirmation level of the project design work is specified, then the submission of the design draft is unqualified and the design work is not in conformity with the process, the "right to submit" and "the right to overturn" can be clearly challenged and whether the process of "confirmation level" is met. At this time, it is the ability to adjust the level of recognition or change the person in charge, is the process of the implementation of the process, more pragmatic than the innocent of each other pretending.

Finally sigh, the product manager is a complete cannon fodder, which link problems, can be uncovered product planning and project management loopholes and scars

A product project, from the establishment, interaction, vision, development, testing and other stages, always because of a variety of problems and repeated damage. In particular, cross-sectoral cooperation, many links with the process of injury problems occur everywhere. During this process, the responsibility of the product manager is to do everything possible to avoid the occurrence of various injuries, to avoid all kinds of damage to the core members, injury and Team center of gravity.

Sadly, in most environments, humble product personnel are not only unable to anticipate all kinds of hidden problems, but also do not have enough resources and authority to prevent injury problems. At this time, the product manager, is the proper cannon fodder, the mouth a Mingshuo, ashes. Finally, the product manager still has to stand up and drag the core members who are tired of various problems to continue to push the project forward.

It is not known whether this is common in other companies. When there is no cure for product accountability and validation of hierarchy management mechanism, the deep buried problem of the inter-departmental team to develop products, and then exposed a pile of problems, over and over again to hurt each product. So the company always comes up with a bunch of discounted products, bear a pile of data and market situation, and finally blame to the product personnel, the transfer of the transfer, the job-hopping, and then recruit into the next batch of unknown severity of the thriving, so repeated, even infinite.

Key role position of the reliable cattle, is the backbone of the product

Product team, in this complex situation, the only life-saving straw is the key position of the product, with the key role control, and then such key roles need to maintain a sustained sense of mind, focus, at any stage can be traced back to the original product principles, evaluation of the current team focus and high-level requirements, Unify the actions of the executive and convince the higher-ups.

From this point of view, there is not so much process management and department coordination of small team products and start-up products, to be more secure and more reliable. A niche product in the recent group, no large resources input, no multisectoral cooperation, no high-level pressure, no strategic significance, although the choice of a difficult road, but the entire product from the design to the operation, so that outsiders see, it appears relaxation degree, rhythm clear, this is an obvious example.

As long as people are reliable, doing anything is reliable. If the person is not reliable, in any role, there will be problems. As to what the problem: the details are not in place, the document and version control logic is not clear, inconsistent decision-making, coordination members with fatigue, focus on the work of the incorrect, communication is not active ... Abound。

I wish I could be more reliable.