What challenges the product manager will face

Absrtact: Small White is a note: With the continuous development of the Internet, Internet products, product managers must also from the old thinking to come out, in order to stand out in the modern competition. What challenges will be encountered in the evolution from the old to the new?

Small white A: with the continuous development of the Internet, Internet products, product managers must also from the old thinking to come out, in order to stand out in the modern competition. What challenges will be faced in the evolution from the old to the new? Let's see what Eric Ries said.

When you are in a traditional waterfall mode workflow, no matter what role you play in it, it makes you feel powerless. This is especially the case for "product managers" who work in startups that are pushing new products to the next market and work in large numbers. Recently I saw a real sense of the product manager responsible for the new product, he and his development team told me the story made me feel helpless. Obviously, the product manager is trying to get results from other people on the team. These wise men maintain the consistency of progress.

So why do they have so many difficulties?

Let's start with what the product manager does. By common sense, he is the one who defines what a product does. He wrote detailed product requirements documents detailing what functionality the team should build in the next iteration. Give these requirements to a designer and let him build the layout and model of all the major function points. The design is then presented to a team of professional developers. Each of you is responsible for your own part (UI, middleware, backend) and corresponding coding. Finally, the QA team builds a test plan based on specifications to assess whether they are functioning properly.

The system itself is a general process suitable for the Product manager organization. Although the programmer does not build the next major feature, he will be busy writing programs. As a result, they will not have any leisure time until they start the next iteration. If the programmer is idle, it is not a good thing for the product manager because he should have been busy building the product. Otherwise, the company is wasting a lot of money.

When I saw the team, the opposition between the team members was formed. The last few features that are built up are quite different from what was originally defined, which takes a long time to work properly. Programmers have been asking a lot of questions about their design and direction. So the team is and has spent more and more time discussing the requirements and design phases, trying to get the team to identify with what is being built. However, for some reason, despite the team's increased sense of identity, the final product does not seem to be the same as it was originally defined. The VP Project spends all of its time trying to make sure that programmers understand and implement specifications, that each iteration takes longer than before, and that the negative feelings of frustration are increasing.

It didn't take long to find that the product manager was being ordered to write 5 times for each requirement specification. For the first time, he wrote neatly and clearly. Then he and the designer build out the design specifications, and QA builds the test plan. When developers get the requirements, they often negotiate with PM about what to build. They communicate many emails, and because of this, product managers are often interrupted to clarify the exact meaning of the requirements. For the fourth time, the requirements note exists only in the message, which causes an expression bias. When QA gets the function, their test plan is already badly outdated. So the product manager has to use the software, start updating the prototype, and help create a new test plan. Naturally, output deviates so badly that he must rewrite the current needs (the next major function) and take them into account.

Ironically, the system is designed to ensure that each function is 100% utilized, so no one, including the product manager, is lazy. But as the number of iterations increases, the product manager spends more and more time answering questions. The interruptions were so bad that he had to get up at 3 o'clock in the morning to write his new prototype just to make sure the workflow was complete.

What the hell is wrong with this? Everyone is doing their best to devote 110% of their energy to work. But the team is getting behind.

Here are some of my suggestions for tweaking the team:

First, work across cross-functional teams. Each team has a functional representative. First, we try a product manager, a designer, one or two programmers, and a QA. The team has a complete point to point feature.

Second, focus on iteration speed rather than taking advantage of each function. If you can't help the current iteration to succeed, let them be lazy. I have been amazed at how many people have not developed their potential. They don't want to be free. By keeping them focused on the success of their team, you can empower them to do anything that will make the team successful. Does that mean that the design team can join QA to help test the release of the certificate? Let's wait and see.

Finally, the push of the demand process is transformed into pulling. Start with a page specification, no more. Next, let the team ask the Product manager questions at any time they need to clarify. In Exchange, team members display each piece of work to the product manager and get his permission. They found that the difference in speed would be much faster and be resolved in a timely manner. And the team will be more and more adept at interpreting concise specifications that need to be written once. (Finally, they may cancel the specification together.) There are more ways to get the team to eliminate the waste of the way they work, thus achieving faster iterations. Ultimately, I want them to have a comprehensive agile development process: with test-driven development, regular meetings, sprints, pair programming, and so on. But first I think we need to save the product manager from the old waterfall model. Once the different members of the team can trust each other again, we have the foundation to start a truly continuous improvement feedback loop.