PM from demand to product growth path

The author of this article is the product manager of the public comment.

This article intends to write, how to communicate with the technology, in fact, with the technical communication is very simple, mainly through the whole from the requirements of the document to product tracking, product on-line, iterative, and so on. This article is more about the author's work for half a year, from the requirements of the document to the whole process of product on-line, but also hope to more friends with more colleagues to exchange.

Requirements document Look No

When you've worked hard to write up a bunch of requirements documents, make an interaction with ued's classmates, vision, refactoring, full of thought technology will be taken seriously, but you will find that the technical students will not see the basic you prepared a pile of things, basically according to their own understanding to develop, when development does not go on, the first time is not to look at the document, but look at the test cases, or communicate directly with the product; The basic document is just a QA classmate writing a use case.

Just beginning to work, for the technology is not in accordance with the document development, is more anxious to get angry, after a period of time, found that the focus is good. The essence of the product is to ensure the quality of the core function of the product to protect the user experience, client and merchant side of the function can not be vague, operating backstage, customer service backstage and so on, the protection of functional integrity and business fluency, on the basis of the appropriate technology to play; even the front page, listen to technical advice, let technical students participate in; In the process of development, maintain communication, the fastest response to technical questions.

What are the requirements for writing documents? For functionality, involving business turnover, state switching, boundary conditions Gray often many needs, flow chart, interaction, PRD one can not be less; for non-functional requirements, the part that promotes the user experience, the document is not ready, the prototype is ready, and then the focus is on it, Make it clear when you deliver.

ToDoList and Priority

Products in the iterative process, there are constantly new needs, the need to be completed, through the list to manage these needs, the process is also the process of thinking about products, keep asking yourself, this demand users who, solve what problems, whether necessary, and whether it is necessary to do now?

The advantage of list is that as much as possible to record all the needs, although some are born to be cut off, but the list of things that need to be done, the whole team will have a sense of urgency; in a word, clear each requirement, indicate priority, lead, corresponding development, start time, completion time, completion status, Let the team owner (including the boss) know how much we are doing, how much has been done, and what to do next.

Demand will never be done, for priority arrangements, peacetime work is the most commonly used in the four-quadrant method, important and urgent, important not urgent, urgent unimportant, not urgent is not important, according to the actual project to make judgments.

Demand meeting

12 Years is a weekly iteration, there will be the next iteration of the needs of the meeting, not the real sense of the needs of the review, product-driven companies, basically is the need to explain, delivery, and related time point confirmation

Need to be fully prepared

In meeting the requirements, in the face of technology and QA, even the bosses of the challenge, this is normal, they will ask why to do so, why do not do so, and even directly to your needs to challenge: this thing is not reliable, impossible; the thing that makes a table to play the bench also occurs; is to be prepared for the needs of the need, no matter what the challenges, the data, user needs, and competitors to do, the basic can be persuaded;

There's no immediate answer, Quick admit error: Sorry, this is I am not ready, after the meeting I go to do detailed research and preparation, quickly skip this problem, continue to have the contents of the following assured, and then to complete the argument, and the problem described clearly, mail to everyone; After the meeting everyone peace of mind to treat, but also easy to solve.

Tell me my story.

This is supposed to be a good user story, why do I tell my story, because products need to put their own into the various roles, a few user interviews, many users describe such a scene, I'm almost off work, take out the app search around to find food; operations say this is annoying, I need to do this, In fact, it can be solved;

Customer service said, this information is checked here, that information on another page, each record processing time increases how many minutes;

The most interesting is the merchant side, the merchant side has signed the contract, the shop leader, the person in charge, the front desk, the receipt silver, the accountant, each person may come to use our backstage, goes to the merchant end to do the interview, observes how they use reviews the product;

Talk about the needs of the time, first describe the plight of users, vivid, touching, how to do, into their own role, do not pretend to use, but their real use of the pain point in the process, amplification and amplification, emotional way to impress technology.

Describing the pain point is just the first step, can clearly describe, if this need to do, operating efficiency can increase how much, save how much cost, the final conversion rate is expected to improve how much, as well as ROI (input-output ratio), all the function points of improvement, finally can be settled as money, because it will make everyone excited, and focus on solving the problem.

Get more people involved in the demand debate

The need to be challenged is a bit uncomfortable, but if everyone shows indifference to your needs, that's the hardest thing to do. How to get more involved in the requirements discussion: First you can tap the people who are interested in the business, talk to them, and they will actively inform them of their ideas. The technique of working for a few years is more concerned than the children's shoes just working. Second, let the technology have a sense of existence, timing to inform them of the relevant product data, monthly number of users, monthly growth, revenue, etc., according to the technology developed function points, refined to the function of the data, as well as the year-on-year chain data; Finally, in scrum, Planning Poker allows everyone to participate in the requirements because everyone has to assess the task's workload, and for now, the effect is good.

