How to do a good demand analysis step by step

how to do a good demand analysis step by step

As a product manager, the most frequently spoken word is “demand”, which is also the ability that product people must master. In this Internet age where everyone talks about needs and talks about pain points, as a product manager, have you really mastered the methods and capabilities of needs analysis?

I once wrote an article titled “Experience Summary: Four Steps to Compiling Product Requirements Documents “. This article is a set of quick and effective requirements document writing methods summarized by my years of product work experience. Compared with other topical articles I wrote, the number of views and collections of this article is very high after it was published. It can be seen that the product people are very interested in the needs, skills, and sharing of examples. To this end, this article will once again focus on the topic of demand for further sharing.

Before writing the requirements document, we must first analyze the requirements, from user requirements to product requirements, then to product functions, and finally form the product requirements document and transfer it to product development.

Regarding how to conduct demand analysis, all the great gods of Zhihu have written inscrutable guiding theories, which is admirable. However, after reading this highly theoretical content, people still have a sense of nowhere to start. Therefore, I am going to use a more straightforward example to share my needs analysis experience.

1. Make yourself a user as much as possible

No matter what product you are making, if you want to do it well, you need to put yourself into the corresponding user role and think about the problem from the perspective of real users.

I was in charge of smart car products in a car networking company. At that time, I had not obtained a driver’s license, so I had no driving experience. Although I am very interested in the Internet of Vehicles, as a non-vehicle owner, I have no sense of product. It is difficult to make reasonable judgments and designs when doing demand analysis.

In order to make myself a car owner and have a sense of product, I bought a car in advance (I got my driver’s license only half a year later). Although I can’t get on the road, I have at least one car for my own experience, even making two turns in the garage of the community. no problem.

At a later product requirements review meeting, a project manager who had also never driven a car raised a question, why is there no shutdown function on the car-machine system interface, and how much power is consumed after driving? This problem will be ridiculous in the eyes of people who are familiar with cars-because the car is directly connected to the car’s power supply, and the car can charge the battery as long as the car is ignited and the engine works, and there is no problem of running out of electricity; and the car’s Part of the control operation is carried out through the vehicle interface, if it is really shut down, there is no way to operate. Therefore, the car machine does not need the shutdown function, at most it just turns off the screen.

This question, before I hit the car, I also couldn’t answer this question.

There are also some basic common sense issues. For example, it is very dangerous to operate the car machine while driving, so the touch area on the car machine interface is made very large and conspicuous, in order to achieve semi-blind operation and improve driving safety as much as possible. . For another example, the time is displayed on each interface of our car and machine, and it is specially designed to be more conspicuous.

Then some people may ask, why is there so much time, does the car itself have no clock display?

Not really.

At that time, most of the low-end cars did not have time display functions, and high-end cars were already equipped with more powerful car machines as standard, which was not the target carrier of our car machine products. Therefore, the function of displaying time is very basic and necessary.

If I am not the owner of a car and do not drive, then these most basic cognitions will not be available, and it will be difficult to realize the needs of a driver.

Of course, car networking products have a certain degree of particularity, because there is a gap between car owners and non-car owners, and it is difficult for non-car owners to take the role of car owners through brain supplements. But, for other products, if you can become a real user, I believe you will have more control over the product needs.

This is the basis for a good demand analysis and a good product.

2. Listen to user needs and understand user needs

Many needs come directly from users. Sometimes users will tell you what they need. At this time, we will listen carefully to users’ opinions.

But we can’t just simply receive user feedback information, but to understand the real needs of users.

In a certain project, we designed a functional module for order management in the back-end management. After the user (actually a B-end customer, but for the sake of unification, it is still called a user), the user told us after formal use, hoping to enhance the query function. For example, the combined query under multiple states of the order (currently only the single state condition query), so that the data he needs can be easily queried.

When I hear it, I feel that this requirement is very clear and simple. It is nothing more than enhancing the query function, so easy!

But is this really the case?

At this time, we need to further understand the user’s motivation. It is: Why do you want to do this, and what is the purpose?

After further communication, he came to understand that his purpose was to export the required data through this method of operation, and then get the data for calculation, and finally use it for account reconciliation to check whether the accounts are even.

It can be seen that querying various data through the enhanced query function is only an intermediate link, and the ultimate goal is to obtain these data for reconciliation. Therefore, reconciliation is the ultimate demand of users. So, if our platform can automatically calculate various data and directly inform users of the reconciliation results, wouldn’t it be better?

Obviously it is.

However, considering that the current business model changes rapidly and is not stable, the data used for reconciliation may also change frequently, so the reconciliation rules cannot be fixed yet, and it is not suitable for systematization.

