New products should learn to adhere to a few

As a newcomer, the work of this period of time left to their own touch more. These touches are actually relatively simple, but because of the previous stay in the level of education, and now is their own deep in which constantly collide, so these touches are more direct and real. For these touches, I personally summed up as: Product new people should learn a few sticks.

　　First, the demand for certainty: adhere to the maximum return of users

Last year internship, the face of a new product, every morning to the office the first thing is to draw the product draft. Of course, it will also contact with the user. At that time, the interview room at Teng Yun building was attended by about 10 user interviews and focus groups. The research students interviewed in the interview room, and I and the other two product managers "hidden" inside the small black House, through a single mirror and monitoring equipment to observe and listen to user feedback. The biggest feeling at the time was that the user's feedback was really different from what we thought it would be!

This year's internship, every morning to the office to do the first thing is no longer directly to draw the product manuscript, but:

1, write product update log: The day before MIUI engineers completed bug repair, functional optimization, new feature, etc. translated into the user can understand the language added to OTA log.

2, look at the forum feedback: the day before the forum users of the new product function feedback List of the mail, open the mail to see what users have suggestions, and timely reply. Every week also receives the feedback list which from the Millet handset user in MIUI "The user feedback" client.

In addition, every day will always pay attention to from micro-blog, micro-letter, QQ Group and other aspects of feedback. With the user more contact, also found that the fun:

1, learn to consider the needs: by replying to user feedback, the user forced to think about the needs of users to rely on unreliable? Is there a user scenario? Is it a large user or a long tail? How should you respond to user feedback?

2, more in-depth understanding of their products: by replying to user feedback, the user forced to go more in-depth to familiarize themselves with the product details, the user's feedback on which part of it? Why did you design this before? Do you need optimizations now?

3, really understand that "users need a faster horse, in fact, is the need for a car" story: for example, user feedback requires MIUI notes to increase the ability to save as a picture. If directly according to user feedback, the product scheme will be better, but think about what users want to save for the picture to do? Hair Micro Bo Map, DMS to their friends and so on, then the product solution may not be "saved as a picture," but "Send as a picture."

　　Second, for product solutions: Insist on more questioning and inquisitive

This is triggered by the fact that questioning and inquisitive will make the product plan a more reliable one.

The plan, the designer will not question your proposal, the program development will not have to doubt your plan, so as to better promote the implementation of the program. Therefore, before others question your product plan, or oneself more question to doubt oneself more reliable.

Before the product plan, easy behind closed doors. Although will also repeatedly to explore whether there are more programs, but generally no gain. It is important that you do not question your existing plans. Here the question I personally sum up is divided into two parts:

1, query the corresponding needs of the project is reliable: constantly ask yourself what is the user scenario of this requirement? What is the user's need for this? What would be the problem for users if there was no such solution?

2, the question whether the solution itself is true: if this program, will really help users solve his problem? Will it create new problems for users?

　Third, for project implementation: insist on efficiency first

From doing the user experience to doing PM, the understanding of the product will change. Before, to look at the product from the designer's angle, will pay more attention to the complete user experience, if this plan is not perfect, I am willing to develop. And now, I'm more concerned about whether this solution can be quickly online to solve the user's problem.

In fact, the reason is simple:

1, 0 to 1:0 to N are more reliable. 0 to 1 is the solution of the "there and none" problem, many times the solution may not be perfect, but it has been developed, and to a certain extent to solve the needs of users, it is valuable. And the other idea is 0 to N, many times will be stuck in the process of (N-1), and N only one step and lead to delay the implementation of the program. In fact, if the product n is implemented, it is possible that the user actually needs is not n.

2, 1 to n are more reliable than 0 to N. 1 solves the function "has" the question, actually is enough, from 1 to N will be more likely than 0 to N, only 1 will have users to "spit" and "advice", with these spits and suggestions, you can more smoothly to reach N, even n+1, may be M. Because you never represent the real user.