(1) Before the start of the project
I have been working on products for more than a year, but I have been suffering from this or that confusion. Many people want to work on products, or their bosses have to take up the position of products themselves when starting a business, but their understanding of the position of products is not clear. I thought it was a pure drawing prototype, some thought it was doing project management to track the progress of the project, and some thought it was doing competitive product analysis for the boss to see. In fact, these are not the core and focus of product managers. In more mature enterprises, due to the expansion of products and the increase of personnel, in order to facilitate collaboration and communication, positions will be clearly detailed, such as product managers, interaction designers, UI designers, user experience analysts, data analysts, operation, etc. However, product managers in start-up companies often have multiple roles. Start-up companies pursue maximum efficiency and minimum costs, and they simply do not have the energy to divide the positions so carefully. Next, I will examine the whole process from the perspective of an entrepreneur or a product manager responsible for a product project, to see what a product manager needs from scratch.
Product from concept to output to process
Before doing anything, you must first consider the user needs, business value, and technical difficulty behind it. Your product will be used only if users have demand; only if its commercial value is established can it bring profits to the enterprise. After all, the most basic goal of an enterprise is to make profits; only if the overall technical evaluation is feasible, the entire project will be can be executed. In today's Internet startups, everyone is pursuing "fast", such as financing in two months, over one million users in April, and listing on Nasdaq three years later. But this is the appearance that everyone sees the success of other people's entrepreneurship. Everyone knows that the premise of doing anything is that you have to understand what you are doing. It is true that it is not ruled out that those who are brave and lucky can do it casually, but that is only a case. Not worth looking into.
1. User needs
1.1 Product positioning
During the implementation of the project, we often fall into a situation where a bunch of people are together, and the atmosphere of discussion can be described as high emotions. A said that the buttons in this place are not good, B said that this place should be done like other people's APPs, and C Saying that you are all wrong should be that this module should not be replaced with this one. Participating in this kind of discussion often will consume incomparably time and energy, and it will take several hours to pass, but after the meeting, I find that nothing can be achieved. In most cases, there must be a problem with product positioning. The person who implements it must clearly understand what the product is used for and who it is used for, so that they can discuss the specific details normally. If you have been discussing passionately and pushing your nose and face for a long time, you find that there is no result, and you find that the discussion at the meeting has gone astray, you might as well return to the essence and think about what our product positioning is.
Product definition: Product positioning includes two major contents: one is product definition and the other is demand definition. The content to be analyzed in the product definition includes product users, main functions and product features.
For example, if you want to start a business and develop a mobile recruitment app, what should you do first as a product manager? China's annual employment population is very large and there are various industries. Then you have to think about what kind of people your products are intended to serve. If you want to serve people in all industries, it is impossible. First of all It is very difficult for a small company to integrate recruitment information in so many industries, and not everyone in every industry is so receptive to the Internet.
Through data analysis and research, it is found that the state encourages entrepreneurship now, and the peak period of entrepreneurship will inevitably generate a lot of manpower demand, especially when it is said that entrepreneurship is not related to the Internet, and people who are engaged in the Internet are also very accepting of APPs. High, at least willing to try. So you take the practitioners of the Internet industry as the users of your product.
When you analyze other recruitment apps, you find that there are many problems with these apps. For example, I am looking for a job in Beijing Xierqi, but many apps are currently unavailable for screening; There is very little feedback; there is too little information about the company; before the establishment of the delivery, as a job seeker, as a job seeker, I want to know who the boss of this company is; now in the Internet age, electronic resumes are completely fine, why do recruiters themselves need to be recruited every time? To print a resume, you must know that printing a resume is not very convenient for job seekers, because it will be changed at any time, which is very inconvenient for job seekers. So if you plan to make this APP, its characteristic functions are 1. The position supports the classification of the location of the company; 2. The recruiter should give feedback to job seekers from time to time; 3. Cancel the paper resume. The main function is to recruit. Now we name the app Feige Recruitment.
Requirements definition: The analysis of requirements definition includes three aspects: target users, usage scenarios, and user goals. What type of target users will use your product; the main function refers to what your product is used for, whether it is a tool or something else; what is the difference between your product and other products on the market? It's the product feature.
Just now, the APP's applicable population, main functions and product features have been clarified. Some of the recruitment apps on the market are headhunters specifically for those who want to change jobs. Who are the target users of your app? Based on the analysis of features and user pain points, it is determined that the target users of the product are those who want to find a job in a specific location, such as those who have settled in Houshayu, Beijing, and hope to work in Wangjing; when you just moved to Huilongguan, At this point, you are faced with changing jobs, and you may be inclined to find a job in Xierqi.
1.2 Demand Analysis
That's it for all product positioning. After these are completed, it is followed by competitive product analysis and user research. On the one hand, this is to verify our needs to a certain extent, and on the other hand, it is also an opportunity for us to directly contact users to see what their needs are.
1.3 Requirements screening
Early demand screening is a very hard task. If the product manager is the boss himself, it is fine if he is very clear. If it is not easy to fall into the massive demand and cannot pull it out, he will go astray after discussing it. After the discussion, it seems that All functions are needed, this function is useful and must be added; that function is too fun, and the user must be interesting. These words are always based on personal subjective assumptions, and often they sound plausible at the time, but they cannot stand up to scrutiny after the fact. Therefore, we need to always grasp our product positioning and priorities, and we must not blindly make a lot of fearless sacrifices and struggles in this place (less unthinking, brain-slapping, and non-brain decisions).
Requirements record sheet:
During the early demand screening period, there will be a lot of needs of this kind or that, some of which we cannot immediately make judgments and say that it is good to do. These ideas may become the inspiration for our product iteration in the future, and will also bring a wider range of product development. ideas. Do a good job of management, respect everyone's ideas, and record and download when there is ambiguity, which will be of great help to the promotion and progress of the meeting.
2. Commercial value
Market requirements documents and business requirements documents are generally more mature in large companies. In small companies, most of the decisions are made by the boss. The boss may not do this or that document, but he will definitely do a basic understanding, or he himself knows a certain industry very well. These two documents are neither redundant nor cumbersome. It is very necessary to spend a certain amount of time to understand the industry and users in depth before the project is launched. The specific document details are not explained here, and there are many online references that can be used for reference.
3. Technical Evaluation
As someone who is not from a technical background, I will no longer write here. Respecting developers and getting along well with development will be very helpful in promoting the product.
(2) The project is under implementation
In the previous article, I have told you about the three major blocks that should be done before the project starts: 1. Requirements; 2. Business; 3. Technology. After these preparations are sorted out, the next step is execution. The execution process is not as macroscopic as you need to consider before, but you need to be careful and patient enough.
1. Product level
After the demand is generated, the product personnel can produce the demand document. The demand document plays a key role in the next interaction design (startup companies often take the role of the product manager) and UI design. Of course, in the process of generating the demand document , If there is a full-time interaction design, it is best to discuss the details of the requirements document with the product personnel in the requirements stage, which is helpful for the interaction designer to understand the overall requirements, and it is also very good for him to prototype design and write interaction instructions. help.
The requirements document generally contains the following aspects:
Background Description: Why this project? What problem does the user solve? How much will it be worth? Roughly, it is to summarize and explain the homework done before the project starts, and it must be concise and concise.
User portrait: A virtual description of user characteristics to clarify the user's situation.
Project timing: When will the prototype come out? When will the real design draft come out; when will it enter the development? When to start testing? When will app store submissions start? These all need to be clarified, otherwise if there is no concept of time, everything will be delayed and there will be no sense of urgency.
Information structure diagram: The content organization structure of the APP. The following is an example, which simply gives the basic structure of WeChat.
Task flow chart: For the major functions in the APP, sort out the whole process of the user from the beginning to the end, and take into account various possibilities. Otherwise, if the development encounters problems and asks you, you have to reconsider, which is even more terrible The problem is that the development does not ask you to develop directly, and the result is not what you want. Here is an example of a simple login:
Requirement description: Explain the conditions and results of each operation clearly. If you can explain clearly in words, use words. If you can't explain clearly, use pictures. Some people may say that there is no wireframe at this time, how to explain it. This is not contradictory. The early requirements document is used for interaction (again, the products of entrepreneurial companies may be interactive), and the interaction designer will design wireframes and high-definition based on your functional structure and process comb real prototype.
Data burying: Make a list of the data that needs to be viewed later, such as the click rate of this button, the open rate of this page, etc. At this time, we need to communicate more with the operation and clarify the places that need to be buried. This is very helpful for data analysis after the product is launched, and the data can also assist in the iteration of product functions.
2. Interaction Design
After the requirements are sorted out, the next step is the design and output of wireframes, page processes, high-fidelity prototypes and interactive descriptions. High-fidelity prototypes are determined on a case-by-case basis, some companies have requirements, some do not.
2.2 Wireframe:
Strive to express the visual effect of each page simply and clearly. It is best not to add interaction here, nor to make it colorful, preferably black and gray. Each situation is a page, and each situation is expressed separately on the page. On the one hand, you will be more clear about the overall number of interfaces of the APP, and on the other hand, the design will also be more clear about what you want. Otherwise, if you add interaction, you will not know how to design. , you have to explain for half a day.
2.2 Page flow chart :
Similar to the previous information structure diagram, the page flow chart uses each page to connect, making the connection and jump of each link more clearly visually.
2.3 High Fidelity Prototype:
The requirements for interaction will be higher. It is necessary to fully display the interaction between various functions, and visually restore the appearance of the real product as much as possible. (About Axure, you can learn the course of Jinwu, which is very good. Many people think it is too wordy, but if you look carefully, it is still very good.)
2.4 Interaction description:
I personally feel that there is overlap between interaction descriptions and high-fidelity prototypes. If high-fidelity is done, then most of the interactions can basically be displayed. However, the interactive effects in some places cannot be handled by the software, and you need to use interactive explanations at this time.
If the text and pictures are not explained, just use the paper to simulate. Don't underestimate this way.
Here are some recommended tools for interactive marking: Mac computer is decisively sketch; under windows, there are snagit, circle, FScapture, and viso can also be marked.
3. UI design
Under normal circumstances, the interaction designer gives the wireframe to the designer, and the designer can start work. In this process, the interaction should be more communicated with the design. After all, the UI will also have its own professionalism, and she will have her own design insights, which is normal.
4. Project execution
The design has been produced, and the interaction work has been completed. It is time to hand it over to the project manager for execution. At present, this status is only available in very large companies. Generally, the product manager directly assumes the role. What needs to be reminded here is that before implementation, various related norms must be established first. for example:
4.1, naming conventions for apk and api files and management of different types of installation packages:
This is all my personal experience. Doing this well will be of great help to the management of the installation package in the future. At that time, we built a developer environment. The APK and API files in this environment can only be used in the local area network. In this environment, you can toss and test arbitrarily without affecting the applications that have been launched.
The icon and name of the installation package packaged in the developer environment should be distinguished from the application in the online environment. In the future, you will not be in a hurry because of the various versions when you continue to test.
4.2 APK, API file management
4.2.1 Development version: Purely developed for your own use or product use, and other unrelated personnel will generally not touch this version. Network environment: It is only used in a specific network environment (technicians are required to build the environment).
4.2.2 Public beta version: After detailed testing of the product and testers, there are basically no bugs, and it can be used by the company's people, which is also a stability test before going online. Network environment: It can only be used in a specific environment (requires technology to build the environment).
4.2.3 Store version: APK and API files ready to be submitted to the market. After the comprehensive testing of the development version and the public beta version, all unstable bugs are eliminated. At this time, the packaged store version still needs to be checked by the testers. Finally, it must be ensured that the APK and API files to be launched are tested. The final check of the personnel, otherwise if the development does not notify the test and product personnel if the changes are made, it will be too late to make changes after a problem occurs after the launch.
5. APP testing and version number management
The management of the version number should be clarified in the early stage. Otherwise, after the product goes online, there will be bugs that need to be improved, or whether the addition of new functions will affect the old version. At this time, a good version number management will play a big role. , on the one hand, you can find out the apk and API files that have been online at any time, and on the other hand, you will not confuse yourself in the face of constantly modifying the packaged files.
The following are my personal opinions, such as which Daniel has a good method to share. The version number is always unique, and it is iterative and progressive. Don't deliberately interfere with the version number in order to make the version number look good when it goes online. It is strictly forbidden to have multiple sets of version numbers.
Test Notes:
In the UI, interaction, and product development stage, it is necessary to communicate with technicians more. It is best to refine large functions into small functional modules, and notify relevant people to check each time a part is done, so as to avoid accumulating too many problems in the end. The modification action is too large. The UI is responsible for focusing on whether the development is implemented according to its own design, the interaction is responsible for focusing on whether the interaction effect meets your standards, and the product is responsible for focusing on whether the implementation of each function is correct.
Test case: A good test case can effectively promote the process of testing. A good test case is to describe the various situations of the APP that need to be tested as clearly as possible in human words. This depends on your writing ability. Write test cases When it comes out, it will be handed over to the testers to test, which is also the standard for them to judge whether the APP meets the standard.
Bug management tools: bugtags, bugclose, etc. There are many on the market, and most of them are free. Even if it is charged, don't care about the money. With the help of bug management tools, the collaboration efficiency of testers and technicians can be effectively improved.
(3) After the project is launched
I have introduced two parts to you before, before the project starts and during the project execution. After the project is launched, there are several aspects that need to be paid attention to as a product, one is APP data, the other is user feedback, and the third is demand extraction.
1. APP data
New user: the user who starts the application for the first time;
New unique users: the total number of new users for all applications (de-duplication)
Active users: users who start once on the day are active users, including new users and old users;
Active Unique Users: The sum of active users of the application for the day (de-duplication)
MAU: MAU (monthly active users) number of monthly active users.
DAU: DAU (Daily Active User) the number of daily active users. It is often used to reflect the operation of websites, Internet applications or online games.
User retention rate: In the Internet industry, users who start to use an application within a certain period of time and continue to use the application after a period of time are considered to be retained users. The ratio of these users to new users at that time is the retention rate, which will be counted every 1 unit of time (eg day, week, month).
The 40-20-10 rule in user retention rate: If you want the DAU of games and applications to exceed 1 million, then the daily retention rate should be greater than 40%, and the weekly and monthly retention rates should be greater than 20% and 10%, respectively.
Next-day retention rate: (among the new users on the day, the number of users who are still active on the next day) / the total number of new users on the first day;
Retention rate on the second day: (among the new users on the first day, there are still active users on the second day) / the total number of new users on the first day;
Retention rate on the 7th day: (among the users added on the first day, there are still active users on the 7th day) / the total number of new users on the first day;
Retention rate on the 30th day: (among the users added on the first day, there are still active users on the 30th day) / the total number of new users on the first day.
The other is the buried point data of the APP. What is the click-through rate of this function? How many people have this feature turned on and how many people have used it? How many people are using this feature frequently? Wait, these buried data should always be paid attention to. Combine data changes to reflect on functional design issues to optimize products.
2. User Feedback and Comments
After the product is launched, user feedback and comments are particularly precious materials for product personnel. On the one hand, it is the intuitive feeling of your real users, and on the other hand, they express their direct needs. So, how to deal with the user's opinion is particularly important. We will do whatever the user feedbacks, which is definitely not acceptable. In many cases, what users express is only a superficial phenomenon, and it is necessary to learn to explore the essence of the needs behind users. Do more research on some revolutionary products in the world and learn more about people.
When we see the opinions flying around, we must learn to think, instead of accepting and copying them all.
Is it our goal? Think about who our target users are.
Does the usage scenario hold? Or is this just a very individual scenario requirement.
Are the user goals correct? Is our APP designed to meet the needs of users?
Is the product positioning correct? If this function is implemented, does it still meet the positioning of our product?
If you want to do this function, can your own project resources be able to meet it? If you need to use all the resources to do this, you have to be cautious and cautious.
Three, demand extraction
Maybe the user's opinion is a circle, but after analysis, it is very likely that the demand is a triangle.
"If I had originally asked consumers what they wanted, they would have told me, 'A faster horse!'"
- This is a classic Henry Ford quote, and now we see it again in "Jobs".
More than 100 years ago, Henry Ford, the founder of Ford, went around and asked his customers: "What better transportation do you need?" Almost everyone's answer was: "I want a faster horse. ". Many people heard this answer, so they immediately went to the horse farm to select horses for breeding to meet the needs of customers. But Mr. Ford did not immediately run to the racecourse, but continued to ask.
Ford: "Why do you need a faster horse?"
Customer: "Because you can run faster!"
Ford: "Why do you need to go faster?"
Client: "Because I can get to my destination earlier."
Ford: "So, what do you really want for a faster horse?"
Customer: "Get to your destination faster and in less time!"
So, instead of going to the racecourse, Ford chose to build cars to meet the needs of customers.
There are two types of customer needs: explicit needs and implicit needs. What we know through market research are often explicit needs such as "I want a faster horse". The explicit needs of the customer are not the real needs of the customer. Enterprises need to conduct in-depth mining and capture based on the collected explicit demand information to understand what customers’ hidden needs are, and then analyze what customers really need (for example: reach the destination in a shorter time and faster) ). This is a process of needs analysis.
Jobs said: "Our task is to understand what has not yet fallen on paper." In fact, it is a deep excavation of users' hidden needs.