How to turn demand into practical product solutions!

Here we assume that the company already has a certain scale of users and has established user portraits.

We have also done a demand analysis to determine what is needed by our core user group.

1. Determine key indicators - think before you act

Analysis: What are the key points of this requirement? How to judge whether the output product solution is appropriate?

Therefore, it is necessary to establish evaluation indicators for the results before the output.

First of all, we need to put out the key indicators and clarify the following points:

• What are user characteristics?
• In what scenarios do users have this demand?
• In this scenario, what are the user's concerns?
• What is the user's goal in this scenario?

Regarding 1, different companies/products have different user groups and characteristics, so the evaluation criteria for the quality of products will be different; for example, the users of game companies are mostly teenagers, students, and office workers. The users of antique and real estate e-commerce products are mostly middle-aged and elderly people.

Regarding 2, in what scenarios will users have this demand? The user's operating behavior and requirements will also change in different scenarios. For example, for taxi-hailing products, users will have this demand when they are tired of shopping or traveling to unfamiliar places. For example, for short video products, users will have this demand when they are taking the subway or waiting for a bus.

Regarding 3, users’ focus will be different in different scenarios, and different focus will lead to different focuses in product design. For example, in e-commerce products, when users are browsing products, they focus on product quality, appearance, price and other information, while in the payment process, users focus on address information, discount information, financial security, consumption risks and other functions.

Regarding 4, users have different goals in different scenarios (here we must clearly distinguish between user goals and product goals, which are the user's psychological preset goals); for example, in e-commerce products, when browsing products, the user's goal is to see products that they are interested in, that are good-looking, fun, and cost-effective; and in the payment process, the user's goal is to complete the purchase operation smoothly and ensure the safety of funds.

After analyzing and answering these questions, we will have a preliminary forecast of the data (number of users, daily active users, and monthly active users) after the launch of this function.

2. Product Solution Design - Not Just Mindless Copying

Research whether there are already functions on the market that can meet this need, and look for competing products on channels such as Baidu and Tieba.

If there is already a unicorn product, you need to look at the user reviews and reputation of the product on Tieba.

Finally, we selected products with good reputation and unicorns as the main competitors for analysis.

1. Competitive product analysis

List the product structure of competitors' products regarding this function, and after comparison, sort out the common functions and different functions, that is, obtain the "basic functions" and "highlight functions".

As a "basic function", our products must also have it. And optimize based on users' negative reviews.

The "highlight features" are the highlights of each product and are the key to operational promotion and attracting and retaining users; so we also need to think about the "highlight features" of our own products. The design of highlight features requires taking into account the “key performance” mentioned above and considering it in combination with the company’s existing resources.

After completing the competitive product analysis, the outline of the product plan is already in my mind.

If there is no competitor with this function in the market, then congratulations, you can make an MVP, gradually expand it after iterative optimization, and fully demonstrate the ability of a product manager.

2. Output business process diagram

Many leaders at work require that prototypes be directly output, but in my experience, this step is a test of the product manager's logical ability because:

1) When making a prototype, you need to build a business process diagram and product structure diagram in your mind, and you also need to consider things like interaction design and interface element layout. After the prototype is produced, a meeting will be held to discuss it. If problems are found at this time, not only will the product manager have to go back to work, but it will also waste everyone's time.

2) The business process diagram can display the process, and the processes that need to be merged and shortened can be clearly seen at a glance, which provides convenience for the division of subsequent functional modules and the merging of the same pages (key pages) design; it prevents users from always entering new pages, which increases the workload of the R&D and design teams.

3) Business process diagrams can clearly sort out and complete abnormal processes. The handling of abnormal processes is also very important. It will affect the product reputation in the early stage of launch. Looking at the early user reviews of WeChat, there are many negative feedbacks about abnormal situations. This causes the team to quickly iterate and optimize in order to win back users, and they have to work overtime a lot.

Therefore, it is recommended that product managers carefully output business process diagrams and ponder them repeatedly; (it is recommended to adopt this method when analyzing competing products, which will benefit a lot) Multiple business process diagrams can be output according to the level of the process. Some closed-loop functions can be detailed in another diagram and directly replaced with modules in the main diagram.

3. Output function structure diagram

After the business process diagram is sorted out, the functional structure diagram will be produced quickly.

The key to the functional structure diagram is to ensure that the application boundaries of each module are clear, so as to prevent confusion in the attribution of functions when new functions are generated in subsequent iterations, which will cause difficulty for users to understand and a bad experience.

4. Design of key data indicators

After the prototype of the product design appears, you need to think about: the design of key processes and page embedding points.

Of course, you need to first think of the indicators that need to be quantified and how to calculate them, and then infer the locations where points need to be buried and the fields that need to be counted.

1) Statistics of key nodes

Design data indicators based on the “key points” at the beginning of the article. For example, if the transaction volume of an e-commerce product is a key node, then data such as PV, UV, order volume, payment volume, etc. of this node need to be collected; finally, user quality, product quality, ARPU and other indicators are calculated based on the collected data.

2) Statistics of key processes

For example, the login and registration process of a learning platform is a key measurement process for attracting new users, so data needs to be collected at every step of the user’s operation, and then a decay graph is made to analyze and locate the behaviors that cause user loss, so as to optimize that position.

