Ten years of software industry product manager's gain and loss

The so-called time flies, Riyuerusuo, twilight look back, suddenly found that their debut at the beginning will be nearly 10 years. It is not trivial to look back at the roles that you have held before. Once worked as a translator, test, development, test supervisor, project manager, product manager, and even made sales, hiking on the streets to visit potential customers. Here I feel the most let oneself lament is that year when doing product manager of some gains and losses. So here is going to write down and share with the peers.

In fact, before the "Product manager" This role, I think it should be a quotation mark. Because the real to run the market, to fly around the world, to tap the demand is a colleague in Germany, but the development team in Zhuhai, and I happen to be able to communicate in English, so I arranged to this so-called "product Manager" role up.

So, if the concept of the customer to the abstract encapsulation, we can also say that the German colleague is actually our customer of this product. So, in fact, the concept of product manager is more generic. You can be a product manager, a product of the idea of the emergence of the final to the market to reach the customer's hand, the whole process you have to control; You can also be a market-based product manager, to explore the market demand for products that are already being sold, and then hand them over to the development team for continuous iterations; and so on.

Technical debt

It might have something to do with the specifics of the "product manager" that I was doing, and I spent most of my time on our product backlog and on the backlog of each sprint, constantly talking to the Germans about the needs, constantly refining the needs of the team, Take the stress out of prioritizing the functions and discuss them with each other, then put them on the corresponding sprint backlog ...

In the beginning of the one or two sprint in fact the overall situation is OK, burndown chart is not too ugly. But then the curve began to tilt more and more high, far away from the ideal curve. Eventually it had to be adjusted to 10 sprints from the 7 sprints originally planned.
Later on this issue have a careful reflection, the reason, I think there are several, but the most important thing is not timely to the "technical debt" to clean up.

In fact, the truth seems simple, and basically people who have run through agile development know that technical debt hurts the project. But at the beginning of the real project, we tend to rush the time to implement the new features, and ignore the code extensibility and robustness, and ultimately these "technical debt" the more tired the higher, the more to the back of the discovery of the disaster, modify a place may be reaching.

It seems to be just a matter of programmer, and it's not, it's more about the idea of a product manager. Like me, I just want the team to quickly complete the function of the product backlog, and not spend enough time to think about the product surface below the things, not to seriously grasp the quality of the problem. If a product is described as a building, then I think the function is what the customer sees above the ground, and the quality is the part of the foundation hidden beneath the ground. Maybe the house you're looking at now looks grand and full of features. Even the toilets are automated, but once you hit a big spot, or if you want to add one or two floors, the whole building may collapse immediately.

The so-called haste, a product manager should not just stare at the list of features, but also should spend more time to solve the "technical debt" these things.

User Experience

I believe that no product manager can ignore the importance of user experience. When users buy your products/software, what they actually buy is the solution to their pain points. If you use your product, the original pain points resolved, but the bad experience has become their new pain point, the user's escape is not far away.

Based on my previous experience as a product manager and later in a start-up company, I found that there are a number of mistakes that we can easily make in terms of user experience:

• mistake yourself as a user : This is particularly likely to happen in a startup because of the lack of experience of the enterprise itself, as well as the overconfidence of the product manager, and also because the early days of the startup did not associate the target customer prematurely with the project (in fact, in scrum, the user's involvement was emphasized), So when a sprint starts the demo, the demo object is the same as the project's people. The product manager, while considering the user experience of the next sprint, often feels as if he can be as small as Zhou Hongyi instantly. So the cycle, a few sprint down, the product to take out a test of water, the discovery is a dead end, the result is no longer results. This error can also be called a "waterfall" error within an agile team, which is the result of not getting users involved prematurely. It seems to be running scrum, actually breaking down the original waterfall pattern into a few small waterfalls, and then applying the concept of scrum to be famous and not real.
• ignoring the first-time experience : In fact, users are very impatient, especially the Internet product users. Your product may be very powerful, the UI rendering is very vivid, but users have to spend a lot of time, even to read your dozens of page user manual to figure out how to use your product to solve their pain points, and finally found that the solution to their pain point of the function is buried in the level three menu or even the following, And do you expect them to fall in love with your product?

The way to solve these problems I think is also very simple:

• let the user get involved as early as possible: For example, we were at the start-up company, because we were doing a private cloud for individuals and small businesses, so we went to the nearby university to find some students to play and give them demos, and then collect feedback. In the course of their trial to have someone to track records, and the record person can not give each other any hint. Of course, finally don't forget to give the students some pay, we were to send students about 100 of the credit card.
• Competitor Research : Unless you are doing this product is very groundbreaking, the industry has no similar products appear, otherwise you can certainly find some parts of similar products at home and abroad. Here perhaps you will say plagiarism shameful words, here I can only low-key say, you ya less in front of me to install saints, have the ability you do not use QQ now, again to talk to Lao Zi about plagiarism shameful problem! Here we listen to the legend Shi Yuzhu How to say: "Plagiarism not only to thick-skinned, but also to develop and optimize." If you copy, but also beyond the other side, others will not say you copied. "So as a product manager, what you often have to do is to continue to study other people's products, rather than just staring at the product backlog of three acres, and here is not just the user experience above, but also other functional points of adjustment, because now information instantaneous change. The following is also explained in this regard.

Support Sales Team

Here is also a second-hand housing for the housing management system that we were doing. The current secondary housing intermediary with more than the room XXX and other commercial property management software (here do not name), will their listings data to the software provider's own data center. And listings information is actually the lifeblood of an intermediary, so they want to be the data center in their own company. So what we did was to provide a data center server, and a corresponding set of property management software, management software support PC-side and mobile.

After the MVP came out, began to run a variety of secondary housing intermediary to carry out the demo to collect further information. The problem is, as mentioned above, the user is impatient, whether you say the hype, or see the truth. But will the entire server rack up still need a lot of time, others also need to deliberately give you space and provide network access, and more embarrassing is, because this is still very early products, run in your company is generally normal, run to someone else's environment inside a run, not the problem is that problems. In the end, many customers interrupted the presentation by doing something busy.

In fact, there is absolutely no need in the first demo when the entire environment to structure, can be completely under the data control layer of a server emulator, so that your data do not have to interact with the network and the data center (this involves the MVC layered architecture-model/view/control, If there is unclear please self-Baidu). After doing so, the salesman to the demo only need to show the appearance of the server, you can not access the server directly in the case of the software installed on the computer for demonstration. The process only needs to indicate to the other party that the data is stored in the data center via the network, but is now temporarily available for demo purposes.

So the product manager here has to consider not only the actual product, but also how to make it easier for the sales team to demonstrate, especially in the early days of the product to get user feedback. Otherwise you do not have enough user feedback support, and eventually went back to the old way behind closed doors.

The default architect or project manager will help you think about the difficulties the sales team is having, and this product is yours (in fact, in scrum, the product manager's name is the product owner, which is the owner), Team members, such as project managers and architects, are only responsible for fulfilling the backlog of products that you hand over to them within the expected time frame.

Competitive product analysis

The above talk about the user experience when it comes to this point, a product manager should always pay attention to the market dynamics, pay attention to the trend of competitive products. For example, we started to do the cloud products made this mistake, the first market on the difficult to find competitors, the front line began to pull too long, the function is constantly superimposed, the product has not launched the market. One day suddenly jumped out of a news, "Baidu Cloud 1T permanent capacity first into the cloud space T era", our hearts a few of the book has been cold half.

Of course, the fact that our products did not launch the market for a complicated reason, but, undoubtedly, the market dynamics and competitive analysis of the strength and grasp of the lack of is one of the reasons for not to be ignored.

Therefore, as a product manager, to the eyes of the moment eight ears to listen to the quartet, perhaps the new version of a new feature of the appearance of the competition, you need to immediately targeted adjustment of their product implementation strategy.

It's important to know that a product manager shouldn't just know how to add new features to the backlog, but more importantly, keep adding new value to the company.

In addition to the above mentioned points, in fact, I think before the product manager when there are a lot of places to be optimized, such as the function point priority ranking grasp (here specifically to mention the three barrels of the principle, specific please see I translated an article "How to build a great product"), Functional point optimization, Product extensibility, team interaction, cooperation with project managers and so on, but limited to space and time, for the moment to say so much, perhaps in the future will continue to elaborate. Of course, I also hope that you crossing can say your views in the comments.

Reminder : More articles please pay attention to the public number:Techgogogo or official website www.techgogogo.com. Of course, you are also very welcome to pick up directly (zhubaitian1). Welcome reprint, please keep the public number and other information when reproduced.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Ten years of software industry product manager's gain and loss