人人都是产品经理——iamsujie

《启示录：打造用户喜爱的产品》作者Marty的视频教学，终于集齐了，@七印部落出品，还没看过的同学，不妨看看吧，一共也才15min不到。

猛击每段标题的超链接去优酷看~~~~~~

两周理论：为什么产品发布总是表现糟糕？为什么“理想很丰满、现实很骨感”会成为口头禅？产品团队对自己的产品总过于自信，只顾埋头开发，却忽视了用户。所以我提出两周理论—克服恐惧，来点刺激的吧！

基本产品：为什么和设想的相比，开发出来的产品功能总是那样凌乱？为什么开发进展总是远远跑不过进度安排？是时候放弃定义最终产品了，你需要一个满足基本要求（价值、可用性、可行性）的产品！

产品团队：产品经理、交互设计师、程序员，他们仨像桃园结义的三兄弟，亲密合作、如影随形。你的产品开发团队做到了么？P.S.部分内容涉及到上一集“基本产品”的概念。

用户测试：“您愿意购买我们的产品么？”“可能会买吧！”别得意，善良的用户也许只是出于礼貌敷衍你。你需要换个方法找寻真实的答案。

独门秘笈：Marty Cagan谈产品5 任何产品团队、网络产品团队都应该拥有两大独门秘笈：证明产品是否真的可行，要使用真实数据原型；搞清楚产品可行与否的原因，找到解决问题的途径，用户原型才是王道。

产品管理：软件开发是个种瓜得瓜种豆得豆(GIGO)的过程,产品设计得差,开发出的产品就差，因此产品经理责任巨大。大家对产品管理的理解存在误区：它不是产品营销也不是项目管理。

PS：上周4、5在上海的PM-China产品经理大会上见到了Marty，看到这里的同学，再给几句他老人家的话吧，请带着自己的思考去读：

做产品要沉浸到用户中去，但问题是，大多数产品根本不知道自己的用户是谁。

如果你继续改进一个已经满足需求的产品，你终将毁掉它。

成功的前提是准确定义成功——要解决什么问题Why，谁的问题Who，如何解决How。

工作就是为用户创造价值，想一下自己做的事情为公司的用户创造了什么价值，如果想不出，那就危险了。

产品探索团队只需要三个人：Product Manager，Lead Designer，Lead Developer。

跳跃性思考，迭代式前进。

产品经理的技术背景不可或缺，至少，要能判断产品的可实现性。

产品经理快速成长的两个捷径：跟一个牛逼的产品经理师傅，去一家创业型公司做。

一句话点评：组织结构会影响人们的行为。只要角色定位准确、管理方式得当，大多数的组织结构都是可行的，如果贵公司的组织结构和任何理论推荐的不同，公司却运转良好，建议你保持这种结构不做任何改变。

Marty Cagan发表于2008年4月16日，原文链接，译者：潘希颖 / 审校：姜沈励 林航 徐定翔

我曾讨论过产品组织中的几个关键角色（包括产品经理、项目经理、交互设计师、视觉设计师、可用性工程师、原型制作人员、工程师、架构师、测试人员/QA和产品营销人员），以及这些角色之间的关系，然而如此复杂的组织结构依然会让企业摸不着头脑。

虽然每个产品组织的组织结构各不相同，但我认为，在过去的几年内，已经出现了一个标准的组织结构。而它的出现存在其合理性。

其实，组织结构并不是我关注的重点，我对组织中各个角色及其相关职责的关注程度更高。我相信，只要角色定位准确、管理方式得当，大多数的组织结构都是可行的。而且我认为，与其照搬一个成功企业的组织模式，不如根据领导团队的特点定制一个更加符合企业自身情况的产品组织。

我们都知道，组织结构会影响人们的行为。在其他条件不变的情况下，如果依照下述方式改变公司的组织结构，会收获到意想不到的好效果。

我这里讨论的对象是产品部门，并不涉及公司其他部门，比如销售、客服、财务、业务拓展及IT（非产品开发）部门。