Therefore, the final plan I gave is: add a new function module, the system automatically inquires the current required reconciliation data according to the corresponding rules, and displays it in the form of a list. In this way, the user only needs to take out these few data, copy it to the Excel sheet used for reconciliation, and then fill in other required data, and then the reconciliation can be carried out conveniently.

After hearing the proposal I proposed, this user was very surprised and said, “Really can this be done? That’s really convenient!”.

Through such in-depth analysis, a solution that is closer to the user’s inner needs is given, and the result can greatly exceed the user’s expectations. Isn’t this the so-called user experience?

When most users face problems, they will seek satisfaction through their own envisioned schemes. This is human instinct-but this is only the needs of users, and usually not “user needs”. This is the so-called pseudo-demand, the legendary “a faster horse”.

This analysis process can be summarized as the what-why-how solution process, that is: what is it? Why? How to do it?

After such an analysis, the real user needs can surface.

3. Listen to users’ solutions

When we are doing demand analysis while considering product solutions, we sometimes get into trouble.

When thinking in your own way, things are likely to become complicated and difficult to understand.

At this time, what we need to do is not to continue to think hard to overcome problems, but to stop and talk to our users.

For a certain project, I need to add a function of auto parts supplier to subsidize freight in the product.

Briefly describe the background: we are in the auto parts logistics business, that is, we help auto parts dealers deliver products to auto repair stores. We will charge delivery fees; the delivery fees are usually paid by auto repair stores, but sometimes auto parts dealers will choose subsidies for profit. Part of the delivery fee. However, when we deliver, we charge a delivery fee per trip. That is to say, when the same train is delivered to a certain auto repair shop, there may be goods from multiple auto parts dealers, and there may be cases where multiple auto parts dealers subsidize the freight at the same time.

At this time, the problem arises: if the three auto parts dealers subsidize the delivery fee of 10 yuan, a total of 30 yuan, and the delivery fee is 25 yuan, then there will be an auto repair shop that even pays 0 yuan for the delivery fee, but also 5 yuan more. The problem.

In this case, in order to make the accounts clear, it may be necessary to turn this extra money into an income and record it in the system.

However, there is no corresponding amount of money in the business circulation, so how to deal with the money has become a problem. After all thinking about it, I found it more troublesome to deal with, and I couldn’t think of a simpler solution.

At this time, I decided to talk to the user.

I asked, in the absence of a system to solve the situation, how do you deal with this situation now?

After detailed communication, I realized that their solution was so simple-directly adjust the distribution fee to be consistent with the sum of the subsidized distribution fee, so that there is no problem of an extra income, just a normal distribution fee ; In this way, the accounts are also level, except that the delivery fee is paid by the auto parts dealer.

Therefore, the final solution is: when the distribution fee subsidized by the auto parts supplier is higher than the original distribution fee, the system will automatically adjust the distribution fee, and the auto repair shop will be exempted from paying the distribution fee.

Therefore, when we are faced with some needs that we don’t know how to handle, we don’t have to rush to think about how to solve them. You can ask users how to deal with such problems.

Many times, we think that we can use product technology to solve user problems more professionally and conveniently; but in fact, more often we will complicate the problem. In the face of new demands, I should communicate more with users and believe in the wisdom of the working people, which is likely to bring you unexpected surprises.

4. Understand the frequency of demand

Faced with the demand, before thinking about how to solve it, we need to ask one more question: How often does this demand happen?

Especially when the system needs to be modified to meet this demand and the cost is high, we have to make all choices when considering the product plan.

It is the case above: if the processing method adopted by the user cannot be borrowed from the system, that is, when there is no simpler processing method, we will once again fall into a mental dilemma.

At this time, we should ask more: Does this happen frequently?

The answer is: very little.

We should resolutely consider a low-cost response to this kind of demand that is difficult to handle and has a low frequency of occurrence. If there really is no better system solution, then you can finally consider the human flesh solution-when this happens, it will automatically be transferred to manual processing, that is, manual intervention. Because the human brain is more flexible and can deal with complex and changeable situations.

Just like our customer phones, general high-frequency and standard requirements can be directly selected and operated through the voice menu guidance. This interaction between the system voice and the phone buttons is equivalent to the system program to handle the requirements. And if the options given by the system voice do not match, you can finally find a solution by choosing manual customer service.

But in many cases, we can’t directly understand the demand frequency situation from the user’s mouth. At this time, we can also analyze it from our system data. That is to use various data such as business data, user buried point data, access logs and so on in our system to extract and conduct a comprehensive analysis to finally find the answer.

With this factual data, if the data shows that the frequency is indeed low, then we should not hesitate to consider a low-cost solution.

5. Simulate user operations and complete the missing process

At this point, we have basically completed the requirements analysis and formally entered the stage of product design and requirements compilation.

At this stage, as long as we have done a relatively complete pre-demand analysis work, this process basically does not need to spend too much time.

