What is the relationship between product management and software development

Relationship between product management and software development

If the success of the product is the real user needs and the current feasibility of the solution, then the importance of the relationship between Product manager and development team, we can imagine.

The Product manager is responsible for defining the product scenario, and as a development team, which product designs are feasible they are best known and they are responsible for product development and implementation. As a product manager, you will know that only a rapport with the development team will give you the opportunity to develop a qualified product or you'll experience a long and difficult time.

The key to forming a partnership is the recognition of equality between the two parties--either party does not belong to the other. The Product manager is responsible for defining the right product, the development team is responsible for developing the product correctly, and the two sides depend on each other. You require the development team to complete the task, must first obtain their approval, is convinced that in order to achieve the product quality standard must do so; the development team also leaves you with enough space to design valuable and usable products.

Product management and software development are mutually reinforcing, and developers can help product managers refine their product definitions, and don't forget that they know best if your product design is feasible.

There are three ways that developers can help product managers refine product definitions.

1, to allow developers to directly face users and customers, understanding the user's confusion and doubts, understand the seriousness of the problem, good ideas will often follow, for example, you can invite a developer to participate in product prototype testing.

2, to the developers to understand the latest technology development trends, discuss which new technologies can be used in the product. Develop "brainstorming" to see if the existing technologies or upcoming technologies can solve the problem at hand.

3, let the developer (or master programmer) in the Exploration (definition) of the product at the initial stage of the evaluation of product design, to assist in planning programs. Product managers often make a mistake, that is, when the product definition is finished, it is thrown to the development team and ignored. Doing so would only delay the best time to coordinate demand and feasibility, and it would be too late to find the problem.

Similarly, product managers can assist developers in their work in the following ways.

1, product managers pay attention to the basic requirements of the product (core functions). Product managers should be aware that they define not the final product, but the prototype of the product that meets the basic requirements. Only in this way, product management and software development can form a good interaction.

2, once the product into the development phase, as far as possible to avoid changes in product requirements and planning. While some things are beyond your control, change is unavoidable and developers can understand, but don't try to brainstorm ideas at this point.

3, the product development phase will inevitably produce many problems, such as use case loss, or use case design is not considered congruent. This is normal, even the best product team can not avoid. Product managers should act quickly to provide solutions to the principle of maintaining product core functionality and minimizing modification.

I often encourage good developers to try product management. I tell them that if the product has no market value, no matter how good the development team is. Many excellent products are programmers to seize the needs of users, their own entrepreneurial development. Broadening horizons is not just for developers ' own careers, but also for products, customers and companies.

How to communicate with a remote developer?

The situation is common today between product managers and development teams. This can happen in addition to India's software outsourcing business, between the branches of large companies, and between companies and the acquired subsidiaries.

If the development team is not around you, the difficulty of communication and implementation will be magnified. Problems in offsite development often lead to low team morale, and some even openly question whether offsite development can really save costs.

I have three suggestions for improving communication efficiency with other development teams.

1, the further development team distance, language, culture, time difference brought about by the difficulty of communication, to determine the perfect product documentation is more important. If the product manager is unsure what kind of product to develop (or change the idea repeatedly), the offsite development team can only be exhausted. This is a disaster, no less than the doctor to prescribe the wrong prescription. If you are far away from the development team, whether it is to communicate the content of the product documentation or to discuss modifying the product design, be sure to use the High-fidelity prototype for communication. Reading a document is not easy after all, if the document is Non-native language, or unclear, the communication efficiency is even lower.

2. Local development teams can easily find and resolve conflicts (for example, two managers give conflicting guidance). A lot of unexpected things happen in a remote development team, and it often takes months to discover the problem. This is because developers in different places have to figure out a variety of opinions (but often try to make mistakes). Therefore, someone must be responsible for the local team coordination with the off-site. This is not to say that all communication work must go through this person, but rather that the remote development team should only accept his commands. This work can be done by local project managers, senior developers or other supervisors.

