Product principles and Product Review Panel revelation

This article is selected from the No. 2012 year of the "programmer" magazine 04, translated by Seven Indian tribes.

Wen/Marty Cagan translation/Huang Jiewen, Tangfonnen

Marty Cagan is a world renowned product management expert who has served as vice President of Netscape and senior vice president of product management and design at ebay. And this is his review of his more than 20 years in the SOFTWARE Product management work of the summary and experience sharing, in the article he described the product development needs to follow the product principles and the need to establish a product review team.

Product principle

Product principles are a summary of team beliefs and values that are used to guide the product team in making the right decisions and trade-offs. It embodies the goal and vision of the product team and is an important part of the product strategy. From the form, it is also a series of clear, can reflect the team characteristics of the product value criteria.

Every time I join a new team, the first thing I do is make product principles. This means deciding what is important, what is not, which principles are fundamental, strategic, and which are temporary and tactical.

The product principle is not a list of product features, but is not dependent on any individual product, but is a strategic guide to the entire product line and a company's value manifesto. Good product principles can also inspire the design of product inspiration. The process of formulating product principles is also the process of learning, from which you can learn about the corporate culture of the new company and the corporate goals established by the founders. Product principles are a framework of value judgments that help companies make the right decisions.

For example, the product principle of a movie site is to believe that community users ' reviews are more valuable than those of a professional. When a studio wants to make a comment on a website, the product team can decide whether to adopt it according to the product principle. Whether the product principle is disclosed varies by company. It can be used as a guidance tool within a team, such as a product strategy document, or open to customers, partners, and investors to publicize the company's philosophy to the public. In addition, product principles can also be used to unite the product team, allowing product managers, product designers, development teams, and marketing teams to form common values and maintain a consistent understanding. This is not done with any product documentation. Note that only the list of product principles is not enough, but also according to the importance of the order of principle. All products are both easy to use and safe and reliable, but there is always a need for priority. is usability, or reliability, the most important?

When formulating product principles, the following two types of errors are easily encountered.

The principle is too vague and has lost its guiding role.

Mistake design principles for product principles. For example, to provide users with a clear navigation path (to facilitate the user to complete the next step) is a common design principle, not product principles.

If your team does not have a clear, product-related philosophy of product principles, then you should gather up and take the time to discuss the analysis to determine the value concept that the team values most.

Resolution of conflict of views

Many product managers complained to me that they were fed up with endless meetings (neither agendas nor results), and the debates and conflicts in the meeting. Executives also interrupt the process from time to time, throwing out unthinking opinions, leaving them confusing.

This situation often occurs in the product decision process, mainly due to the following points.

Each colleague has his own opinion on the product.

Everyone is very concerned about the product, understand that the company is profitable to rely on users, only products to attract users.

Many people think they know the target audience better than others.

In addition, most product teams do not have to report to the product manager, and the product manager does not have the power to manage the product team. In need of product team coordination, product managers can only put facts, reason, can not be enforced. So the product manager always felt very frustrated.

Sometimes we disagree, the stalemate, can only ask the executive to decide. This situation indicates that there is a problem with the way of communication. Product creativity in the debate can be improved, but the premise is that everyone formed a consensus. Asking executives to make decisions and resolve conflicts will exacerbate the internal contradictions of the team and outweigh the gains.

There are many difficulties in making product decisions, and it is inevitable because constructive debate and argumentation are the only way to define good products. But even with that in mind, it's hard for me to make the argument a pleasure.

In order to encourage innovation, improve the effectiveness of discussions, and reduce external interference, before making a product decision, we should first determine what the decision to solve, let everyone in the following points to reach a consensus.

What is the problem to be solved?

What kind of personas do you want to solve?

What goal does the product achieve?

What is the priority of each goal?

In my opinion, whenever there is a serious disagreement within the team, it is not that everyone is disputing the fact, but that there is a different understanding of the priority of the goal and the goal.

For example, the team should first determine which goal is most important to the user, ease of use, responsiveness, functionality, cost, security, or user privacy? Only by unifying the understanding of product goal and goal priority can we discuss the rationality and feasibility of various schemes in this consensus.

Be sure to carefully analyze the priority of your product goals (from the most important to the least important) and let the team reach a consensus. Never label all goals "critical" and "important". Be sure to distinguish between what is important and what is second.

I was often asked to resolve the controversy over product decisions and found that most teams skipped this critical step. Because of the lack of basic evaluation criteria, everyone has a different understanding of goals and priorities, and we tend to be emotionally excited, arguing over details.

Even if consensus has been reached, it should be emphasized again before the discussion begins, preferably on the whiteboard in order of priority, so that each colleague can see the exact basis of the evaluation plan and the decision making.

The process and basis for making decisions must be completely transparent and not to be judged by intuition. Be sure to tell us the basis and rationale for the decision, and clearly show every decision link.

A heated meeting will affect everyone's morale and efficiency. If this happens again, review the product goals and objectives first, and make sure you agree.

Develop more timely and reliable product decisions

Even for small companies, making decisions is often time-consuming and laborious. Product companies need a mechanism for policymakers and related personnel to make informed product decisions in a timely manner. I think the establishment of a product review panel is the best way to solve this problem.

I am usually not interested in attending meetings or committees, except for product review groups. Product Review Panel Let all decision makers sit together and make decisions to bring products to market, which can speed up the development of products.

