Excellent product managers must overcome these three challenges

As a senior product manager, I have encountered countless setbacks and gains in my work over the past few years. I feel excited when I see the growing number of users and good reviews. I also cry silently on the subway on my way home when I hear the doubts of my partners and the accusations of users, regretting my original choice. For newcomers, I, as an old bird, have only one thing to say: the career of product manager is like life. If you take it seriously, it will take you seriously. But to become an excellent product manager, you must conquer these three mountains.

◆Requirements collection and exploration stage

Every iteration and every functional point of a product is actually the result of the persistence and compromise of the product manager. First and foremost, the product manager needs to face the balance and trade-off between "user value" (commonly known as user experience) and "commercial value".

Demand is what product managers deal with every day. Product design serves demand, which is divided into the functional layer, i.e. business demand, and the experience layer, i.e. the visual, human-computer interaction and copywriting experience.

[[161675]]

Where do demands generally come from? And how do you prioritize them?

People often say that user needs are the first demand for products, but this is actually a bit biased. The first product serves the overall strategy of the company or team. Before we explore user needs, we need to confirm the target industry, field, user group and usage scenarios of the product.

For example, Taobao did not have cash on delivery from the beginning. Alipay has already well met the payment problems of users and the trust issues of merchants. With the increase in the number of users and the penetration of small and medium-sized cities, especially in areas where the Internet and online shopping are underdeveloped, cash on delivery came into being. In addition to strategy and target user groups, of course, the launch of this function is also based on data mining and analysis, user feedback and the development of competing products.

The essence of demand assessment is value assessment, which is generally as follows:

① The size of the audience, that is, the core value or the extended value; for example, the core of Baidu Maps is to find routes, and only with this can there be specific scenario-based needs such as taking a taxi and finding a restaurant.

② User usage frequency, high frequency beats low frequency. Recently, WeChat cancelled the function of pulling down to shoot short videos. Pulling down to shoot short videos is not a high-frequency demand. Data shows that the proportion of users posting short videos through Moments is as high as 95%, while pulling down only accounts for about 5%. This data effectively supports the change in demand.

③ Then there is the degree of dependence.

All of the above evaluation indicators can be judged by data indicators:

① In data indicators, we should use relative values ​​to evaluate the value of functions. Absolute values ​​are easy to manipulate. For example, if the marketing department is bought junk traffic by suppliers, it is more efficient to use per capita activation, average daily browsing, etc. to judge.

② Be more cautious when interpreting data, such as the following example which has been seen in many places.

[[161676]]

The combat commander therefore believed that the protection of the wings should be strengthened, because analysis showed that there were "densely packed bullet holes there, and it was most likely to be hit." However, the statistician had a different view, and he suggested strengthening the armor of the cockpit and tail area, where the least bullet holes were found. Because his statistical sample was the damaged aircraft returning from the coalition forces, it meant that most of the aircraft that were hit in the cockpit and tail engine had no way to return and crashed.

Requirements Review Meeting: What Should We Persist and What Should We Give Up

Trial and error is the only way. Some developers and project managers often question your design and the product functions extracted from product requirements during the requirements (PRD) review meeting. Their mantra is "If I were a user, I would not use this function, I would xxxxxx". At this time, don't be anxious, slowly explain what the background and scenario of your design is, and what purpose it achieves. If there is preliminary data as a basis, it will be more convincing; if this is just his opinion, you can ignore his remarks directly, because once he diverges, it is easy to spend a lot of time discussing and the meeting topic is unhelpful. What's more, there are thousands of types of users, we are all users, and no one can represent users.

Don't be afraid of conflict and friction. Every product participant has his or her own position and focus. Project managers hope that the number of functional points is as small as possible so that the delivery cycle will be ample. Operations personnel hope that the product functions are as flexible as possible so that the marketing activities are rich in variety, but they also hope that the operation is simple.

Therefore, we need to clarify before the requirements document:

①User object;

② What are the core functions and the purpose to be achieved, that is, what and why;