我认为CEO、COO，以及子公司的总经理都需要将他的员工明确地划分至三个部门：营销、产品管理及设计、产品开发。并保证这三个部门同属于公司组织结构的最高一层，而不出现其中一个部门隶属于另外一个部门的情况。
建议一个中小型公司的CEO/COO，或者大公司的业务经理将组织结构做出如下安排：

–营销部门包含其企业营销（corporate marketing）、营销传播（marketing communications）、现场营销（field marketing）、产品营销（product marketing）。

–产品管理及设计部门负责产品管理和用户体验设计（交互设计/信息架构、视觉设计、原型制作、用户研究/可用性开发），如果条件允许，该部门还可引进行业专家。

–产品开发部门主要负责产品架构、代码编写、质量测试、产品发布、平台运营（SaaS软件运营公司）和项目管理（PMO，项目管理办公室）。

注释：

–为内部员工技术服务的IT部们有别于产品开发部门。这点在以后的文章中我会详细描述。在此，我只强调一下，这两个组织在需求上有本质的区别，因而管理方式也该有所区别。通常是由首席信息官CIO管理IT部门，而由CTO（首席技术官）或 VP（产品开发副总裁/工程部副总裁）来负责管理产品开发部门。

–在某些公司将PMO（项目管理办公室）作为最高级别的管理部门，这本身没错。但多数时候，PMO是产品开发部门的一部分，因为项目经理管理的大部分资源 都在产品开发部门里，因此产品开发负责人会全权负责产品的实施与交付。但不管在什么情况下，项目经理还是直接受项目管理办公室管辖。

–不管将用户体验设计归入营销部门还是产品开发部门都会产生问题。用户体验团队（特别是交互设计师）和产品经理就应该是拴在一根绳上的蚂蚱。为了使产品经 理与用户体验设计团队的合作更加紧密，越来越多的公司选择将产品管理和产品设计合并为同一个部门（但每个职能都有各自的负责人，如产品管理总监负责产品战略，用户体验总监则负责平台/软件的整体信息架构及风格）。

–在营销部门里，通常也会有一些负责营销项目和广告的图形设计师。用户体验组织中的视觉设计团队可能也能满足营销工作的需求，但我觉得在营销部门设立这样的职位会更好。强大的用户体验离不开对交互设计的持续关注和对应用程序的可视化设计。而这些图形设计师的领导者则应该清楚如何为产品团队提供支持。如果你的创意总监是产品类视觉设计和营销类视觉设计的双项全能，那么你的公司就有福了，因为这样的视觉设计团队可以同时满足两种设计需求，所塑造出的品牌形象的也会非常一致。但是，如果视觉设计团队负责人隶属于营销部门却不了解产品的需求，就必须尽快做些改变了。

–不要把用户研究和可用性研究混为一谈。用户研究是以人口统计学和消费者行为学（包括购买模式）为基础对客户进行分析与研究。因此，只要产品经理和交互设计师能随时找到用户研究人员，且相互之间建立了良好的工作关系，就可以将用户研究作为营销活动的一部分。而可用性研究是对人物角色、原型，以及如何让用户能够方便地使用产品进行具体的研究。与用户研究不同，可用性的研究成果会直接反馈给交互设计师、视觉设计师和产品经理。因此，可用性研究人员是用户体验设计团队不可或缺的一部分，只有这样，在研究产品的过程中，他们才能更好的与其他成员合作，他们的研究结果才能更好更快地反馈给相关人员。

–有的公司将产品营销归为产品部门。这种结构不会产生大问题，没准还有一定的优势。但我还是认为将产品营销独立出去会更好一些，因为这样营销人员对自己的角色定位能更加准确，产品管理和产品营销之间的职能划分也更为清晰。但即使产品管理和产品营销同属于一个部门，也不应该将各自的职责混为一谈。

–创业型公司的组织结构通常比较简单，因为相对于组织结构而言，公司更看重个人能力。可一旦公司走上正轨，进入快速发展阶段，尽早采用有效的组织结构会是明智之举。

