[Product Manager] How to deal with "second-hand demand"?

"I was assigned a module that someone else was in charge of. In the early stage, he also connected with the operation classmate. He told me that the operation wanted a certain function. It took me a long time to complete it. When I reviewed it with the operation, I found that it was not an operation at all. The function that my classmates wanted. In the end, I reworked it again. What should I do if I encounter this situation next time?"

1. Clarify the source of demand

First, determine what the real source of demand is.

In their daily work, product managers will receive a large number of demands, some of which are conveyed by others, some of which they propose specific solutions, and so on.

It is very important to clarify the source of demand.

In the original demand pool, effective records of demand sources are particularly important. Because of this information, it will affect the confirmation of subsequent demand scope, priority decision-making and scale judgment.

Second, clarify business scenarios and real pain points.

Most people do not say: what problem do I want to solve when they ask for it; they generally describe it as: what function do I want.

To give a case, a new sales company acquired 3 factories in the upstream of operation, and the boss asked for a factory management system. After a series of inquiries and communication, it was discovered that what the boss wanted was to standardize the operation flow and production quality of the three different factories. So he does not need a complete set of factory management platform, but a production management system.

So how to determine the real needs of users?

2. Getting to the bottom of it is the key

1. First, ask the person trying to convince you to explain it clearly

You must know that the Chinese language system is complex, so in the process of communication, you need to pay attention to the meaning of different words and expressions in different contexts, and don't just stay at the literal meaning.

We can deduce what he really means by asking repeatedly, combining context and getting more background information. The most important thing is that we need to keep an open mind, be an active listener and empath, so that the requester can trust us and can really solve his problem.

2. Next, it is necessary to quickly grasp the key points in the large-scale communication and discussion

What does he mainly want to express? What are the keywords? What is he most concerned about? Determine his true intentions and analyze what his real pain points are? What is his difficulty? What problem is he trying to solve? Where does he feel sad? Instead of asking stupidly: What are your needs and what functions do you want.

Tips: In this process, you can combine the [discovery problem model] to assist analysis and judgment.

The first step is to use the As is/To be model to visualize the gap between the ideal state and the current situation. The so-called gap is the problem.

Describe the ideal state, for example: as a sales consultant of a store, I hope to quickly see the daily tasks; sort out the status quo, currently we can only see messy customer information on the APP, and cannot quickly follow up with customers.

The second step is to use the "6W2H" model to delve into the core of the problem.

• Who: store salesperson.
• whom: Store customers.
• What: The existing system is difficult to quickly establish a connection.
• when: every day.
• How: It takes a lot of time to find the corresponding follow-up tasks in the system every day.
• Why: The company requires that the system is difficult to use.
• where: APP and offline paper form provided by the company.

Through simple sorting, confirm whether you understand the problem correctly, analyze why this problem occurs, and then find out if there are any key points that you have overlooked subconsciously.

During the questioning process, you can use the "cause analysis" model to keep asking why.

First of all, we must set the problem and lock in a specific problem. Secondly, ask why, and write down the reason, keep asking why, continue to dig into the reason, and go through layers of cocoon until it is logically stated that "as long as this problem is improved, the problem raised at the beginning may be solved."

Problem: The new employee at the branch placed the wrong order.

1. I didn't find that I made a mistake.
2. Not carefully confirmed.
3. The usage process and related specifications are not confirmed.
4. The process is not uniform, and I don't know what the process is.
5. There is no universal standard operating procedure.

3. Organize and summarize

The messy problems can be summarized through the fishbone diagram or logic tree diagram, so that no problems are missed. Categorize the problems and sort them out logically.

During the process, check whether there are overlaps or omissions in the problems, and whether the requirements can be combined or need to be supplemented.

4. Paraphrase

Finally, be sure to repeat the conclusion, clarify again whether there is any ambiguity, and obtain the final confirmation.

3. There is no harm in asking a few more people - find the question in the shadows

For a question, you can find several relevant parties, ask the same question, and see what other people's answers are.

From it, we can find information that has been ignored. Because human nature is complex, most people are refined egoists. Then in the communication process, it is very likely to seek advantages and avoid disadvantages, and only expound information that is beneficial to oneself, which will interfere with our judgment.

Through different roles, change different perspectives, to find those problems that do not want to be mentioned, maybe these problems are the real pain points.

4. The original demand enters the pool

After the above process, the requirements are obtained and complete records are required.

There are many kinds of demand pools. Based on my personal work experience, I have summarized a set of product demand pool templates (and operational demand pool templates, which will be explained in detail in subsequent demand management articles).

• Original requirement description: try to record the original dialogue of the proposer, and do not reprocess to increase subjective analysis.
• Solution: 1. What function is used to achieve what effect/purpose. 2. What management means/business goals/pain points do you want to achieve.
• Requirement Title: Platform-Module-Requirement Title, for example: Operation Platform-User Management-It is recommended to add query function.
• Requirements description: describe the overall closed-loop process and key logic.
• Priority: P0-P4.
• Sources of requirements: external customers, operational advice, technical advice, product planning, senior leadership.
• Requirement types: new functions, function improvements, bug fixes, user experience, UI optimization, customization requirements, deletion requirements, interface requirements.

Remember to scroll through the demand pool every day, merge the demand in time and exit the pool.

The demand for second-hand is like a scumbag who doesn't understand clearly and why, but still bites the bullet and wants to fall in love with it. But you can identify and domesticate him in various ways and use them to your advantage.