3, today's business communication is very rich, in addition to e-mail and instant messaging, there are video conferencing options, in addition, voice telephony services (VoIP) significantly reduce the international long-distance call costs. Nevertheless, the advantage of face-to-face communication is still irreplaceable. Each quarter, the product manager should at least go offsite to meet with the development team and communicate with the Software architect and manager. Face-to-face communication helps improve relationships and improve communication efficiency. In addition, the exchange is an effective means of communication, can allow the main programmer to work with the product manager for a period of time, or the product manager to work off-site for a period of time.

It is a special enjoyment to work with an excellent development team according to the method I introduced. If it is working with India's outsourcing team, this kind of collaboration can be more enjoyable due to jet lag. Each morning at work, the other side of the project progress has been placed in front of. You can use daytime (each other's night) to check, test code, feedback information, significantly shorten the project cycle.

Note that if you are working on a product prototype in a remote location, because the cycle is very short (several times a day), you must be ready to handle each other's problems and devote more effort.

Another way to solve the problem of offsite development is to hire a product team in an off-site location. This trend is on the rise, and I believe this model will be adopted by more companies. You don't have to worry about that. We have spent 10 years developing professional development and testing personnel in different places, and it is likely that it will take another 10 years to develop professional product managers and designers.

Programmers want to rewrite the code?

The product manager was most worried about hearing from developers complaining: "No more features!" We have to stop to rewrite the code. Code base a mess, like a paper tiger, can't cope with the growing number of users. We can't do this anymore!

This scene has been staged in many companies and is still being repeated. In the 1999 ebay encounter, the company was on the verge of collapse beyond everyone's imagination. Friendster also happened a few years ago when they were opening up social networking users to MySpace. Netscape and Microsoft launched the browser war, there have been similar events, the final results are known. In fact, few companies can pull through.

Once the company is in this predicament, the development team tends to fall prey to the scapegoat. Experience has taught me that such problems are often caused by product management failures. Because the product manager has been forcing the development team to work full load and develop as many functions as possible. All software architectures have functional limits, and if they ignore the underlying technology architecture of the product, once the system crosses the critical point of collapse, it can cause irreparable results.

In the process of rewriting the code, the user cannot see any improvements to the product. You might think that rewriting code is at most a few months, but it actually takes a lot more time. You can only sit and watch the user go to the competitor, and at this point the competitor is constantly improving the product.

If you're not in a situation like this, it's necessary to take precautions-you need to reserve certain research and development skills, which are called headroom on ebay. Many of the problems caused by the rapid expansion of products related to the scale of expansion, the margin means to avoid touching the technical capacity of the upper limit, for the growth of the number of users to reserve space for the growth of the transaction space to reserve space for new features, to ensure that the product's basic technical framework to meet the team

Working with the development team should be guided by the following principles: set aside 20% of the free time for the development team in product management, allowing them to dominate. The development team can use these times to rewrite the code, refine the architecture, refactor the defective parts of the code base, or replace the database management system, improve system performance, and avoid the "we need to stop to rewrite the code" scenario.

If your bad situation is already emerging, you should have at least 20% of the resources to adjust, and I'm afraid some of the teams don't even want to take out 20%.

If you are already in the predicament of rewriting, indicating that the company is at stake, here are some suggestions for your reference.

The first step is to target the product changes identified by the development team and develop a realistic plan and schedule. Typically, an experienced development team estimates the development time pretty, but rewriting the code is an exception, since most teams do not have the actual experience of rewriting the code and are often overly optimistic. You have to look at the situation and double-check every detail to make sure the plan is realistic.

The second step, as long as possible, it is best to rewrite the target into several chunks, to achieve incremental changes, so that users feel the improvement of the product, even if the 9-month working hours will be extended to 2 years, we must adopt this approach. When rewriting code, make sure that the user sees improvements in functionality-even if it takes a few 25%, and a 50% of development resources-is critical to maintaining the market share of products, especially Internet products.