Data quantification is an important basis for subsequent product iterations. It can quantify disadvantages and scientifically improve key indicators. I hope everyone will start planning when designing the product.

5. Output prototype image

According to the structure diagram, distinguish the modules, and sort out the key pages according to the flow chart, focusing on the smoothness of interaction and the rationality of element arrangement; users will enter the key pages from multiple business lines, so the key pages need to be paid special attention.

My experience is that prototype design can be dynamic or static. Generally, high-fidelity dynamic prototypes are required for presentation to customers (2B).

When showing prototypes to R&D colleagues in the team, specific communication and company regulations are required. Some R&D colleagues prefer static + descriptive prototypes.

6. Output prd

The output of prd can be output according to the company's regulations. Some companies only need a prototype diagram + logic description, but some companies have more backend logic that cannot be described by an interface, so prd is needed.

3. Product solution demonstration - don’t rush to find technology

When a product manager takes a solution to look for technology, he or she is embarking on a battle line from which there is no turning back, so he or she must be cautious.

Based on my own experience, I will give a self-examination method for this stage.

Self-test questions:

• Does the designed function meet the needs?
• Is this design the user's preferred option?
• Is there a cost for users to choose to use this feature?
• Does this feature pose a risk to users?

Regarding 1, reflect on whether the original intention of the design has been achieved. Look back at the requirements in the initial "key points". If they solve the user's needs, then it is passed.

Regarding 2, the demand exists, but users have many solutions and do not necessarily choose the method you provide; if users have more efficient and preferential methods, your user base will be lower than expected.

Regarding 3, many solutions require users to use this function, but do not consider the cost to users; for example, users need to install a lot of software, plug-ins, etc., which is a cost that some users need to consider.

Regarding 4, are there any financial, psychological, time, or social risks for users? At this time, it is necessary to analyze the risks one by one based on the user portraits in the "key points"; I believe everyone understands that these issues will have a negative brand impression on users.

4. Connecting with R&D - Don’t use the attitude of a leader

At this stage of work, communicating with R&D colleagues is also a headache for many product managers. My experience is: don’t talk to R&D about requirements with a leadership attitude.

The product manager thinks: I have worked hard for a long time and finally came up with a product plan. I can just give it to them and they can just work on it. Why do they keep asking me questions and making trouble?

However, the R&D team’s idea is: Our R&D is the core of the company. Why do you, the product manager, give us orders? Why should we listen to you?

In this way, you will find that your R&D colleagues do not disagree with your product plan (excluding the case where the product design is really bad), but they think that there is something wrong with the product manager’s attitude. Some product managers even use what a leader says to do to force the R&D team to do it. Therefore, product managers who face great resistance to R&D in the team should reflect on their own attitude when interacting with R&D.

Back to the original intention of the product manager: hoping that the product will be implemented perfectly. With this goal in mind, we can output to R&D in a more friendly way. Based on my experience, the method is as follows:

1) Storytelling

Describing the users' pain and how urgent their needs are in a tearful and emotional way can make R&D personnel empathize and generate motivation from within.

2) A platform for R&D to showcase their EQ

Product managers report product results to their leaders, and R&D, as behind-the-scenes staff, rarely comes into contact with senior leaders. Therefore, if product managers add more space in their reports to indicate the contributions of R&D colleagues, they will naturally build a friendly relationship with R&D bit by bit. Of course, daily emails should also indicate R&D's cooperation and express gratitude.

Of course, during the development process, abnormal situations are also a part of the conflict between product managers and R&D. Here we have to emphasize the importance of business process diagrams. Please refer to the above.

5. Testing and pre-launch control - don't ignore the details

After the development is completed, the product manager needs to test it on the front line. In addition to paying attention to whether the process is smooth, he also needs to pay attention to:

• Check the page text and prompts for typos.
• Whether the cold start data is adequately prepared.

It is possible that there are no typos in the prototype, but the designer is busy and does not notice the typos; and if the R&D department directly uses tools to generate the page, the typos will appear in front of users after it goes online, which will of course affect the reputation of the product.

6. Data Collection - Compare Expectations and Reflect

Don’t worry if the data is not good at the beginning. Work together with the operations department to collaborate in attracting new users and promoting activation. Don’t get excited if the data is particularly good, as it may be because the operations activities are well done.

The product data will not appear until half a year later. Before that, the data mostly shows the results of operational activities, so the product manager must remain stable, collect more user reviews, maintain seed users, have more contact with the first batch of users, conduct user surveys, collect problems, and iterate quickly; after half a year to a year, the data will show the quality of the product.

Compare the predicted data, think about the reasons for the difference in data, and reflect on:

• Are there any loopholes in the functions you designed?
• Is the understanding of user group characteristics not accurate enough?
• Has a strong competitor emerged?

At this point, the product plan has been completed. It can be said that the road ahead is long and difficult, but the journey will eventually be successful.

The implementation of a product plan does not mean that the product manager’s responsibilities are fulfilled. It is recommended that everyone think more based on the process and the results, come up with more goal-oriented ideas, and work hard on their own to find solutions and optimization plans.

If you are passing by, please take a look at my ideas. If they inspire you, please leave a comment.

Author: Uchiha Bing

Source: Uchiha Bing