–如果贵公司的组织结构和我推荐的不同，公司却运转良好，建议你保持这种结构不做任何改变。但如果你的团队挣扎在痛苦的边缘，好产品的诞生比预计的要困难，就可以考虑将组织结构朝上述方向改进一下，看看会不会有所改善。

特别感谢Chuck Geiger和Kyrie Robinson对本文的贡献。

P.S. Marty Cagan将出席PM-China首届产品经理高峰论坛，然后，我可能会客串一下主持人，呵呵，详情请见：http://www.pm-china.org。

本文节选自《启示录：打造用户喜爱的产品》一书作者的博客。该书从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。

一句话点评：貌似Marty对“大爆炸式的发布”深恶痛绝，希望大家用增量式设计、构建、测试及发布的方式来替代，但“大爆炸式的发布会”是ok的营销方式。

Marty Cagan发表于2010年2月9日，原文链接，译者：译者：唐丰能 / 审校：潘希颖 林航 徐定翔

什么是“大爆炸”式发布？

这是指一个项目团队经过数月的努力，构思让自己的作品在一个大型新产品发布活动中一炮打响。

大爆炸式发布不等于瀑布式开发(有关瀑布式开发的来历，请参考《启示录：打造用户喜爱的产品》第27章)，但它是瀑布式开发中常见的最终环节。不止在瀑布式开发中会采用大爆炸发布，Scrum团队实际上也被迫采用大爆炸发布。

为什么大爆炸式发布会产生问题？

因为它几乎从来都不顺利。通常时间紧、任务重，要发布的版本内容总是越变越多（管理层都是急性子，只要他们想得到，总是希望加入更多的功能）。过不多久，问题就来了，你要么大修大改，要么痛苦地在功能上做裁减。

此外，采用大爆炸式发布的产品，几乎没有什么时间可以让你根据上线后的实际数据对功能进行调整。很多时候，结果和预期有出入，可此时已无力回天。

此外，一次性地做出过多的修改，网站的稳定性会受到严峻考验，因为只有在上线之后你才能发现这些问题并尝试解决它们。即使不存在稳定性方面的问题，用户也会因网站一次性改动太大而心生反感。

既然有那么多问题存在，为什么还会选择进行大爆炸式发布呢？

可能有以下几个原因。

有时是因为营销部门想举办一场大型的发布活动以达到震撼效果，他们觉得在活动准备好之前，产品不应该被曝光。 还好我们不必像以前那样经常做大型发布活动。即使举办了这样的活动，也要明白大爆炸式营销不等于大爆炸式产品发布。你可以采取循序渐进的方式开发产品，一点一点地发布新功能，最好让用户几乎察觉不出什么变化。

有时是因为主管定下的项目完成时间太具挑战性，要按时完成任务，产品团队不得不减少测试和发布的时间，以保证有足够的时间用于产品开发。我知道这样做也是 逼不得已，但是产品不应该用这种方式开发。如果真的要按时发布，最好的方式就是采取增量式开发和部署。让产品按时上线不一定要采用大爆炸式发布模式。

有些公司，特别是大公司，坚持进行项目审查和过程监督，从而“成功”地将团队引向瀑布式开发，最后不得不选择大爆炸式发布。例如，他们会说：“你可以继续 研究这一想法，但真正动手前，必须要通过评审。”于是发布任何功能之前，他们都要进行一次评审。这样一来，不想把团队引向瀑布式开发都难。也许你不得不给 你的上司来场“汇报演出”，但你要做的事情还很多，别为了这点小阻碍就垂头丧气。事实上，你要是把原型和真实的用户反馈拿来让上司进行评审，没准还能给他 们留下一个好印象。评审一结束，就赶快继续你的增量式构建、部署和测试吧。

所以，如果有人要求你采取大爆炸式发布，尽可能通过增量式设计、构建、测试及发布的方式来替代它。

本文节选自《启示录：打造用户喜爱的产品》一书作者的博客。该书从人员、流程、产品三个角度介绍了现代软件（互联网）产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。