But the only issue that needs attention is to avoid missing business processes.

Still an example description:

There is a demand point in our project called Auto Parts Supplier Payment Confirmation, which means that the payment we collect on behalf of the goods requires the auto parts supplier to verify and confirm in the system before we transfer the payment. For this requirement, I arranged for another colleague of product manager A to be responsible. After describing the general requirements and process with him, he started to work.

It didn’t take long for colleague A to complete the requirement document for this function, and he sent it over for me to confirm. I probably took a look. There is no major problem in the design of the user (auto parts supplier) side, but there is a big problem in the back-end management of the system: in the back-end management, he only does the inquiry of the payment confirmation record; of course, there is also Export data function. Because I told him at the time that for the confirmed payment records, we need to manually perform transfer operations after exporting the data (because the bank transfer interface is not yet connected).

Let’s analyze it and simulate the process according to the operation flow of this function:

Auto parts dealers check the unconfirmed payment in the system one by one, and then confirm the correct data; our cashiers regularly check out the confirmed but untransferred payment records through the background every day, then export them, and then export them according to the exported Data transfer one by one…

Attentive students may have discovered the problem: if you do this, then there are multiple payments under the same auto parts supplier; if you operate according to this data, you need to make multiple transfers to the same auto parts supplier-if so , Then I think not only our cashiers will be crazy, but auto parts dealers will also be crazy.

Of course, the cashier can merge the exported data again, but after all, this operation is too troublesome every day, and we need to further improve our design. We can add a functional module to directly present the summary data that needs to be transferred every day, and automatically merge the total payment of the same auto parts supplier, so that the cashier can directly use this data for transfer operations. After the transfer is completed, come back and set these records as “Transferred”, and then the system will automatically change the status of the payment records corresponding to the summary records in a one-time state.

Through such a process, we can further improve our needs, and finally complete the closed loop of the system process.

Of course, if we can take it into consideration in the preliminary analysis, there is no need to conduct a review to make up for the leakage in the product design stage.

6. Don’t forget the original intention, and always have to

Sometimes, when we make the product to the end, we find that there is always a gap in front of us that cannot be bridged. At this time, we might calm down and think. Maybe it will be discovered after the resumption that we were wrong at the beginning.

When I was working on the Internet of Vehicles project, I was in charge of a music product, that is, the music app on the car. When we are making product requirements, business colleagues also look for external music resources simultaneously. Because our product is positioned as online music, we need the support of a massive copyrighted music library.

However, the problem of music resources has not been solved. The main problem is that the prices offered by the partners are too high for us to accept. I have negotiated with several companies that are similar, because the concentration of music resources is high, and there are not many choices. When our music product was almost completed, the music resources could not be finalized-this would cause the music product to be unable to go online at all. Seeing the helpless business colleagues look like, we are also helpless.

In this case, we have to think about whether we can break through this problem at the product level?

Music products are designed to meet the needs of car owners to listen to music while driving. We hope to provide car owners with convenient music services and enjoy the fun of driving. Just like before, there were special portable audio products such as MP3 to meet people’s music needs anytime and anywhere; but later because of the smart phone, it was replaced. Now, as long as you like to listen to music, you will have a music app in your mobile phone and store certain music, so you can listen to it whenever you want.

Thinking of this, I suddenly found a question: We are already convenient enough to get music through smart phones. For car owners, do we really need a new “online music”? We make car music to solve the convenient music needs of car owners, but it is not necessary to “online” music.

There are other choices for the source of music resources. For example, you can use SD card to copy music on your computer, or you can use mobile phone Bluetooth to send to the past-by the way, can you transfer the music on your mobile phone to the car for playback? ? For example, we are also developing a mobile phone APP to connect with the car to realize the transmission of music files, or synchronization.

This solves the problem of the music source, and it is more convenient than the SD card method.

This low-cost solution can also solve the problem of music resources, but it is a little troublesome.

From a demand perspective, what users need is only listening to music, not online music. Online or not is not the key to the problem, as long as you can listen and listen easily, that’s enough.

For the needs of users, I think it is more important to understand the difference between the needs of listening to music in the car environment and the ordinary environment. For example, we are prone to get sleepy during long-distance driving. At this time, we especially need some passionate music to refresh our minds. In the ordinary environment, this demand is very weak. For this, we can explore in depth from the perspective of car owners’ needs for different types of music in different mental states. We believe that through such excavations, products that meet the needs of users can be made.

Don’t forget the original intention, always have to go. Only by always remembering the fundamental needs of users can we make appropriate products to satisfy the desires of users.

The above is my own experience and understanding of requirements analysis. There are not many advanced theories here, but if you can think in this way when doing demand analysis work, I believe you will be able to make a good product that meets the needs of users.

Leave a Reply