③ What are the data indicators for evaluating the effectiveness of this function, that is, what is the value? Sometimes the big one is a strategic goal, and sometimes it is just a small product goal within a certain period of time. Both must be reflected in data, such as the number of monthly investors, the number of daily double-jump UVs on the website, or the weekly investment amount);

④What is the reason for designing this function point and the historical data used as the basis;

⑤ If I want to reduce a function point, which function point will I abandon or lower the priority of? Ask myself twice in a row. This is what I am used to, because I am a product manager who likes to "be greedy". You can just take a look at it.

After these are prepared, we will explain the first 4 points at the beginning of the review meeting, so that the review meeting participants will also have a macro understanding of the requirements. Then we can further explain the product functions, processes and interactions.

What to say and do during the review phase

Don't say hurtful things. Insulting dirty words are strictly prohibited. You can speak fast and raise your voice appropriately, but you must discuss the controversial points based on the facts. If you make others unhappy, you can explain and apologize after the meeting. In fact, in every fight and "killing monsters and leveling up", my verbal expression ability, persuasion ability, on-the-spot reaction, and decision-making judgment ability are all improving. When you accumulate to a certain level and establish "prestige" among product-related personnel, you will be accepted by them, and what you say will make people more convinced. This requires a process.

The PRD review meeting is to review your product logic, user scenarios and demo drafts. It is very targeted. Don't just treat it as a debate and rely on eloquence to decide the winner. If you really can't come to a conclusion, you can put it aside. If you must come to a conclusion, my suggestion is that you must trust the technical staff from the perspective of technical implementation, and listen to the professional advice of the designers for user experience design, because all arguments will be proved by data later.

The requirements review meeting must be attended by developers and testers. It is not enough to have only the development leader or project manager attend. This is because only the developers and testers who are doing the execution on the front line can provide feedback on the real status quo and the time required. Sometimes the details they think about go beyond those of the product manager.

Evaluation of development time

My experience is that as a PM, I will give a schedule based on the opinions of the demand side and the operation and promotion time. Of course, the development team will definitely think that this time is tight (the probability is higher than 80%). They need to reconstruct some things and rely on the development results of other teams. In addition, they need to disassemble. Of course, the premise is that the things of product managers of other teams will not be inserted with higher priority, etc. At this time, you need to patiently listen to the schedule of the development leader and project manager. At the beginning of the running-in, it is generally necessary to communicate the development schedule several times, because often you think there is only one change point, but later at the expected time, you find that there are actually several changes in the development view. This requires a period of running-in.

Compromise on delivery time is unavoidable in the early stage. Once you understand the technical capabilities, development efficiency, and who is good at which functional module of the entire development team, you will have a good control of the development time cycle after 3-4 iterations.

It is also worth mentioning that several versions of PRD and demo drafts, even API interface definitions, etc. need to be documented. Requirements and designs will change and iterate, and documents also need to be updated in real time. If there is a personnel change, these documents can help newcomers get started faster, and can also provide early considerations and focus points for later product optimization. Of course, when you are preparing for your annual work report or even an interview, speech or book, these historical documents are a record of your past efforts and growth.

◆Iteration stage: iteration quality and iteration speed

Many people say that product managers need talent and product sense. People with a lot of ideas and quick minds are suitable for product managers. My personal feeling is that ideas and thoughts can indeed bring products back to life in many cases, but in the early and middle stages of the product manager's career development, ideas themselves are nothing, and their value needs to be clarified through wrangling and negotiation. Many people will think that few people can do it, and even fewer people can succeed.

Product managers need to follow up the development process. Every iteration feels like a race against time. Time and resources are limited. Often we have to worry about the work of a product manager while also being a project manager. It is recommended that you draw a timeline with pen and paper (you can use a Gantt chart if you are more professional), and specify what to output at what time. Use the calendar function of Outlook to remind you, so that when you confirm the delivery at a certain time, there will be no omissions. For example, 12.3 will produce the interactive draft, 12.5 will produce the visual, 12.9 will produce the API mock, and 12.16 will complete the development and send it for testing. Share this timeline with all stakeholders of this product, so that everyone can have some control over the product progress and time progress.