Marty与他的《启示录》，新浪要不要这么小气啊~~~，算了不改了

#Marty Cagan答产品经理问#硅谷产品集团创始人暨《启示录》作者Marty Cagan即将要来华讲座。现征集产品经理的提问，请Marty Cagan解答。请各位皱眉的、苦脸的、抓狂的产品经理们尽情吐露心声，将苦恼统统倒向Marty！P.S.请尽量用英文提问，有翻译困难请求助万能的微博~ 欢迎在文末提问，或者访问七印部落微博留言：http://weibo.com/1939249870/xthKZyvdh

一句话点评：正好是产品经理的校招季，虽说和社招看重的地方有很大区别，这篇长文还是很有参考价值的，顺祝大家国庆假期愉快~~~

本文节选自《启示录：打造用户喜爱的产品》一书和作者的博客，并发表在《程序员》杂志11年07期，本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享，谈到了招聘产品经理的标准，以及产品经理应该具备的特质。作者Marty Cagan是享有世界声誉的产品管理专家，曾经担任网景副总裁、eBay产品管理及设计高级副总裁。译文由姜天纬 @七印部落 出品。

寻找出色的产品经理

“哪里能找到出色的产品经理？”CEO经常问我这个问题。

我总是这样回答：出色的产品经理就在公司里，只不过在其他岗位上，有可能是软件工程师、用户体验设计师、系统工程师，等着伯乐去发掘。无论你打算从公司内部还是从公司外部招聘产品经理，必须清楚合适的人选应该具备哪些特质。这一章，我将列举产品经理应有的特质。

个人素质和态度

技术可以学习，素质却难以培养，有些素质是成功的产品经理必不可少的。

• 对产品的热情

有这样一群人，他们对产品有一种本能的热爱，把自己生活中的一切事物都看成产品，怀揣对优秀的产品的热爱和尊重。这份热情是产品经理必备的素质，是他们夜以继日克服困难、完善产品的动力。这份热情能感染团队成员，激励所有人。

辨别这种特质很容易，可以让应聘者谈谈自己最喜欢的产品及喜欢的原因，聊聊不同领域的产品和他讨厌的产品，问问对方，如果有机会，他打算怎样完善自己最喜欢的产品。热情是难以伪装的，虚伪的做作容易毕露无遗。

• 用户立场

理想的产品经理不一定来自产品的目标市场（这种情况有利也有弊），但是他必须融入目标市场。这一特质对制造大众产品的高科技企业尤为难得。我们倾向 于从自己的角度去理解用户和市场。事实上，目标用户的经验、喜好、价值观、知觉能力、忍受程度、技术理解很可能与我们的大相径庭。

可以就产品的目标市场向应聘者发问，让他谈谈如何换位思考。了解应聘者对目标市场的感觉，最重要的是看对方是尊重目标市场希望融入其中，还是打算一意孤行改变用户习惯。

对国际化的产品和针对特定地域的产品来说，换位思考尤其重要。各种文化虽有共通之处，但也存在许多差异。有些差异对产品无关紧要，有些则至关重要。应该考察应聘者是否足够了解目标市场，能否区分这两种差异。

• 智力

人的智力水平是无法替换的。产品管理需要洞察力和判断力，因此必须具备敏锐的头脑。勤奋当然是必需的，但从事这项工作光有勤奋还远远不够。

招聘聪明人是项知易行难的任务，结果在很大程度上取决于招聘者的能力和可靠性。常言道，“物以类聚，人以群分”，此言不虚。方法之一是测试应聘者解 决问题的能力。微软令人称道的、深入而有效的面试，即是考察应聘者解决问题的能力，通常由一位或多位领域专家就一个问题对应聘者进行深入考察。面试官不关 心应聘者是否知道正确答案，而看重应聘者解决问题的思路和方法（智力优于知识）。如果应聘者回答正确，面试官会将问题略作调整，询问应聘者在新情况下如何应付。重复这个过程，直到应聘者被迫处理他不知道答案的情况，说出解决方法。

阅读全文…