Determine the time point and the responsible person

Scrum is really a good way to estimate the workload and the technology to pick up the task until everyone's work fills the entire sprint.

Before scrum is started, a weekly demand meeting is just to deliver the relevant requirements, the development Manager will assign the task, and set the work schedule, then the QA students will add the relevant test arrangements and finalize the online time.

In fact, regardless of the way, the final result of the guide is that the product online as soon as possible, and the most effective and least risky way.

Cut demand properly

Products do not need to understand the technology, but if you can approximate the workload according to the requirements, the scheduling is simpler; each time I will prepare more, even the interaction and refactoring are ready, put a do not do this demand is not to give up posture; When the resources are adequate, the technical children's shoes will take the initiative to receive the demand, but when the work is more full, It's very difficult, so when the requirements are reviewed, the priority of each requirement is high, the user described the pain point lifelike, if the technology is really complaining too much, then symbolically cut off the part, the premise is to ensure that the core must be completed, in fact, when cutting off a part, will not be cut down, but also the heart will have a sense of satisfaction; Second, the technical sense of urgency to complete, and then there are a lot of things, even if this iteration does not do, the next iteration needs to be completed

In the process of product development

Keep communication

In the process of product development, the technology is very responsible, will help you consider the boundary conditions, as a product of positive response to the various questions raised, is to maintain the technology and products is a very effective way. Although there are some problems, may be the technical understanding of the needs of the product is not so deep, it is good to speak clearly, there is no need to Ober, because ultimately everyone's purpose is for the product, and the company began to practice scrum also to the entire team to maintain communication, both the requirements, but also become a

Take test Cases seriously

Test cases, but also a tool to ensure product quality; When I first started working, I thought the test case was just a QA classmate's job, when the first version of app was uat, I found that the requirements document was not fully validated by all the requirements, but for the test case, all the mainstream, the auxiliary process, the boundary conditions, Non-functional requirements, clear, feel too useful. Therefore, each time the requirements of the completion of the required document delivery QA,QA in the technical formal access to the completion of use case documents; In the test case, the product at the same time, to avoid some of the deviation of the understanding of the requirements, in addition to the technical students to the case development, more clearly than the requirements of Uat, is also a product reference.

Requirements change and delay

Change of demand is the eternal topic, scrum is generally not accept changes in requirements, in fact, not allowed to change the nature of the demand is not fixed plate, but the product put forward a better demand, from the needs of research, preparation, design, delivery every step need to consider comprehensive and clear; even in demanding scrum, Is the demand really not changed? If the temporary online bug caused users to not access, technical students are not to stop the work, to troubleshoot the line. As a product, not God, try to make sure that all the requirements are reasonable and necessary, and that all the requirements are ready to be done and, if not avoided, to influence or even persuade the entire team to embrace change.

Correctly handle requirements Changes

The change of demand has happened, so hurry up and deal with it. If the product is not considered clearly, user research or data support error, decisively to the team to admit their mistakes, no one will blame a sincere apology to the people; and in the first time to deliver the changes in the requirements of the document, interaction, vision, refactoring and so on, and communicate with the technical how to minimize the cost to complete this implementation; If the technical work has already been fully scheduled in this iteration, consider the urgency of the requirement and, where appropriate, the next iteration.

If the industry or the market changes, product transformation and other reasons, directly to the team to communicate the reasons for the change, as well as the next product planning, so that everyone can see a clear goal, technology will have questions and challenges, patient answers, through the industry data, competing products and other perspectives to explain; Because the boss's demand priority is always the highest, but as a direct communication with the technology products, to seriously deal with the boss changes in the part, if the boss frequently change the demand, annoying is the technology, will not leave the influence after the cooperation.

About product delay

No matter product or technology, no one would like to see delay, face delay, how to deal with? Another way of thinking: even if the delay, as long as the user can still use, services run, the earth still turn. If it really causes users to not access, the entire technical team must work overtime, do not eat and drink will do well. Once the delay, the whole team to troubleshoot delay reason, is the need to change, or resources are not in place, or the coupling between the project, the small changes in front of the project to postpone, do a summary meeting each time, and in the next iteration to avoid this problem.

The team is slowly introducing scrum agile development, and this summary, most of it is based on the Cascade model of iterations; there are many more to learn, in a blink of an eye after two months, the formal work has been eight months, there are many roads to follow the whole team to grow together.