产品管理与软件开发的关系
如果说成功的产品是真实用户需求与现阶段可行性方案的结合，那么产品经理与开发团队之间(合作)关系的重要性自然不言而喻了。
产品经理负责定义产品方案;开发团队最了解哪些产品设计是可行的，他们负责产品的开发与实现。作为产品经理，你很快能体会到，只有与开发团队融洽合作，才有可能开发出合格的产品，否则等待你的将是一段漫长难挨的日子。
形成合作关系的关键是双方承认彼此平等——任何一方不从属于另一方。产品经理负责定义正确的产品，开发团队负责正确地开发产品，双方相互依赖。你要求开发团队完成任务，必须先取得他们的认可，确信为了达到产品质量标准必须这么做;开发团队也要留给你足够的空间设计有价值、可用的产品。
产品管理和软件开发相互促进，开发人员可以帮助产品经理完善产品定义，别忘了他们最清楚你的产品设计是否可行。
开发人员帮助产品经理完善产品定义的方式有如下三种。
让开发人员直接面对用户和顾客，体会用户的困惑和疑虑，了解问题的严重性，好点子常常会随之而来，譬如，可以邀请一名开发人员参加产品原型测试。
向开发人员了解最新的技术发展动向，讨论哪些新技术可以用到产品里。开展“头脑风暴”，看看目前已实现的技术或即将实现的技术能不能解决手头的问题。
让开发人员(或主程序员)在探索(定义)产品的初期阶段参与评估产品设计，协助策划方案。产品经理常犯一类错误，即完成产品定义后，扔给开发团队便置之不理。这样做只会贻误协调需求与可行性的最佳时机，等到发现问题时，为时已晚。
同样，产品经理也可以协助开发人员的工作，方式如下。
产品经理关注产品的基本要求(核心功能)。产品经理应该意识到，自己定义的不是最终产品，而是满足基本要求的产品雏形。只有这样，产品管理与软件开发之间才能形成良好的互动。
一旦产品进入开发阶段，要尽可能避免修改产品的需求和规划。虽然有些事情超出你的控制范围，变动是不可避免的，开发人员也能理解，但是千万不要在此时尝试突发奇想的点子。
产品开发阶段难免会产生诸多问题，比如，用例丢失，或者用例设计考虑不周全等。这很正常，哪怕最优秀的产品团队也避免不了。产品经理应该迅速采取行动，在维持产品核心功能、尽量避免修改的原则上，给出解决方案。
我经常鼓励出色的开发人员尝试产品管理工作。我告诉他们，如果产品没有市场价值，无论开发团队多么优秀也无济于事。很多优秀的产品是程序员抓住用户需求，自己创业研发出来的。放宽眼界不仅仅有利于开发人员自己的职业发展，也有利于产品、顾客和公司。
如何与异地的开发人员沟通?
如今产品经理与开发团队各处一方的情况很常见。除了印度软件外包业务，大型公司的分支机构之间，以及公司与被收购的子公司之间，都可能出现这种情况。
如果开发团队不在你身边，沟通和执行的难度将进一步放大。异地开发出现的问题常常导致团队士气低落，有人甚至公开质疑异地开发能否真正节约成本。
提高与异地开发团队之间的沟通效率，我有三条建议。
开发团队距离越远，语言、文化、时差带来的沟通难度越大，确定完善的产品说明文档就越重要。如果产品经理不确定开发什么样的产品(或者反复改变想法)，异地开发团队只能疲于奔命，白费力气。这简直就是一场灾难，丝毫不亚于医生开错方子。如果你与开发团队相隔很远，无论是沟通产品文档的内容，还是讨论修改产品设计，一定要借助高保真原型进行交流。阅读文档毕竟不轻松，如果文档是非母语的，或者阐述不清楚，那沟通效率就更低了。
本地的开发团队很容易发现和解决各种冲突(比如，两个管理者给出相互抵触的指导意见)。异地开发团队则会发生很多意想不到的情况，往往过了好几个月才发现问题。这是因为异地开发人员不得不揣摩各种不同的意见(但经常揣摩错)。因此，必须有人在本地负责与异地团队的协调工作。这并不是说所有沟通工作都必须经过此人，而是应该明确异地开发团队只接受他的命令。这项工作可以由本地的项目经理、资深开发人员或者其他主管担任。
如今商业沟通手段很丰富，除了电子邮件和即时消息外，还有视频会议可供选择，此外，语音电话业务(VoIP)大大降低了国际长途通话费用支出。尽管如此，当面交流的优势依然不可替代。每个季度，产品经理至少应该前往异地与开发团队见一次面，与软件架构师、管理者当面交流。面对面交流有助于改善(合作)关系，提高沟通效率。此外，交换人员也是一种有效的沟通方式，可以让主程序员来本地与产品经理共同工作一段时间，或者让产品经理到异地工作一段时间。
按照我介绍的方法与优秀的开发团队合作是一种特别的享受。如果是与印度外包团队合作，那么由于时差的原因这种合作会让人觉得更加惬意。每天早晨上班时，对方的项目进展已经摆在面前。你可以用白天(对方的夜晚)检查、测试代码，反馈信息，显著缩短项目的循环周期。
请注意，如果是在异地开展与产品原型相关的工作，由于循环周期非常短(一天迭代好几次)，你必须随时准备处理对方的问题，投入更多的精力。
解决异地开发问题的另一种方式是在异地聘请产品团队。这种趋势正在兴起，我相信这种模式会被更多的公司采用。你大可不必为此担心。我们曾经用了10年时间在异地培养专业的开发和测试人员，培养专业的产品经理和设计人员很可能还要再花10年时间。
程序员想重写代码?
产品经理最担心听到开发人员这样抱怨：“不能再增加功能了!我们得停下来重写代码。代码库一团糟，就像纸糊的老虎，根本应付不了持续增加的用户。我们维护不下去了!”
这一幕在很多公司上演过，现在依然在不断重演。1999年eBay遭遇这一幕时，公司濒临崩溃的情形超出所有人想象。Friendster几年前也发生过这种情况，当时他们正在向MySpace开放社交网络用户。网景与微软展开浏览器大战时，也发生过类似的事情，最后的结果大家都知道。事实上，没几家公司能渡过难关。
一旦公司陷入这种困境，开发团队往往沦为替罪羊。经验告诉我，这类问题通常是由产品管理失误引发的。因为产品经理一直迫使开发团队满负荷工作，开发尽可能多的功能。所有软件架构都存在功能极限，如果忽视产品的基础技术构架，一旦系统越过崩溃的临界点，就会造成无法挽回的结果。
在重写代码的过程中，用户无法看到产品的任何改进。你可能认为重写代码至多也就几个月，但是实际花费的时间无一例外要多得多。你只能坐在一旁，眼睁睁看着用户投奔竞争对手，而这个时候，竞争对手恰恰在不断地改进产品。
如果你还没有遇到这样的情形，未雨绸缪很有必要——你需要预留一定的研发技术能力，在eBay被称为余量(headroom)。很多因产品迅速膨胀产生的问题都与扩展规模有关，余量意味着避免触及技术能力的上限，为用户数量的增长预留空间，为事务增长预留空间，为新增功能预留空间，保证产品的基础技术构架能够满足团队的要求。
与开发团队合作应该遵循以下原则：在产品管理上为开发团队预留20%的自主时间，让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、重构代码库中有缺陷的部分，或者更换数据库管理系统，提高系统性能，避免“我们需要停下来重写代码”的情形发生。
如果你的糟糕处境已经初现端倪，应该拿出至少20%的资源进行调整，而我担心有些团队连20%都不愿意拿出来。如果你已经身陷重写的困境，说明公司危在旦夕，这里给出一点建议供你参考。
第一步，针对开发团队确定的产品修改目标并制订切实可行的计划和时间表。通常，有经验的开发团队估计的开发时间八九不离十，但是重写代码是个例外，因为多数团队都没有重写代码的实际经验，估计往往过于乐观。你必须审时度势，仔细检查每处细节，确保计划切实可行。
第二步，只要有可能，最好把重写目标分成几大块，实现递增修改，让用户感受到产品的改进，哪怕会因此把9个月的工作时间延长至2年，也一定要采用这种方式。重写代码时，保证让用户看到功能的改进——即使会占用少则25%，多则50%的开发资源——对保持产品(尤其是互联网产品)的市场占有率至关重要。
第三步，由于开发用户可见功能的资源有限，必须谨慎选择正确的产品特性，并确保产品定义的正确性。
eBay起死回生后，我们发誓绝不重蹈覆辙，马上开始新一轮的代码重写，把危机甩在身后。事实上，由于发展迅速，eBay已经重写了三次代码，最后一次采用了完全不同的编程语言和架构。开发团队花了几年时间，大规模地改写了几百万行代码，同时在不影响用户群的情况下，开发了大量新功能。这是我知道的最惊心动魄的中途重建网站的故事。
临渴掘井不如未雨绸缪，为防患于未然，别忘了预留20%的余量。如果你从未与开发团队谈过这件事，今天就去找他们吧。
软件开发人员如何转型做产品管理?
我与开发人员接触，发现他们很关心这样一个问题：如何从软件开发向产品管理转型?
开发人员希望向产品管理转型，有时是因为参与探索(定义)产品后，尝到了影响产品决策的甜头，不再满足于只做编程的工作。有时是因为对现有产品很失望，他们认识到如果产品没有价值，开发团队再优秀也无济于事。
我认识的很多优秀的产品经理都是开发工程师出身。接下来，我将探讨从软件开发转型到产品管理时可能遇到的问题和挑战。
开发人员转型做产品管理有其无与伦比的优势——对产品可行性的敏锐嗅觉。如果他们对用户行为进行深入分析，学习一些和产品管理有关的技巧，就能成长为出色的产品经理，打造出用户喜爱的产品。
转型的第一步，是清楚地意识到自己和目标客户是截然不同的。花一些时间和真正的客户交往，就会很容易意识到这一点。不要想当然地认为，只要我喜欢这个产品，知道如何操作，用户也一定会喜欢这个产品，知道如何操作。
第二，学会“移情”(empathy)，懂得站在用户的角度思考问题。其实，用户并非一无所知的菜鸟，只是他们的工作和擅长的领域与你不同罢了。要做到换位思考，最简单的方法是花时间与用户做面对面的沟通。注意，这并不意味着用户能提出真正的产品需求;挖掘产品需求是产品管理的任务。
第三，转变思想。作为开发工程师，你的任务是优化开发流程和效率。但作为产品经理，你的工作则是定义产品、优化用户体验，打造出用户喜爱的产品。这一点看似容易，只有当你面临一个两难抉择，比如项目发布时间与用户体验出现冲突的时候，你才能体会其中的困难。
第四，保持谦逊的品格。向用户展示产品时，大多数人的反应可能会与你的预期背道而驰，这时谦逊就显得格外重要。仔细倾听来自用户的声音，日复一日，你的理解力会得到极大提升。但前提条件是必须拥有开放的心态来面对用户的批评。
第五，改变讨论风格。很多互联网企业中，工程师都喜欢围绕着某些决策争论不休，激情四射。可多数情况下，这些产品的技术决策有明确的判断标准，比如运行速度更快、规模更合适、容错度更高、扩展性更好等等。而产品定义和用户体验的决策中并不存在这样的标准。这时候就需要你改变以前的讨论风格，提高说服和辩论的技巧，让他人接受你的观点。
最后，处理好和原部门的关系。成为产品经理后，你和开发部门的关系会变得很难处理。他们会变得异常敏感且难以沟通，会采取各种各样的方式来挑战你，质疑你的技术能力，不会轻易作出承诺。你需要学会放手，让工程团队做好他们的本职工作，并参与到产品开发的流程中来。产品管理的工作已经够让人头大了，相关的技术决策就放手让他们来处理吧。
我强烈建议公司建立畅通的渠道为开发人员的转型提供便利，一定会培养出许多杰出的产品经理。即使转型不成功，开发人员还是决定回去编程，但产品管理的观念也为他们树立了“科技以人为本”的思想，对他们今后的工作是极其有益的。
作者简介：过去20年，Marty Cagan作为负责定义和开发产品的高级经理人为多家一流企业工作过，包括惠普、网景通信、美国在线、eBay。他亲历了个人电脑、互联网、电子商务的起落沉浮，致力于通过写作、演讲、培训帮助客户打造富有创意的产品。为此，他撰写了《Inspired: How to Create Products Customers Love》一书，创办了硅谷产品集团公司(SVPG)。在此之前，他的最后一份工作是担任eBay产品管理及设计高级副总裁，负责规划全球电子商务网站的产品和服务。
本文节选自华中科技大学出版社《启示录：打造用户喜爱的产品》一书和作者的博客。该书从人员、流程、产品三个角度介绍了现代软件(互联网)产品管理的实践经验和理念。特此感谢华中科技大学出版社与Marty Cagan先生授权。