What impressed me most when I came to Dianrong is that this is a team with a strong engineering culture. Engineers are very proud of their own and their team's technical capabilities and achievements. Everyone has ambitious goals, but they are also down-to-earth and work on details bit by bit, working overtime to speed up the development of new features.

The business departments of many startups often use product features and lack of technology as reasons to explain the decline and bottleneck of business growth. A company I once worked for had very few product features in the early stage, but it also created sales of 18 million in one day during a big promotion. This number is more than ten times the sales of an ordinary day. I am not giving this example to make excuses for the product, but just want to say that product features are sometimes the icing on the cake. Once the core functions are available, they will be put online for verification, and data changes and user feedback will be observed to determine the goals for the next step of product features.

There is another very important point! No matter how rushed the project is, please do internal testing before releasing it! You must do internal testing! You must do internal testing! Important things must be said three times. The product manager must participate in the testing, and the product can only be put online after acceptance! This is a lesson learned from blood.

I once followed up on a small external cooperation project. At that time, there was no development environment and STG environment for testing the landing page. The demand side and the developer felt that time was urgent and the project was small, so they rushed to launch it online first and then checked whether the user experience needed to be adjusted online. Then the terrible nightmare began. The first time, the registration page banner of the main site was not replaced according to user behavior, so we quickly removed the debug. It turned out that the landing page did not call the registration API. The second time, we clicked the button on the landing page and could not get the coupon normally. We quickly removed the debug again. It turned out that there was one less parameter on this page. The development engineer had to modify it again. We release one release per week, which resulted in a delay of 2 weeks. Because the interval of 2 weeks was too old, the external partner of this activity had to notify the channel distributor of the offline promotion channel again, which took nearly 2 weeks, which meant that the actual and expected launch time of this activity was 1 month apart.

[[161677]]

Compatibility testing of different devices is also necessary. Many products are now mobile first. It seems that the PM's work is more focused, but in fact, it includes a lot of work. Tablet or mobile, iOS or Android, native page or H5 page, iPhone5 or iPhone Plus screen size, product functions and experience need to be tested and checked before and after going online.

In addition, performance testing is also required, especially for operational functions such as promotions. Have high concurrency situations been considered? What is the emergency plan? How to deal with attacks from competitors? These are not just the business of operation and maintenance students, but also require PMs to join in the preparation. A product manager's career is incomplete without encountering hacker attacks, competitor attacks, and rollbacks of functions after launch.

[[161678]]

◆Career development, interpersonal communication

Choosing to be a product manager means not only facing the entanglements of iteration, functions and requirements, but also the determination and struggles in career development and interpersonal relationships.

Making products requires strong physical strength and vigorous energy. Recently, I often need to spend 5 to 6 hours during the day to participate in meetings of all sizes, including demand communication, demand or document review, resource communication, follow-up of interactive drafts and visual drafts with project managers, progress reporting with the boss, and cross-departmental resource competition. Only after get off work and when my colleagues in the same office have left, I can quietly organize my thoughts, write documents, and summarize my shortcomings and gains. Meetings during the day and working overtime at night to write documents must be the daily portrayal of many product managers. Of course, this is also related to the fact that I just joined the company and it takes time for each department to run in. From time to time, I also remind myself that I need to improve efficiency and adjust the communication methods with different departments. For project managers with strong control, I only need to communicate well at the PRD review meeting. For developers and UEDs with many product lines and projects, I need to bring snacks and jokes to "comfort" them from time to time.

The Internet has changed our lives, and has also allowed us to hear different voices and see a variety of perspectives. Minimalism, the Golden Line Theory, anti-intellectualism, and insensitivity, every viewpoint and every culture has its own mask and position. The world is diverse, and it is precisely because these views and positions have the right to speak that the Internet era is open and valuable. As a product manager, or as a part of the Internet era, we must listen and see more, learn to understand, treat and accept. In the face of complexity, stay happy~