Experience Sharing: How Should Product Managers Tell User Stories? Source

Translated

From the initial waterfall model, demands have run through products and projects. Demand is an important source of information for product construction. Whether it is an enterprise-level product with clear user needs or an Internet app product without clear user needs, demand research is the source of product closed-loop, and the quality of the research is directly related to Product success or failure.

I remember the first time I went to a telecommunications company to do a project. Their demands were not raised by themselves, but the company helped them put them forward. There is a thick set of company specifications for these demands, which is very awkward sounding and confusing to read.

Like dialects, you may have different understandings after reading A and B. In short, the products at that time were not easy to make because it was difficult for us to understand their needs, and customers did not know why they used the system or what to do.

However, the product is also easy to make because customers don't need to use the system, and sometimes they pretend to fool the group's specifications.

Later agile appeared(the middle span is still very large, but I just mentioned it in one stroke), and agile, with the flexibility of water, fully resolved the rigid and dogmatic project process of the previous waterfall model.

However, many companies think that agile is a universal method to solve project and product problems and be agile for the sake of being agile. It’s just that they used to write requirements documents, but now they rewrite user stories. The essence is the same. They regard agile as a universal tool, thinking that applying agile can help the project go online smoothly...

The answer is, of course: NO!

Agile user stories are not so low. A good user story does not apply a template and writes what the user said, even if it is done. It still needs a lot of preparation work in the early stage, and the product experience's analysis and evaluation must be added later.

Demand Investigation and Research

A user story must come from the user, but it may not be said by the customer himself, which may be confusing. For example, a customer who needs home decoration may often tell the designer my living room is dark, I see a lamp in other people's houses that looks very good, and I also want to install the same one. This demand seems reasonable, but the designer still has to question this demand before agreeing to the customer's demand.

Do customers need lights? Can installing a light in the living room solve the problem? Will there be other problems, such as easy to kowtow? Safe question?

After in-depth communication with customers, the designer discovers the essence of the problem. The customer thinks it is too dark and the lighting is not very good, so the problem changes from choosing the type of lamp to choosing what kind of light source to solve the problem of a dark living room, and the possible solutions will be very different.

Therefore, whether a clear demand survey will directly affect the design ideas of the following products and the product's final form.

How to Collect User Stories?

How to collect user stories?

• We must listen, let the user speak more, and guide him to speak (in fact, ask more why what you expect? etc.); Don't forcefully interfere, and don't talk too much yourself;
• It would help if you grasped the rhythm of the research, clarified the goals, don't let the research become your sales or training for customers, let alone let the research become customers' complaints, and must produce valuable information;
• Be sure to clarify the scenario. Different scenarios may have different user needs and may evolve into multiple user stories;
• It would help if you asked about the needs of the two roles of users and customers. Users are the final users, and the customer is the one who pays. The two types of people have two completely different needs (but in most cases, they only ask customers, after all, they have given money, and those who have not paid will wait to receive our complex system and endless training);
• Be sure to ask more about the client or user's expectations and describe the scenario they hope to achieve.

Only after the above information is collected, sorted, and classified can the final user story be formed and become a user story familiar to the product manager: xx user in the xx scene, through xxx operation, realizes xxx with the purpose of xxx.

Combined with the way of thinking training mentioned earlier, demand research is to confirm whether your thinking is correct and whether you can be at the same frequency as users.

Based on clear goals and the same purpose, can reverse reasoning apply the product and business logic to customers' needs, meet their basic needs, and even give them some surprises? If yes, then your product is at least finished well.