The difficulty in organizing a product review team is to provide transparent information to the executive in making product decisions, to oversee the product process, and to avoid the specific work of the executives interfering with product teams, such as product design. Many companies have similar organizations, but I think the first person to put forward this concept is the COO Maynard Webb before ebay. Over the years, I have been in practice to standardize the product review team's specific responsibilities, improve its flow.

Work objectives of the product review team

The purpose of establishing the product review Group is to determine the strategic direction of products, supervise the research and development process of the company's products macroscopically, and allocate resources rationally. The Product Review Panel does not develop the company's business strategy, but instead puts forward a matching product strategy under the conditions of a given business strategy. The decision of the product Review panel directly affects the operation of the enterprise.

Composition of the product review team

The Product Review Panel is composed of managers of various departments of the company. Although the situation varies among companies, it usually includes the following people.

Chief executive/Chief Operating officer/Department general manager

Director of Product Management/Deputy Director

User Experience Design Director/Deputy Director

Marketing Director/Deputy Director

Development Director/Deputy Director

Website Operations Director/Deputy Director

Customer Service Director/Deputy Director

The performance of the product review team depends largely on the skills of the meeting organizer. He must be undisturbed and articulate and make decisions. In large companies, organizers are usually held by the company's product owner; In a small company, it is the boss. To ensure that each key department is represented in the product Review panel, it is best to control the number within 10 people. If more than one person participates in the jury, one person should be elected to represent the department. For example, the sales President speaks on behalf of the marketing department and the QA Supervisor speaks for the development department.

Responsibilities of the Product Review panel

The Product Review panel is not a team that designs and develops products, it is responsible for overseeing product development processes and making key decisions.

It reviews products and make decisions based on four milestones in the development of products.

1. Review product strategy and product roadmap, start work on evaluating product opportunities, i.e. select products that are worth investing in, and ask product managers to start evaluating product opportunities.

2. Depending on the outcome of the evaluation of the product opportunity, decide whether to start defining the product's solution.

3. Review product prototypes, user test results, cost estimate details, decide whether to start developing products.

4. Review final product, product quality, release plan, social effect, decide whether to release the product.

Precautions

A small company's product review team is usually responsible for reviewing all of the company's products; large companies may need to set up a number of product review groups based on the size of their business units.

The Product Review Panel is not responsible for reviewing and updating the product details. This is to expedite the processing of details, to ensure the smooth operation of the company's business.

Product panel is not responsible for specific product design work. If the product is defective, it should be handled by the product team and resubmitted to the product Review panel for review.

At Milestone 2nd, since the product solution has not yet been formed, it is not possible to estimate the cost of the product intuitively, but at Milestone 3rd, the development time and cost should be carefully estimated to prepare the company up and down.

Try to avoid the product review team to discuss the specific implementation strategy, it is time-consuming to discuss these issues. If you have to discuss, you must control the time, do not affect the product review team to oversee the main work of the product process.

Product jury meeting frequency depends on the progress of the specific product, you can open an hour per month or two hours per week meeting.

The product review team should also review and analyze the performance of the product after the listing. Products can be released after 3-6 months, the product team to report the performance of the product market, product review panel can reflect on the wisdom of the previous decision, how to adjust in the future.

At each review meeting, it is best for the Product manager to report the product progress to the product review team. Directs the Product Manager to prepare the presentation content by the product manager's direct leadership to ensure that the product manager is well prepared. Before the meeting, the product manager is best to make a brief report to the members of the product review team, the existence of questions should be resolved in a timely manner, to avoid being caught unprepared in the reporting process.

If the company is too inefficient in making product decisions, consider organizing product review groups. It can take the place of the long decision-making meetings, shorten the decision-making time, and make informed and transparent product decisions.

When to estimate project costs

Although the software industry has long had a tradition of estimating costs, it is still prone to confusing estimates until today. I think the reason for the confusion is that management always wants to get the cost information as early as possible, but it's often late for developers to accurately estimate costs (at least until a specific solution is released). As a result, either premature estimates lead to significant discrepancies between results and reality, or the results are accurate but far beyond the budget, making management difficult to accept.

The estimates presented here are derived from the product development process that I advocate, but they also solve most of the company's problems.

Before you start developing products, you should evaluate your product opportunities. The goal of evaluating a product's opportunity is to see whether the product's creative claims to solve the problem are valuable. At this point, the solution has not been released, with only product creativity and unresolved issues on hand, so the product team can only approximate the size of the project (the proposal is divided into small, medium, large three levels), and then roughly estimate the project cost based on the project size. Although the estimates differ from the actual situation, there is usually no cross level error.

Recognizing that product opportunities are valuable and that rough estimates are acceptable, management can allow the project team to begin defining product solutions. Ideally, a detailed product solution should also contain a high-fidelity prototype that is available for user testing.

In the process of defining a solution, first the product manager and the interaction architect need a developer's assistance to assess the cost of the different solutions. The product manager and the interaction designer then adjust the solution further based on the evaluation results. After the complete product documentation is formed, detailed and reliable cost estimates can be generated based on document details.

At this point, with detailed product documentation and credible cost estimates, management can easily decide whether to start developing the product. If there is a problem with the solution or if the cost estimates are beyond the budget, management can immediately call it quits. If you decide to develop a product, the product team can start working with full knowledge of product definition and cost details.

In conclusion, I propose to conduct cost estimates in two phases. Make a rough estimate of the opportunity to evaluate the product and make a detailed estimate based on the final product documentation.