Third, due to the limited resources to develop user-visible functionality, it is important to carefully select the correct product characteristics and ensure that the product definition is correct.

When ebay came back from the dead, we vowed never to repeat it, and immediately began a new round of code rewriting, leaving the crisis behind. In fact, because of the rapid development, ebay has rewritten three of times code, the last time using a completely different programming language and architecture. The development team spent several years rewriting millions of of lines of code on a large scale, while developing a large number of new features without impacting the user base. This is the story of the most thrilling reconstruction site I know.

Line as a precaution, do not forget to reserve 20% of the allowance. If you've never talked to the development team about it, go find them today.

How do software developers transform product management?

I contacted developers and found that they were concerned about the issue of how to transition from software development to product management.

Developers want to transition to product management, sometimes because they are involved in exploring (defining) products, tasting the benefits of influencing product decisions, and no longer content with programming. Sometimes it is because of disappointment with existing products that they realize that if the product is worthless, the development team is no good at all.

Many of the best product managers I know are from development engineers. Next, I'll explore the problems and challenges that you may encounter when you transition from software development to product management.

The transformation of the developer to do product management has its unparalleled advantages-a keen sense of smell of product viability. If they conduct in-depth analysis of user behavior, learn some skills related to product management, can grow into a good product manager, create a user favorite products.

The first step in the transition is to be aware that you are completely different from your target clients. It's easy to realize that by spending some time with a real customer. Do not assume that as long as I like this product, know how to operate, users will also love this product, know how to operate.

Second, learn to "empathy" (empathy), know how to stand in the user's perspective to think about the problem. In fact, users are not ignorant of the rookie, but their work and expertise in the field is different. To do transposition thinking, the easiest way is to spend time with the user to do face-to-face communication. Note that this does not mean that users can put forward real product requirements;

Third, change the mind. As a development engineer, your task is to optimize the development process and efficiency. But as a product manager, your job is to define products, optimize the user experience, and create products that users love. This seems easy, and only when you are faced with a dilemma, such as when the project release time conflicts with the user experience, can you understand the difficulties.

Four, keep the character of humility. When you show a product to a user, most people's reactions may run counter to your expectations, and humility is especially important. Listen carefully to the voice of the user, and your understanding will be greatly improved day by day. But the prerequisite is to have an open mind to face the user's criticism.

Five, change the discussion style. In many internet companies, engineers like to debate about certain decisions and to be passionate. In most cases, the technical decisions of these products have a clear standard of judgment, such as faster running speed, more appropriate scale, higher fault tolerance, better scalability, and so on. There is no such standard for product definition and user experience decisions. This time you need to change your previous discussion style, improve your persuasion and debate skills, and let others accept your views.

Finally, deal with the relationship with the original department. When you become a product manager, your relationship with the development department becomes difficult to deal with. They will become extremely sensitive and difficult to communicate, and will challenge you in a variety of ways, questioning your technical skills and not making promises lightly. You need to learn to let the engineering team do their job and participate in the process of product development. The work of product management is enough to make the head big, the relevant technical decision let them to deal with it.

I strongly recommend that the company establish a smooth channel to facilitate the transformation of the developers, will certainly cultivate a number of outstanding product managers. Even if the transformation is unsuccessful, the developers decided to go back to programming, but the concept of product management for them to establish a "science and technology people-oriented" thinking, their future work is extremely beneficial.

Author Introduction: Over the past 20 years, Marty Cagan has worked as a senior manager for the definition and development of products, including HP, Netscape Communications, AOL, EBay. He has experienced the ups and downs of personal computers, the Internet and E-commerce, and is committed to helping customers create innovative products through writing, lecturing and training. To this end, he wrote "Inspired:how to Create product Customers Love" book, founded the Silicon Valley Products Group (SVPG). Prior to this, his last job was to be the senior vice president of product management and design at ebay, which is responsible for planning the products and services of the global E-commerce website.