A mix of gains and losses from product managers who have been working in the software industry for 10 years and a mix of product managers

A mix of gains and losses from product managers who have been working in the software industry for 10 years and a mix of product managers

The so-called Time flies, the sun and the moon are like a shuttle, looking back, suddenly found that he has been debut for nearly ten years. Looking back at the roles you have previously held is not complicated. He has worked as a translator, test, development, test Director, Project Manager, product manager, and even sales personnel to visit potential customers on foot. In this case, I felt that I had to lament some gains and losses when I was a product manager. So I plan to write it down here and share it with our colleagues.

In fact, I think the role of "Product Manager" should be enclosed in quotation marks. I really want to run the market, fly around the world, and explore the needs of a German colleague, but the development team is on the Zhuhai side, and I just have the ability to communicate in English, so I am assigned to this so-called "Product Manager" role.

Therefore, if the customer concept is abstracted and encapsulated, we can also say that the German colleague is actually the customer of our product. Therefore, the product manager concept is quite extensive. You can be a product-type product manager. When the idea of a product is born and pushed to the market, you must control the entire process; you can also be a marketing product manager who can discover market requirements for products that are already being sold and then hand them over to the development team for continuous iteration.

Technical debt

This may be related to the special nature of the "Product Manager" I made at that time. I spent most of my time on our product backlog and the backlog of each sprint, we constantly discuss the requirements with the German team, refine the requirements with the team, and sort the functions in priority and discuss them with various teams, and then put it on the corresponding sprint backlog...

In the first sprint or two, the overall situation is also good, and the burning chart is not too ugly. But then the curve began to grow higher and higher, far away from the ideal curve. In the end, we had to adjust the number of originally planned 7 sprints to 10 sprints.
Later, I had a careful reflection on this issue. I thought there were several reasons, but the most important of them was the failure to promptly clean up the technical debt.

In fact, this principle seems very simple. People who have basically run agile development know the harm that technical debt brings to the project. However, at the beginning of a real project, we often rush to implement new functions because of the time, ignoring the scalability and robustness of the Code, in the end, the more tired these "Technical debts" are, the more difficult they will become to the end, and the change to a place may take a long time.

This seems to have something to do with programmers. In fact, this is not the case. It is more related to the concept of the product manager. As before, I only wanted my team to quickly complete the functions in the product backlog, but did not spend enough time thinking about the things on the product surface, there is no need to take the quality of implementation seriously. If you describe a product as a building, then I think the function is the above part of the ground that the customer sees, and the quality is the foundation hidden under the ground. You may see the Magnificent Appearance of this House, and even the toilets are automated. However, if you encounter a big storm or want to build a two-tier building, the whole building may collapse immediately.

A product manager should not just focus on the function list, but should spend more time solving the "technical debt" issues.

User Experience

I believe that no product manager will ignore the importance of user experience. When users buy your products/software, they actually buy solutions to solve their pain points. If your product has been used and the original pain points have been solved, but poor user experience has become a new pain point for them, the user's escape will not be far away.

Based on my previous experiences as a product manager and later experiences in a startup company, I found that the following errors are common in terms of user experience:

• Mistake yourself as a user: This is especially easy to happen in a startup because of the lack of experience of the company and the high self-confidence of the product manager, at the same time, because the target customers were not prematurely associated with the project in the early stages of the business (in fact, in Scrum, the user's participation was very emphasized), when a sprint started the demo, demo objects are usually the same group of people in the project. When considering the user experience of the next sprint, product managers often feel that they can change instantly like Zhou Hongyi. So the cycle starts again. After several sprints, the product goes out for a try and finds that the result is no longer a result. This error can also be called a "Waterfall" error in the agile team. This is the consequence of not allowing users to participate too early. It seems that we are running Scrum. In fact, we did break down the original Waterfall Model into several small waterfalls, and then applied the Scrum concept.
• Ignoring the first user experience: In fact, users are impatient, especially Internet product users. Your product may have powerful functions and UI rendering, but it takes a lot of time for users, you even need to read dozens of user manuals to figure out how to use your products to solve their pain points, in the end, I found that the feature that solved their pain points was buried in level 3 menus or even below. Do you still expect them to fall in love with your product?

I think the solution to these problems is also very simple:

• Early user participation:For example, what we did in a startup company was because we were doing a private cloud product suitable for individuals and small businesses, so we went to a nearby University and found some students to try and demo them, and then collected feedback. In the course of their trial, they should have a dedicated person to track the records, and the recorder cannot give any prompt to the other party. Of course, don't forget to pay the students some money. At that time, we sent the students about 100 yuan of recharge cards.
• Competitive product research: Unless you are making a breakthrough in this product and there are no similar products in the industry, you can certainly find some products with similar functions at home and abroad. Here, you may say that you copy shameful words. Here, I can only say a low-key phrase. If you pretend to be a saint in front of me, do not use QQ now, let's talk to Lao Tzu about the shame of plagiarism! Here, let's hear what legend Shi Yuzhu says: "plagiarism must not only be cheeky, but also be developed and optimized. If you copy the file and surpass the other party, others will not say you copy it. "As a product manager, What you often do is to constantly study other products, rather than simply focusing on the product backlog, what we will talk about here is not only about the user experience, but also about the adjustment of other functional points, because the current information is instantly available. This is also described below.

Support sales team

Here we will start with another Housing Management System for second-hand houses. Currently, second-hand housing agencies use a lot of commercial housing management software such as house xxx (this is not called here), and will upload their housing data to the software supplier's own data center. The housing information is actually the lifeblood of an intermediary, so they prefer to put this data center in their own company. So what we did at that time was to provide a data center server and a corresponding suite of housing management software. The management software supports PC and mobile terminals.

After the MVP came out, he began to run various second-hand housing agents for demo to collect further information. The problem arises. As mentioned above, users are impatient, whether you are talking about things or looking at reality. However, it still takes a lot of time to rack up the entire server. Others also need to make room for you and provide network access. what's even more embarrassing is that this is a very early product, when running in your company, it is generally normal. When running in a home environment, it is not the problem or the problem. In the end, many customers interrupted the demo on the grounds of being busy.

In fact, there is no need to give the entire environment to the architecture during the first demo. It is completely possible to graft a server simulator under the data control layer, in this way, your data does not have to interact with the data center through the network (this involves the MVC layered architecture-model/View/control, if you have any questions, please Baidu ). After this is done, when the sales staff goes to the demo, they only need to show the server appearance to the other party, you can install the software on your computer without accessing the server for demonstration. The process only needs to indicate to the other party that the data is stored in the data center through the network in real conditions, but it is temporarily stored locally for the convenience of demo.

Therefore, the product manager should not only consider the actual product release, but also how to facilitate the demonstration by the sales team, especially when the product gets user feedback in the early stage. Otherwise, if you do not have enough user feedback, you will eventually go back to the old road of closed doors.

By default, the architect or project manager will help you consider these difficulties encountered by the sales team. This Product is yours (in fact, in Scrum, the Product manager name is "Product Owner, project managers, architects, and other team members are only responsible for implementing the product backlog you handed over to them within the expected time.

Competing product analysis

I mentioned this when talking about the user experience above. A product manager should always pay attention to the market dynamics and the trends of competing products. For example, the cloud products we made at the beginning made such a mistake. At the beginning, it was difficult to find competitors in the market. The front line began to grow too long, and features continued to overlap. The products were delayed in launching the market. One day, we suddenly jumped out of a piece of news, "Baidu cloud 1 T permanent capacity first enters the era of cloud space T", and our hearts have been cool.

Of course, in fact, the reason why our products were not launched into the market at that time is complicated, but there is no doubt, one of the reasons is that the analysis of market dynamics and competing products is insufficient.

Therefore, as a product manager, you need to keep an eye on all sides. Maybe the emergence of a new competing product version requires you to adjust your product implementation strategies immediately.

You must know that a product manager should not only know how to constantly add new functions to the product backlog, but more importantly, you must constantly add new value to the company.

In addition to the points mentioned above, I think there are still many points worth optimizing when I was a product manager, for example, how to grasp the priority sorting of Function Points (three bucket principles should be mentioned here. For details, refer to my previous article "how to create a great product" translated). function optimization, product scalability control, team interaction, cooperation with the project manager, etc. But for the time and space, let's talk about it for the moment, we may continue to elaborate in the future. Of course, I also hope that you can express your views in the comments.

Reminder: For more articles, follow the public account:TechgogogoOr the official website www.techgogogo.com. Of course, you are also welcome to directly (Zhubaitian1. You are welcome to repost the message. Please retain the public account and other information during reprinting.

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.