做产品设计的最早半年，一直只是做需求，关注的焦点是产品需要哪些功能，具体应该怎么做，通过与用户接触，写出需求文档；接着又需要负责项目，从立项、需求、开发、测试到发布。这几乎就是第2、3章和大家聊的内容。2008年开始，项目的那些工作我也比较熟悉了，渐渐地，我开始和产品有关的更多团队接触。“以人为本”有一种特别的解释，它说互联网、软件项目的主要成本是人力资本，就是我们的团队。
第4.1节从全局的角度提出了“大产品、大设计、大团队”的概念。在前面几章的基础上进一步扩展视野，让我们看到“产品之大”、“设计之大”、“团队之大”。
作为产品经理，我们要毫不推辞地主导产品的一切，培养舍我其谁的霸气，可以本位主义一点，把自己看做团队的中心，如图4-1所示。
图4-1 “我的产品我的团队”缩略图
我们先谈“游走于商业与技术之间”的产品团队，主要分为三部分：一是狭义的产品团队，“心思缜密的规划师”；二是用户体验团队，“激情四射的设计师”；三是运营团队，“‘阴险狡诈’的运营师”。
接下来是“商业团队，冲锋陷阵”的他们时刻战斗在与用户接触的第一线，又细分为市场、销售、服务等角色。
然后是“技术团队，坚强后盾”的他们，可以分为三部分：开发团队，负有架构、编码等职责；测试团队，需要做功能、性能等各种测试工作；运维团队，管理着产品的数据库、服务器、软件配置等。
还有一支支撑团队，总是处于“容易被遗忘的角落”，除了提供资源的老板们，还包括默默奉献的法务、财务、行政等同学。
本章的最后一节，我们来细细体会“大家好才是真的好”，我觉得比做产品更重要的是让团队里的同学工作得开心，所以我们会聊聊“所谓团队文化”，再回到产品经理自己的技能上，分析一下听起来很“虚无的无授权领导”。
4.1 大产品，大设计，大团队
我想说的第一句话就是：所有和产品有关的事都是产品经理的事。
我渐渐发现产品的概念其实远不止要做哪些功能，还包括了诸如上线后的运营手法、线下宣传的各种物料准备、定价与促销的策略，甚至开发票的流程等，它们共同决定着产品最终的体验和用户的感受。所以，我开始和公司里各个部门的人打交道，于是有了“大产品、大设计、大团队”的概念。
下面我们会站在一个比较高的位置，一看“产品之大”，了解一下“产品生命周期”与“商业、产品、技术”的铁三角；二看“设计之大”，从多个角度看看不同层次的设计；三看“团队之大”，辨析“职位与职责”的区别，体会“从几个人到一家公司”的过程。
4.1.1 产品之大
产品之大，我想可以从时间和空间两个角度来说。
时间是指产品的生命周期，我们在之前两章中讲到做需求、做项目，忙了半天产品的1.0版本上线之后，其实才走完了生命周期的一小步，产品刚刚呱呱坠地，后面还有产品的青年、壮年、老年，每个阶段都有不同的挑战等待着我们。
空间是指做产品需要考虑的三个大方面：商业、产品、技术。任何一个产品，扩大至公司，都是由这三方面组成的，三方面有一点做到极致就很不容易，再配合上不是很弱的另外两方面，可能就是一个成功的产品和公司。
下面，我们分别展开讨论。
时间之大：产品生命周期
最早体会到产品的生命周期，是“公司的生命周期”给了我启发。这个思想来源于摩尔的《公司进化论：伟大的企业如何持续创新》和《跨越鸿沟》【1】，读完之后我觉得产品与对应的市场、用户好像都是有生命的，他们都会从幼小发展到成熟，最终老去，不同时期的产品与市场、用户都有其特点，最佳状态就是彼此之间完美的配合。结合自己做过的产品，从五种用户群体的角度，说说其间的过程与体会。这五种用户群体如图4-2所示。
图4-2 产品生命周期里的五种用户群体
创新者（Innovators）：新鲜感强，消费能力强，但是忠诚度不高，需要新鲜的东西不断刺激。这批人都有Geek【2】气质，乐于探索。产品刚上市，甚至未上市的时候，主流用户往往是创新者。
他们的特点与产品设计人员比较像，很容易打成一片，比如建立共同的IM群，经常交流，创新者经常给产品提出很好的意见和建议。所以设计此阶段的产品会让我们比较兴奋，似乎创意总像地里的野草，割都割不完。不过，虽然我们可以利用创新者帮助产品尽快成长，但由于创新者总是极少数，所以商业利益无法保证。更何况创新者“喜新厌旧”，往往比产品开发走得更快，想尝试新技术甚于解决问题。所以这些创意也正像“野草”，必须由我们做出价值判断，要防止产品被它们变成荒地。
早期追随者（Early Adopters）：观念比较新，但是需求目的性很强，需要迅速能够解决其问题的产品。他们是信息达人，可能很早就知道产品了，但不会盲目试用，而是先从其他渠道主动了解这个产品是干什么的，反复验证，确认对自己有用以后才会尝试，好在这批人如果开始用了会比第一种人忠诚度高很多。
我比较像这种人。早期追随者和创新者最大的区别在于，早期追随者不是为了尝试新技术而使用某产品，而是为了解决某些需求才使用，早期追随者也会给产品提很多的想法，但他们是从需求出发的。这批用户对产品发展价值极大，最好牢牢抓住，将来可以发展为产品的种子用户，不断地给产品提供改进意见。产品上市后的早期，主流用户通常是早期追随者，这时候产品可以做得偏向“专家用户”，产品的进化主要体现在功能的不断创新上。
早期主流用户（Early Majority）：是产品大规模产生商业价值的用户群，他们是典型的实用主义者，也是生活中最常见的一批人，偶尔被动地听到过新产品，但觉得正在使用的老产品也能解决问题，就不会更换，但心中还是对新产品存在期待，希望有机会试一下。
《跨越鸿沟》里说的“鸿沟”，就是冲出“早期追随者”进入“早期主流用户”的阶段。这时候的产品与早期有很大的不同，需要面向主流的“中间用户”和“新手”，而非“专家”了。所以在产品进入这个市场，接触这批用户的时候，需要尽量做得简单易用，才能迅速占领尽可能多的市场份额，因为这帮用户没工夫研究，他们需要的是一个能够更好地解决问题的产品。从这个阶段开始，产品渐渐稳定，小修小改也不那么让人激动，回顾一下第2.2.5节的“生孩子与养孩子”里说的，从这时候开始，我们的主要工作从“生孩子”变成了“养孩子”，不过这也是真正获得商业回报的开始。
晚期主流用户（Late Majority）：这部分主流用户和早期的区别也许是心态上的。早期主流用户对新产品有尝试的愿望，而晚期主流用户对新产品心存抵触。他们直到老产品已经渐渐地出现明显的劣势，才会很不情愿地使用新产品。
比如我家里的一些长辈就是典型，全自动洗衣机已经成为主流之后，他们在购买的时候还是会考虑老式的双筒洗衣机，除了价格因素之外，他们最大的理由就是“用习惯了，全自动的按钮太多，不知道怎么用，不想学”。这个阶段产品已经定型，用户其实对产品也比较了解，市场竞争也相当激烈，所以仅仅通过功能竞争来获得用户再也不够，是典型的市场营销发力的时刻，需要通过强大的心理攻势来赢得晚期主流用户的认可。这也就是“微笑曲线”【3】右半边上翘的嘴角发力的时候。营销的创新，如果做得好，就可以达到“一招鲜吃遍天”的效果，并且相对于研发阶段的投入比较少，产出快速、可预期，是收割商业回报的大好时期。
落伍者（Laggards）：最后一批用户，他们的附加值已经比较低了，如果我们实际一点，就可以更注重眼前利益，在不违背道德标准的前提下，赚一票是一票吧。这时候，产品渐渐退出，市场也渐渐萎缩，或者说转移，因为必定有新产品成长起来，长江后浪推前浪，前浪必然死在沙滩上。
上面的生命周期只是一种解释，现实的产品、市场、用户并不会严格按照这里所说的阶段走，有的产品某个阶段也许特别长，或者非常短，甚至没有；有的产品也许会同时处于多个阶段，一浪又一浪地重叠在一起，部分功能已经走到晚期主流用户，部分功能还在早期追随者阶段。
所以，对于我们来说，必须找到背后不变的应对之策，不管哪个阶段，都是要先明确，我们现在要主打哪种类型的市场与用户，他们的特点是怎么样的，然后再决定应该做什么产品、用什么功能来满足相应的需求。
空间之大：商业、产品、技术
2007年年底，“大产品”的概念在脑中已经出现好几个月了，一方面总是听到一些前辈在讲，另一方面自己也在思考，一个产品最终的商业化成功与否，推及一个公司的成功与否，所有的影响因素似乎都可以归结到“大产品”的空间上，具体点说，是商业、产品、技术三个方面，如图4-3所示。
图4-3 商业、产品、技术的三角支撑
三角形是最稳定的结构，从产品与公司的发展角度来看，似乎也是这样。
商业，在公司里主要由市场、销售、服务等部门来考虑，他们决定产品的销售渠道、价格策略、促销策略、服务方式等。比方说，再好的产品，如果卖得太贵，目标用户负担不起，那注定要死掉。又如促销活动与产品库存的准备没有配合好，结果很多用户下单却无法满足，也会给公司造成极大的损失。
产品，此处是狭义的，由我们平时说的“产品部门”，包括产品设计、用户体验、产品运营等部门来考虑，他们决定了产品的功能范围、交互流程、视觉表现、运营手段等。这些是我们最熟悉的，试想一款单制冷的空调，在夏天热得要死，冬天又冷得要死的长三角，是注定卖不好的。
技术，主要由开发、测试、运维等部门考虑，他们决定了产品的稳定性、性能、Bug数量等特性。我在2003年前后曾经使用过一款摩托罗拉的T720手机，当短信的收件箱里有50条以上的短信时，再看新短信都出奇的慢，要等10秒以上，很快就让我无法忍受，换了手机，把它送给了收发短信都不太多的长辈。上面这个例子说明性能也会影响用户对产品的体验。
这三个方面共同构成了“大产品”在空间上的三个维度，我们可以理解成，他们的乘积决定了产品最终成就的大小，任何一个维度上的提高对产品都大有好处，任何一个维度太弱对产品也都是致命的。
下面是我想说的重点：
上述三方面，任何一个公司必然有它的强项和弱项，它不可能也没有必要在这三方面都很强，一是因为构建“性价比团队”的考虑，二是因为都强的话互相压不住反而造成内耗，所以更重要的是找到自己公司、或团队、或产品的那个突出的刀尖，也就是所谓公司的DNA。
非常明显，Google是技术主导的团队，从一位在Google做过市场工作的女生那里了解到，工程师在Google拥有绝对的话语权，而市场人员的地位相对较低；Apple则是无可争议的产品主导型公司，它的设计已经拥有了一种气质，它的产品几乎件件都是艺术品，就算现在Apple做个手电筒，叫iTorch，我相信也能卖出不少；而Alibaba就是第三个方面——商业主导的了，商业的强势也说明了阿里为什么不招技术很强的应届毕业生，而Business Sense，商业感觉是在真实的商业环境中工作磨炼出来的。不过个人感觉，这两年阿里开始体会到技术的瓶颈，已经在加大技术方面的投入了。
通过上面这段简单的分析，大家可能也发现，一家公司哪方面更强，其实也是和其产品的特点有关的，所以说到底，这些方面都可以看做是产品经理需要关注的事情。
换个角度看，上面这段可以送给想找工作的朋友，大家在找工作的时候必须调查清楚自己的职位在公司里是不是最受重视的，是不是强势方，这很重要！举个不是很现实的例子，如果你在特种部队式的组织里，那么可以安心地做一个特种兵；但如果你进了塔利班或基地组织，那就抓紧时间进入管理层！
我们说完了“产品之大”，接着聊“设计之大”。
4.1.2 设计之大
产品的设计之大，体现在产品设计的多个层次上。
产品战略层面上的设计，决定了“做不做”、“做什么”，在第2章谈需求的时候说了一部分，第5章谈战略会再说一些；狭义的产品设计层面上的设计，要决定“做多少”、“怎么做”，前两章及这章都有涉及；而产品实施层面上的设计，决定了“谁来做”、“何时做”，主要内容在第3章的“项目”里。
有关设计，我们先来看个经常被引用的小例子。
上海的地铁一号线是由德国人设计的，看上去并没有什么特别的地方，直到中国设计师设计的二号线投入运营，才发现其中有那么多的细节被二号线忽略了。结果二号线运营成本远远高于一号线。
上海地处华东，地势平均高出海平面就那么有限的一点点，一到夏天，雨水经常会使一些建筑物受困。德国的设计师就注意到了这一细节，所以地铁一号线的每一个室外出口都设计了三级台阶，要进入地铁口，必须踏上三级台阶，然后再往下进入地铁站。就是这三级台阶，在下雨天可以阻挡雨水倒灌，从而减轻地铁的防洪压力。事实上，一号线内的那些防汛设施几乎从来没有动用过；而地铁二号就因为缺了这几级台阶，曾在大雨天被淹，造成巨大的经济损失。
德国设计师根据地形、地势，在每一个地铁出口处都设计了一个转弯，这样做不是增加出入口的麻烦吗？不是增加了施工成本吗？当二号线地铁投入使用后，人们才发现这一转弯的奥秘。其实道理很简单，如果你家里开着空调，同时又开着门窗，你一定会心疼你每月多付的电费。想想看，一条地铁增加点转弯出口，省下了多少电，每天又省下了多少运营成本。
设计里的学问很多，我们作为新人很容易思考不全面，甚至自作聪明，就像上例，国内的设计师希望“取其精华，去其糟粕”，但根本没分清哪是精华、哪是糟粕。我建议同学们有必要先看几本入门的书，学习华为的任正非引进新的管理体系时所用的策略——“先僵化、后优化、再固化”，慢慢找到最适合的设计方法。下一节里，我想介绍一些从书里学到的知识，并结合实践来谈谈我是怎么应用的。
产品设计的五个层次
作为互联网、软件行业的产品人员，我想《用户体验的要素》应该算入门必读书了。书里把基于网页的产品分为了软件类和网站类，又把用户体验的要素分为五层，我觉得这也是产品设计的五个层次，它可以帮助我们在脑海里建立起产品设计过程的地图，先贴一张业内著名的图，如图4-4所示。
图4-4 用户体验的要素
此图原型来自《用户体验的要素》，网友d8in对此图亦有很大贡献
战略层：明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点。例如，通常的商业目标是赚的钱越多越好，而用户则想花的钱越少越好，这种最底层的冲突没法通过产品设计解决，而要靠商业上找准价值的切入点。作为产品设计人员，早些年可能接触不到制定战略的过程，但仍然要深刻理解公司战略并尽可能发挥自己的影响力，这个话题是第5章的主要内容。
范围层：明确“做多少”，对于软件类产品，是确定功能范围；对于网站类产品，则是确定内容范围。这时候要做好需求的采集、分析、筛选、管理、开发工作。复习一下第2章的主要内容，先要“尽可能多地收集”，灵活运用多种用户研究的方法，不要遗漏，再“尽可能多地放弃”，因为我们的资源有限，只能做最有价值的，先做的“收集”不是为了“放弃”，而是防止遗漏任何“有价值的”需求。
结构层：考虑产品的各个部分互相之间是什么关系，上一步相当于把一桌子菜的原料都买来了，这一步就开始确定哪些原料组成什么菜，具体是蒸是煮是炒是炸了。对于软件类产品，主要工作有交互设计，对于网站类产品，主要工作有信息架构。这一步常见的产出物有软件的业务逻辑图、网站的站点地图等。一般来说，技术部门在这时开始全面介入。
框架层：到了这一步，才出现用户真正能看到的东西。对于软件类产品来说主要的工作是界面设计，对于网站类产品则是导航设计，两者都有的是信息设计。大家经常看到的网页，是上下结构，还是左右结构，导航条在哪里，分几级，都是这个时候设计的。对新人来说，常见的错误就是认为从这里开始才算设计，接到一个任务马上就开始想网站的页面应该长成什么样子，而忽略了上面的几层，这样在大前提没思考清楚的情况下做出来的产品必然会成为一个悲剧。
表现层：最后一步的主要工作包含了视觉设计和内容的优化，比如页面的配色、字体字号等，这里的表现决定了最终产品的气质。这部分是最有意思的，但好的设计师一定要理解商业和用户的目标才能做出正确的设计，毕竟我们不是艺术家。解释一下，设计师和艺术家的区别就在于要满足的对象不同，一个是“你！你！你！你！你！”，另一个是“我！我！我！我！我！”。
产品设计的这五个层次，从整体看是抽象到具体的过程，是从概念到实现的过程，又有一点从商业到产品到技术的感觉。虽然在时间上是顺序的，但各层之间的界限模糊，彼此交叉，而且必须反复迭代。对于很多创业团队来说，也许一个人就要搞定所有的设计工作，也没法区分今天做的是哪个层次的工作，所以这五层并不用写在纸上，而是应该记在心里，有时候可能一天之内做的事情就囊括了五层，但速度再快，设计的思路都是在这里，逃不掉的。
我用五个层次来写书
在正式开始写这本书之前，我问过几位作家是怎么写书的，比如《流血的仕途》作者曹昇、科幻作家刘慈欣，发现他们写书的方式，和我想的不一样。据他们说，基本上是顺序写下来的，甚至写作过程中自己也不知道后面会发生什么情节，也许和他们写的是小说有关系。而我的这本书，就很不一样。
2009年9月，我把本书样章的初稿提交给编辑同学，4万字出头，在Word里用5号字连图表一共近50页，从篇幅角度看有全书的1/6。回顾整个过程，无时无刻不感到自己是在刻意用做产品的思路来写作，有点像软件工程的瀑布模型，又有点敏捷开发的味道，更明显地是上一节提到的五个层次。
正式开始写样章之前，我给全书做了定位的分析、风格特色的设定、目录结构的搭建，有兴趣的同学可以回去看“写在正文之前”，这些工作是为了让自己对全书有个整体的把握，并把全书分解成若干个模块，方便接下来深入某一模块各个击破。通过样章的实践，我确定了写作的五轮模式。
第一轮搭建框架。以“章”为单位精确到最细的一级目录的，本书是四级，我会在每个目录标题下至少写两三句话说明这一段的主要内容与核心观点，保证章节的整体思路通畅。
第二轮填充文字。把两年多来积累的文字剪切入符合主题小节里，补写缺少的内容。这一轮尽量不考虑文字细节，先把想说的都说出来，保证码字的速度。随着实践的进行，我发现这一轮相对不用动脑子，所以充分利用比较零散的时间完成。
第三轮理顺逻辑。按顺序通读文章，重点关注段落、句子间逻辑的顺畅。这一轮主要的工作是调整段落、句子的位置，剪过来切过去；增加过渡句；删除废话等。我在这里会耗费极大的精力，经常把一句话反复地在几段文字中倒腾。
第四轮调整风格。关注语言的味道一致，增加例子、对话等、找轻松活泼，聊天的感觉；增删改图表，比如把某些文字用图表表达；突出本书特色，将不出彩的内容简化，添加有特点的内容。当然，我做这一步的时候，还是有些细节尚未完成，比如有的图表需要重画，有的图是照片，需要补拍，或者有的例子觉得不好，先占个位子等有灵感之后再换掉。
第五轮后期制作。完成四轮以后，才是初稿。我会先给编辑同学，听听意见，编辑也会把初稿发给前辈和同行评审，然后我会继续和编辑同学一起做从框架到细节的各种改造，大到整节的增删改，小到格式调整，图表调整，病句错别字等，以及很多我到出版后才能了解的事情。同步的，其他章节也开始从第一轮写起，并行前进。
这五轮，实在是很像互联网产品设计的五个层次：战略、范围、结构、框架、表现。写作的每一轮也不是严格线性，必然有时间上的重叠和反复，是一个迭代的过程。正如刘未鹏【4】所说：“手里拿着锤子，看什么都是钉子”，锤子是方法和工具，钉钉子是目的。我们知道了“产品设计的方法”，很自然地会想把它用到各个方面，只是，不能被方法所累，要时刻牢记目的。好在写书这件事上，我思来想去觉得这个方法确实不错，又好在，产品设计的各种思路，其通用性决定了它们确实是适合解决大多数问题的好锤子。最后再来一句，上述情况升级版的境界就是“想钉一个钉子，看什么都是锤子”，这才是“手中无剑，心中有剑”，解决问题的最高境界。
设计的“现实与浪漫”
设计之大，还表现在设计的“现实与浪漫”之间。
2008年夏，我看了Donald Norman大师的两本书，一本是《设计心理学》【5】，另一本是《情感化设计》。诺大师是先写了《设计心理学》再写《情感化设计》的，从中我似乎看到了一位认知心理学家、一位宗师从现实主义到浪漫主义的升华。
诺大师把设计的目标分为三个层次，即本能水平设计，行为水平设计，反思水平设计，有观点说是对应了心理学里人脑的三种不同的加工水平：本能的、行为的和反思的。本能水平就是纯生理的视觉冲击，就像“第一眼美女”，看上去就喜欢，没什么好说的；至于行为水平，我认为就是《设计心理学》一书的主要内容，主要讲的是产品功能、用户与产品交互层面的设计；而反思水平则是诺大师思想的又一次升华，通过《情感化设计》一书，把纯心理需求也纳入了产品设计的考虑范围。
行为水平的设计，和我们日常的工作很接近，能把产品做到好用、贴心就已经很不容易了，毕竟生活中仍然存在太多让人不满的产品。虽然大师举的都是传统产品的例子，但一些原则却是非常基础，让人印象深刻，比如：
反馈：动作前的可预测、动作中的积极响应、动作后的可评估。比如网页上的一个按钮，我把鼠标移上去它的样式有些改变，单击以后马上表现出被按下去的样子，点击完毕后告诉我后台的程序“正在查询，请稍候”。
容错：一些貌似多余的强制性设计，不可逆操作可以后悔。比如工业仪器上，设计师经常给一些重要的按钮上加个盖子，并且按下之后还需要再次确认。又如电脑USB接口的“防呆”设计，让用户只能从一个方向插入USB设备。对于错误的理解，我们要做到“用户没有错，所有的错都是设计的错”。
简化：充分利用用户已有的知识，利用心智模型，利用标准化，利用一切。比如现在各种软件默认的复制、粘贴功能，图标长得都很像，快捷键都是“Ctrl+C、Ctrl+V”。
当一个产品在行为水平上做好以后，就可以算是一个优秀的产品了，但要做到伟大，大师觉得，反思水平上的情感因素变得更重要。这对设计师提出了极高的要求，只有更进一步的不但好用，而且想想都或开心、或伤感、或恐惧……的设计，才会华丽丽地升级为ART，这里我不用纯大写不足以表达“艺术”这个词的牛气。达到这一境界的产品，也许iPhone算一个，它确实让人用起来很爽，而且达到了“就算用户用得不爽，也会不好意思说，而是认为自己没有理解设计师意图”的境界；也许一些创意家居用品算，淘宝上很多，比如做成花一样的台灯、人形的调料罐；也许游乐场里的过山车、海盗船算，用户的需求本身就是情感化，为了寻找刺激的。
不过，对于要给大多数普通用户用的产品来说，本能水平、行为水平、反思水平的设计还是要挨个满足的。第一个层次，本能水平的设计是基础，产品要有用，能满足用户的某种需求；第二个层次，行为水平的设计是保证，产品要能用，好用，顺利地解决用户的问题；第三个层次，反思水平的设计是升华，是难以捉摸的“用得爽”，对大多数公司来说，最多只是面包上的果酱，行为水平还没做好就去追求反思水平真的没有必要，真的做一个没有行为水平、只有反思水平的“卡洛曼茶壶”【6】，那也只能给那些没事儿就愿意穷得瑟的用户们去用了。
大家再一起默念一百遍：我们是现实的设计师，不是浪漫的艺术家……
4.1.3 团队之大
前文从几个角度讲述了设计的各种层次，下面我们再从“团队”的角度体会一下“大产品、大设计、大团队”。在上一章的“项目”里，我们谈到做事需要流程、文档、规则，其实这些最终都是靠人。只要团队里都是靠谱的人，大家做起事来就会特别轻松、愉快，这点我深有体会。
接下来，将按照一个团队从几个人逐渐变成一家公司的过程，来说说“团队之大”。
想当年，一个比一个猛
想当年，一个比一个猛！只要经历过创业公司或者创业团队，就知道我们都是这么过来的。有一次和同事们吃午饭的时候聊到最初是怎么做事的，发现真的很有意思。
测试的同学先开口了：
“我们那个时候哪有什么TC【7】评审啊，测试的任务都是完全交给我们自己搞定的，不清楚的地方只能去问开发。”
“当年，我们都不写TC的，大概几个功能点，自己凭感觉点点就好了！”
这时候，老板们笑了：
“我当年做开发工程师的时候，根本没有测试……都是自己测。”
“开始连美工都没有，也是自己画，后来公司发现实在太丑了，卖不出去，才找了美工。”
一位开发的同学很有同感，说：
“以前我们公司没PD的，都是开发自己做需求，然后白天跑客户，晚上写代码。”
PD们也不示弱，小明抢着说：
“原来我们的需求文档，就是从一个空白的Word写起啊，想到什么写什么，一份需求文档可能和一篇作文没什么区别，或者拿一张白纸写写画画就直接去找开发的同学做了，虽然现在有时候也偶尔这样，但性质完全不同了。”
“Demo也自己做，都会用Dreamweaver和Photoshop的！”
……
似乎，每个团队都是从这样开始，每个人都是全能战士，那个时候的感觉挺好，但随着产品的发展，团队总是从很少的几个人起步，渐渐产生了分工，最后变为一家公司。
从几个人到一家公司
上一节的故事给我的启发是，有必要思考一下做产品的团队，是如何从个人进化成一家公司的？这中间的各种职责为什么要切分？各种职位又为什么会出现？我的理解是这样的：
最开始，一个人的时候，好比在大学里做《C语言》的大作业，所有事情都由自己一个人搞定，这时候你可以认为自己是这个产品的产品经理、程序员、测试等任何人，甚至自己就是整个公司。
后来又有一门课，应该是《软件工程》，老师让大家分组完成大作业，通常同学们会把同组的人分为“技术”和“非技术”类，强一点的人都去做技术，简单地说等价于编程，而什么也不会的人就做非技术，类似于写文档。这里的文档人员就是将来公司里的策划、PD、运营等，但区别在于，多数公司里这类人员很强，很重要。我自己分析产生这个差别的原因是因为学校里的作业，大多数是已经明确要做什么，而且不会有真正的用户，所以只要有技术强人实现就可以拿到高分了，所以策划的工作就变成了附属。事实上，决定做什么其实更重要，这不能不说是我们所经历的学校教育的一个遗憾。
再往后，可能是毕业设计，或者自己出于兴趣而做的社会实践，就又产生了更多细分的职责。我们会发现“自己编程，自己测试”很难发现问题，于是把测试的事情独立出来，很多时候是随意地交给一些不懂技术的人去做。而原先的非技术概念也开始扩充，出现了专门做需求的人，他们会处理很多“对外”业务，即与客户相关的事情。而产品经理的概念，似乎除了编码的工作，都有可能去做……
其实很多创业公司的小团队，这时候也无非是这样：总经理管除了技术以外的所有事情，另一个副总写代码，就这么简单。
再往下说就是相当成熟的公司了，我觉得可以分为商业、产品、技术、支撑四大块，这些将在本章的第2～5节详细讲述。几十人，甚至几百人的公司也不外乎如此。
公司大了，人多了，新的难题出现了，那就是——
如何设计各种职位，让各种人（职员）与各种事（职责）互相匹配。
我个人的思路是这样的：我们做任何产品，或者说公司需要做各种各样的事情，由于事情越来越多，而分工可以使效率提高，所以我们把要做的事情分解成了各种职责，比如开发、测试，再细一点，比如功能测试、性能测试——这是相对容易分析的。然后，老板去找拥有相应能力的人组建团队，于是，由各种各样的人，即职员组成了团队，每个人都有特定的能力，比如有的人喜欢钻研技术，有的人喜欢和人打交道。所以简单想一下就会发现，只要职员的能力都可以和要做的事匹配，那就OK，一个人做一件事是正常的，一个人做几件事是正常的，几个人做一件事也是正常的。到现在为止，“职位”的概念还没有必要出现。
渐渐地，公司大了，要做的事情越来越多，分工越来越细，于是很自然地出现了很多人做同一件事的情况，比如有50个“Java工程师”。我们说到过“偶尔为之的事情只需要可行解，经常做的事情要追求最优解”，所以，我们不能每次都特意去找某个人，成本太高。于是，公司必须找出事与人之间的匹配关系，在“职责”与“职员”两者之间，出现了“职位”的概念，这就能让HR批量地帮我们找到合适的人。君不见，每个职位的描述里，最重要的两块内容就是：“工作职责：做什么事”，“职位要求：要什么人”。职位的出现，降低了用人单位与求职者两边的沟通成本，一个词“交互设计师”、“运营专员”，就能传递很多信息。
很多人问我最佳的产品团队应该是什么样的组织结构，怎么设置各种职位。现在你知道了，职位并不关键，在想明白做一个产品要完成哪些事情，做这些事需要拥有哪些能力的人，团队处于什么阶段之后，应该设置哪几种职位的答案自然就出来了。所谓最优团队，每个个案都不一样，别人没法告诉你。
所以，本章下文中，将讲述我的经历，大家尽量从职责的角度去理解，不必拘泥于我提到的那些职位。互联网与软件公司要做的事情都是类似的，但是每种职位具体做什么在各家公司有所不同，这并不用在意，只要每件事情都有人做就可以了。
接口人存在的价值
公司大了，必然会出现各部门分工做不同的事情，但是，有些事情总是分不清楚，总是需要多个部门之间来配合。比如产品上线以后，PD都会遇到日常的Bug处理、工单处理这类事，常见的故事是这样的：
我们开始很有激情，给客服的同学培训完产品以后，许下诺言：“以后用户那边，有什么搞不定的问题都转给我好了，把我的手机号给用户都可以……”。这时候PD也的确急切地想通过一切途径了解用户对产品的反馈。前几天还不错，每天都有客服转过来的几个问题，有时候也会把用户的联系方法要过来，直接和用户交流，收获不小。渐渐地，随着产品的用户越来越多，问题也越来越多了，我们感到忙不过来，更头疼的是发现很多问题是类似的，占据了日常工作的大部分时间，让人烦躁不堪。有一天，我们终于受不了了，跟老板说，我要变成客服的客服了……老板说，很简单啊，让客服部门确定一个接口人吧。
于是就像如图4-5所示，接口人做了你做的大部分工作，他不存在“变成客服”的抱怨，他本来就是客服的同学。之后，接口人给你的问题才是真正的疑难杂症，才是真正体现你价值的问题。
图4-5 接口人存在的价值
不管是客服还是其他部门，接口人一般会让相关部门中比较资深的同学来担任，他起到了问题过滤的作用，可以解决大部分一般同学搞不定的问题，并对相似问题进行合并。
后来，我体会到接口人还有个好处，就是缓解“办事要靠脸熟”的问题，一般让沟通能力比较强、已经和公司里多数人很熟的人来做接口人，事先明确了他们的职责，通过他们来连接多个部门的陌生人，可以减少部门合作时，陌生人之间的沟通成本。当然，最好能在公司里培养起“对事不对人”的文化，那会使得沟通成本大大降低。
我的理解是，部门协作出现问题，是因为“找不到共同的利益”，如果不是公司内部的合作就更头疼，合作的基础就是有共同的利益，或物质或精神，或短期或长期，但务必要找到。
我身边的矩阵型组织
任何一个超过几十人的团队，就必然脱离“一个班长带几个兵”局面，产生自己的组织结构，常见的有职能型组织、项目型组织和矩阵型组织。组织结构是对项目、产品等的支撑，组织结构的设计也可以看做是一种很高级的产品设计，这一节来谈谈我对它的理解。
职能型组织是把相同职责的人划分在一个部门里，有利于同类资源共享，互相学习提高，但公司的目标在分解到各部门之后，很容易不一致，而且每个部门唯一的客户就是“上面”，都只对“上面”负责，导致没有人对真正的客户负责。我和同事讨论认为，这种形式比较适合大规模运作型的公司或部门，适合计划经济，比如大多数工厂的车间，人真的可以当做可替换的“资源”的情况。
项目型组织正好相反，是把各种职责的人组成一个个的项目组或产品线，团队目标一致，有利于快速推进项目，但是会资源浪费。项目组发展下去就是事业部，甚至分公司。说明一下，从组织结构的角度讲，项目型组织的头是项目经理或产品经理（为了方便起见，这一段下面单说产品经理），和职能型组织的头——部门经理相对应。
矩阵型组织则是上述两种组织结构的融合，如图4-6所示，就是前两年某段时间我身边的组织结构，横向是产品线、业务线，为了对客户负责；纵向是资源线、行政线，为了资源共享。如果说职能型组织比较适合防守型的业务，项目型组织适合进攻型业务，那么矩阵型组织就是全攻全守。但它也有很明显的问题：对员工来说，一面是部门经理，另一面是产品经理，这样的“双头领导”总是很让人头疼，那么这两种职位可以通过兼任来解决矛盾吗？
图4-6 矩阵型组织
有一次培训的时候，老师解答了这个问题，答案是否定的。产品经理主要管事，有成就感，像“猎人”，类比到军事上，就是对打仗负责，需要有攻城拔寨的能力；部门经理主要管人，有权力，像“农民”，对练兵负责，贡献技术与人，有防守与后勤的感觉。那么，部门经理如兼任产品经理，就会用权力来寻求成就感，或者在产品KPI的重压之下，放弃农民的责任去做猎人，造成行为的短视，主动或被动地忽视团队能力的提升。这是人性的弱点，无法避免，目标不同导致手段不同。在矩阵型组织下，部门经理和产品经理就应该各司其职，至于“双头领导”的协调，应该由用人的产品经理提供建议，养人的部门经理决定对员工的考核，同时培养每个人对事负责的态度。
不过，在很多公司中难免会有同一个经理既管事又管人的情况发生。我想，只要明白了上一段提到的问题，这样也未尝不可，只是当事人需要自己权衡两边的得失了。而在公司发展壮大之后，组织结构可能会经历从单一型向矩阵型变化的过程，这又引发了一些问题：比如说职能型组织变革为矩阵型组织，部门经理的成就感会被剥离，于是该过程经常会遇到来自当权者的阻力。所以说，组织结构的变革大多会有人“流血牺牲”，变是找死，但不变是等死。就像有个小段子说的那样——修高速公路最难的是拆迁问题。这是个人最优与集体最优的矛盾，没办法。“局整问题”困扰人类已久，不论是个体，还是组织，必然是“在什么山头唱什么歌”。
4.2 游走于商业与技术之间
有一种说法说我们的性格，去做工程师会显得太外向了，而去做销售又显得太内向了，工程师们把我们当做业务人员，市场销售们却把我们当做技术人员……这就是我们，游走于商业与技术之间的产品团队，几种主要的角色如图4-7所示。
图4-7 产品团队简图
从这节开始，把产品经理当做中心，依次讲述围绕在周围的各种团队。首先，从产品团队出发，讲一下我心目中的几大主要职责，涉及大家经常听到的职位，如产品经理、产品规划师或产品设计师、需求分析师、产品运营师、交互设计师、视觉设计师、用户研究员、前端工程师等。我会按照产品从概念的规划到最终成型的顺序来说，这也是一个从抽象到具体、从商业到技术的过程。
需要再次强调的是，因为人员的能力、产品的形式、历史遗留问题等，下面的分工在各种团队里都有不同，职责的界限也很模糊，我只是说最常见的情况。好比在我待过的团队，PD经常要做部分交互设计师的工作，部分运营和市场工作，部分架构师、系统分析的工作，绝大部分用户研究的工作，以及项目经理的工作。
所以我认为，谁做什么事其实并不重要，重要的是我们对周边同学的职责必须有所了解，知道要做哪些事，并且保证这些事都有人做。
4.2.1 心思缜密的规划师
首先要讲的是狭义的产品团队，具体是指产品经理及其带领的产品规划师、产品设计师和需求分析师【8】，通常在团队中，都被简称为PD，但各人的具体分工会稍有不同。产品经理和产品规划师，更偏向于产品前期的规划，比如产品的市场定位、各个版本发布的时间计划等，在这个层面上，商业目标、用户需求是思考的焦点，当然，公司的管理层也会充分参与这个过程，较大的决策通常由老板们最终拍板。产品设计师侧重于做功能级的设计，编写需求文档，在某个模块上，他们很像一个小产品经理，比如，要做进销存，具体到库存管理是否需要提供库存警戒功能，警戒数字是只有上限或下限、还是都有，警戒数字设置是否需要批量操作等。更为细分的RA，只在部分部门里存在，在这种分工下，PD的工作尽量往前走，偏市场、用户，产品的规划；而RA尽量往后走，偏实现、技术，即写UC，做系统设计。
总的来说，狭义的产品团队所做的事情，最符合互联网、软件行业产品经理的招聘广告里的描述，他们有大局观，逻辑严密，理智而冷静，我们不妨叫他们为“心思缜密的规划师”。
从概念设计到信息架构
PD所做的工作，在之前的章节中已有大量描述，这里我们来查漏补缺，谈谈产品的概念设计与信息架构。战略相关的话题将放到第5章。
概念设计的产出物是产品概念图【9】，个人认为它比较像第2章里提到过的业务逻辑图，但比业务逻辑图更抽象。产出概念图应该是在需求采集之后，需求筛选之前，基本和需求分析属于同阶段的任务，在纷繁复杂的各种用户需求之中，我们需要通过概念图来理清思路，找出到底应该“做什么”，并将这些打算做的需求整合为一个合理的系统。
如图4-8所示是一张流传甚广的典型概念图【10】，它描述了在线的照片存贮、分享网站Flickr的产品概念。分析此图后，大家就清楚Flickr是用来解决什么问题、产品包含哪些模块，以及它们互相之间的关系了。
图4-8 Flickr产品概念图
不过，上面这种图毕竟太难画，要把产品想得很清楚才能画出来，这往往是产品已经成型之后了。那么，有没有简单一些的做法？我们常用的是以下两种。
第一，在思维导图上改画出概念图。用户需求采集上来，我们或简单转化为产品需求，或直接画在一张思维导图里。然后，开始整理这堆“乱七八糟”的东西，比如把各种需求做简单的分类，把一些条目打上各种标记，把相关的需求连几条线，写一些注释，就算完成最粗糙的概念图了。
第二，是找个会议室，用马克笔在白板上画出自己对将来产品概念的想法，完全不要受拘束，然后大家一起讨论改进。这样手绘的概念图很酷，大家可以试试，画完了拍下来，存到电脑上，有必要的话可以重新画成更漂亮的电子版。
这步做完，产品相当于有了整体的业务架构，下面就可以进入需求筛选阶段，大家来决定先做哪一部分、后做哪一部分了。所以说，概念图其实描述的是整个产品的内外关系，形式并不重要，重点要表达出下面两点。
► 产品与外界的关系：把产品整体看做一个系统，描述它与上下级系统、并列系统的关系，可能的话，勾勒出产品所处的产业链结构。
► 产品内部的关系：产品有多少模块、模块之间的关系如何，不用涉及数据流等细节，重点描述清楚不同的角色在系统里的身份。
概念设计是为内部而做的，为了团队的沟通，便于大家对产品达成共识。所以我觉得，完成概念设计之后，才可以开始信息架构的工作。相对的，信息架构是为外部而做的，为了设计出更合理的方式，把信息传递给用户。这个先内后外的过程，也可以看做是从“做什么”到“怎么做”的过程。至于信息架构的话题，有好几本书专门讲述，建议可从《Web信息架构》【11】看起。
可能有的同学会问，“概念设计”这个词也经常在写PRD的时候提起啊？没关系，我们不用纠缠词的本身。我想那不过是下一个层次的，针对某个功能的“概念设计”了，会涉及更多的细节，比如某个功能的业务逻辑图、流程图，普通用户、系统、管理员之间的关系等。
在这节的最后，我还想提一点，PD和普通用户看产品、想问题的角度通常是不一样的：PD习惯于从内向外，从本质出发；而用户习惯于从外向内，从表面看起。所以，不论是概念设计，还是信息架构，都应该从用户的角度出发，以用户为中心，这意味着将来产品的表现要更接近用户的心智模型。而技术架构层面真的不用太关注用户，我们留给工程师们吧。
PD的出身及其优劣势
有一个很有意思的现象，PD团队的成员，原来做什么的都有，有做开发、测试的，有做市场、销售的，也有我这样毕业了直接入行的。而技术团队则绝大多数都是上学时学技术，毕业后也做技术的。从这个角度，我们可以看出，PD作为整个团队的核心是合理的，因为PD团队的人员背景多种多样，可以和周边任何团队的同学顺利沟通，起到连接器和润滑剂之类的作用。
那么，各种出身的PD的优劣势是什么呢？我的答案很简单，你之前做的事情是你擅长的，那就是你的优势，也是你的劣势。对PD这种职位来说，没有任何一项技能是没用的，而任何人也没法掌握全部需要的技能。
从个人角度解释一下，比如一位从开发工程师转型为PD的同学，擅长的事情很显然是技术方面的，这时候就看他怎么用自己的“背景”了。在整个团队中，他最大的优势是懂技术，用好了，可以在产品早期的时候思考更全面，能在一开始就判断出哪些事情根本就不靠谱，从而避免浪费资源，并且在进入实施阶段后会与工程师沟通得更顺畅；最大的劣势也是懂技术，用不好，就会让技术压倒商业，在业务逻辑还没确定的时候就考虑过细的实现难度问题，导致方向走偏，进度受限。所以说，PD之前做什么不重要，我们必须是一个通才而不是专才。
从PD团队的角度来看，成员组成就应该尽量丰富，商业、技术等各种背景的同学都有会比较合理，这样可以优缺点互补，考虑问题更加全面。我身边有的团队，大部分PD都是做传统软件的项目管理或开发出身，在做产品的过程中，他们深感对互联网产品的“感觉”不到位，对用户体验有心无力，这就成了产品的短板。另外，公司里新人过多也是大问题，这也是小公司、高速成长团队必然存在的问题，老中青的梯队还是必要的，个人感觉经验在一年内的同学最好不要超过一半，而且需要有三年以上经验的同学压阵，这样的结构才稳定。
4.2.2 激情四射的设计师
“激情四射的设计师”，指的是用户体验部门【12】的同学们。这些同学给我们的印象总是有一些艺术家气质，他们追求完美，需要我们时刻提醒还存在着一个“商业目标”；他们想法多多，但有时候需要我们更主动地去沟通；他们经常也叫产品设计师……确实，很多时候他们与我们的界限很模糊，我想可以这样来区分，规划师更多的是“结构化思维”，保证产品有用，能满足用户的某些需求，让产品“从无到有”；而设计师更多的是“形象化表达”，保证产品好用，能让用户用起来舒服，让产品“从有到优”。两支团队齐心协力才能让产品内外兼修。
用户体验部门各种职责的细分，通常主要有如下几种。
用户研究员（User Researcher），一看就知道，是做用户研究工作的，他要利用各种方法进行用户研究，给产品决策提供建议。第2章的前两节里我们聊过相关话题，但太多的团队没有专人来做了，所以PD们经常充当用户研究员。
交互设计师（Interaction Designer），他要负责人机交互界面、用户操作流程的设计，典型的工作有导航设计、信息设计等，必须要了解很多商业的内容，理解功能的商业价值。举个例子，比如在商业目标是“注册用户数”的前提下，去设计注册流程是一页搞定还是分几个“下一步”，出错提示如何处理等。
视觉设计师（Visual Designer），在很多小作坊被简称为“美工”，他与交互设计师的界限也挺模糊的，他们主要做视觉设计，即用户第一眼看到的效果，比如页面结构、配色方案、字体字号、按钮的形状、颜色、大小、质感等。
前端工程师（Web Developer），互联网行业特有的一个偏技术的职位，要运用前端技术进行Web页面的开发，实现产品体验的良好传达。我们在网页上看到的各种很炫的效果，通常都是他们的杰作。
如果是更大的团队，可能还会细分出更专业的职位，比如说专门的文案设计师、信息架构师等，就我了解，国内没几家公司设置了类似的职位，所以下面还是从我亲身经历过的几件事里来看设计师们到底在做什么吧。
产品新首页诞生记
2009年夏天，“e网打进”的产品Portal【13】做了一个改版项目，叫“变脸”，回想一下，我们正是按照前文提到的产品设计五个层次——“战略、范围、结构、框架、表现”的顺序做的，设计师也从头到尾很充分地参与其中。
这个项目的缘起是为了统一公司几个产品的Portal风格，但我们希望能在老板给出的这个目标下找到“变脸”的更多价值。于是项目开始后我查看了Portal页面的访问情况，分析了用户场景，画了如图4-9所示的场景图。
图4-9 产品Portal的用户场景
在“e网打进”刚上市之时，Portal页面只是付费用户的登录入口，有一个简单的填写账号密码的输入框，并没有额外的商业价值，但随着产品的成长，渐渐有了点名气，非付费用户访问Portal的行为逐渐增多，他们通过各种途径知道了“e网打进”，可能是通过搜索引擎，可能是听到朋友说起，有了点兴趣，但是到了这个页面以后，却看不到产品介绍、不知道如何购买，页面内容的缺失导致流失率很高。当时每个月有几万UV【14】，其中：
非付费用户的访客占大多数，超过80％，短期内相当稳定；付费用户约20％弱，目的其实很明确——登录，很少会东张西望看其他内容；极少数的经销商，有个入口登录后台也就行了。
有了上述分析，很直接的想法就是Portal要转型，重点满足普通访客，促进他们转化为付费用户。因此，我们加重了营销相关内容，力求创造更多的销售机会，也就是所谓的“潜在用户”。进一步思考：
潜在用户＝访客数×转化率
我们可以一方面通过增加页面的营销内容提高转化率，另一方面也可以通过SEO、公关、推广等方式增加访客数。下面只说前者，但两者的目的都是希望能加粗图4-9中访客到“潜在用户”的箭头。
之后，我们和销售、服务一起讨论，确认了目标，总结出Portal需要哪些页面和导航菜单的结构。由于整个站点的复杂度相对较低，所以这些内容被我们压缩在一级菜单里解决了，如表4-1所示。
表4-1 产品Portal菜单结构示意
接着是确定每个页面上都需要哪些元素，以首页为例，如表4-2所示。
表4-2 首页的元素
上面的工作可以看做“结构化思维”，意味着“战略、范围”的设计基本完成，接下来就是“形象化表达”了——“结构、框架、表现”——UE的同学就成了主角。如图4-10、图4-11、图4-12所示的这几幅图在第3.3.1节的“Demo也要我们做么”里已经给大家看过，所以这里不再说制作Demo的工具与方法，而是聊一下PD和UE如何分工配合。
图4-10 纸面Demo
图4-11 线框图Demo
图4-12 视觉效果图
一开始，大家一起讨论，手绘出首页的大概样子。PD要表达清楚每一个模块的商业目标，可以给出自己对页面的布局建议，但最终的页面结构由UE主导确定。
然后是线框图，PD有时候也会直接给出这个图，但在“变脸”项目中，是UE做的。大家仍要讨论确定，UE这时候会在设计的过程中融入很多自己的想法，PD要做到的就是防止走偏，保证大家对商业目标理解的一致。比如在图4-12中，大家讨论后确定页面为“左侧大、右侧小”的双列结构，并且左侧的内容主攻普通访客，右侧的内容主攻付费用户。
接着，UE做出页面效果图，PD安排销售、服务等相关方来做一次Demo评审，告诉他们这就是将来看到的页面，征求意见。他们一定会有各种疑问，这时候PD和UE需要确保每一个细节设计都是有理有据，包括每块区域的位置、长宽，每行文字的字体、字号，每张图片的颜色等，都不只是为了好看，而一定是与商业目标相符合的。
比如图4-12中，“立即购买”的区域用了页面上最醒目的橙色，在充满商业气息的蓝色氛围下很醒目；且位置在“e网打进”访客的电脑最常见的分辨率，即1024×768的首屏右下角，这归功于数据分析；加之又有个亲切的美女在向你招手，进一步吸引眼球。以上三点设计非常强势地突出了目的，至于是否太过，需要后续的效果分析来验证。
2012年4月在线上的这个页面“http://e.alisoft.com/”，整体和图4-12看起来还是很像的。今后一定会有变化，不知道你看的时候是什么样子。
新首页上线以后，事情还没有完，持续的监控和改进是必须的。所以在上线后的半个月、一个月、三个月这几个时间点，我们做了一些数据分析。从结果看，有一定的效果，比如访客黏度、网站停留时间均有提升，填写表单留下联系方式的潜在用户明显增多，具体就不仔细讲述了。
当交互设计遇到敏捷开发
让我们先回忆第3章谈论敏捷开发的时候说，我们说要快，先发布再说，慢慢改；而交互设计的理念是精雕细琢，慢工出细活。我们在纠结，大师们也纠结过。
2002年1月15日，交互设计之父Alan Cooper和极限编程【15】创始人Kent Beck在PK，话题是“当交互设计遇到敏捷开发”。
► Cooper大爷认为子弹很贵，因此在每次开枪之前一定要精确地瞄准。负责瞄准的人应该是专业的交互设计师。Cooper大爷很适合做一个狙击手，点射的命中率几乎能够达到100％。
► Beck大师认为有了敏捷开发，子弹变得很便宜，不需要瞄太准，打不准就再放一枪，没什么大不了，最终总能打中目标。Beck大师很适合做一个机枪手，机枪是不可以点射的，一般都是扫一片，用密集的火力消灭敌人。
还是那个道理，方法只有合适与否，没有好坏之分。也许“交互设计”比较适合传统领域、成熟公司、时间资源充裕的，公司在某领域中已经处于领先地位，目的是求稳，不犯错就是胜利；而“敏捷开发”适合新兴行业、创业公司，时间紧迫，大家都在赶，谁先出头谁就能占得先机，或者作为挑战者进入某个行业，团队本身灵活，失败了损失也不大，重来的成本低。从这点上看，互联网行业似乎更偏向于使用敏捷开发的方法，但敏捷绝不是在时间紧迫下被动的放弃交互设计，而是主动为之的一种思想，并且要将交互设计融入其中。
“交互设计”之于“敏捷开发”，正如哲学里“对立统一”的概念，有点像楷书与草书，没法评价哪个好哪个差，也许结合一下又出现了很赞的行书。两者考虑问题的角度不大一致，其实并不存在大的冲突。相反，交互设计与敏捷开发方法如果能够结合起来，就能以更小的成本交付令用户满意的产品。Patton大师已经在这方面做了成功的尝试，有兴趣的同学可以继续深入研究。
信息展现设计的例子
设计师们常做的工作中，信息展现是很重要的部分。同样的一堆信息摆在面前，展现方式设计的好坏可以让用户的感觉有多大差异？为什么同样的一个“任务”，有时一天就能“完成”，有时一周也可能没法“完成”？
这个例子是我在2007年从Google的一位产品经理那里听来的，任务的目的是展示美国的几个城市在不同月份的平均降水量。很自然的，一开始我们就会想到用一张表格，如图4-13所示，横轴是1月到12月，纵轴是城市名称，分别是San Francisco、Seattle、Chicago、New York、Miami，表格中每个元素就是某城市在那个月的平均降水量，单位是“英寸每月”。
图4-13 把数据表格化
图4-13已经把所有的信息都展示出来了，但重点不够突出，各种信息都使用一样的字体，让人不知道一开始看哪里，而如图4-14所示的图表就优化了很多。首先各种文字用了不一样的字体，图表的标题最明显，让人一眼就知道这个图表是说什么的。月份与城市信息稍微弱化以突出数据内容，特别值得一提的是这里用了不同深浅的颜色来突出数据，让人很容易解读出某个城市全年整体的降水情况，降水季节分布等信息。
图4-14 突出重点信息
我常说“字不如表，表不如图”，再回忆一下上面的图表，你还能记住Miami在8月的平均降水量吗？我是不能，但我记得Miami在夏季的降水量很大。这给了我们启发，其实要传递的并不是具体的数字，而是每个城市在全年的降水量整体情况与分布，所以说某个城市某个月的降水量，表达成类似“很多、多、少、很少”的形式会更好，数据只是给极少数做科学研究的人，在需要的时候可以查到就可以了，在表现形式上，我们可以处理成鼠标悬停在某个区域的时候，就展现出相应的数字。于是，我们进一步优化出如图4-15所示的图表，用很符合读者心智模型的水滴大小、颜色深浅来表示不同的降水量区间。现在更加一目了然了，San Francisco最干，冬天稍微好一些；而New York全年降水很平均……
图4-15 数据可视化
还可以优化吗？是的，还可以。上面几个城市为什么会有这样的降水情况呢？我们可以像如图4-16所示这样，把它们放进地图里，从地理的角度得到解释，比如San Francisco “因为三面环水，并受太平洋加利福尼亚寒流影响，是典型的凉夏型地中海式气候”，所以夏季降雨极少，冬天经常下雨。而Miami则“拥有温暖、湿润的夏雨型暖副热带气候”，所以降水充沛。图4-16可以与用户交互，把时间轴做了个动态展现，拖动时间轴，我们可以看到几大城市，甚至可以推测出全美国在一年中各地的降水情况。当然，如此炫的表达也有其弱点，那就是没法如图4-15一样一次性看到所有信息了，这个需要我们来权衡利弊。
图4-16 带交互的信息展现
有个细节差点忘记，图4-16中左上角的logo，有没有让你联想到什么？对了，flickr（flicker.com），同样的配色，同样的字体，同样的故意拼写错误，我想这应该是产品经理、产品设计师一种典型的闷骚表现吧，总想留个彩蛋，总想在看似严肃的场合下开点玩笑。
聊聊细节，文案设计
设计师是一群追求完美的人，所以在最后，我们再讲一个细节话题——文案设计。这里不是指网站里大段文字的编辑工作，而是指产品中随处可见的文字问题。自己的体会：因为文案问题很隐蔽，所以在各个产品中都普遍存在，包括本书，我想出版后也必然还有错别字和病句。虽说这不会对产品功能造成太大的伤害，但是过多的文案问题会使得产品整体感觉降了一个档次。我把文案问题分为三个级别。
低级阶段：错别字，病句，错误标点。比如常见的错别字：把“登录”写成“登陆”，打开一个网页可以算“登陆”这个网站，而输入了用户名、密码之后才是“登录”了这个网站，用英文Landing和Login就容易区分了；语句逻辑关系混乱，这属于小学的时候作文练得不到位，没事儿乱“因为、所以”、“如果、那么”；中文与英文的标点混合不分，陈述句最后没有句号等。这些错误没什么好说的，要极力避免。
中级阶段：用词不统一，不准确。比如“创建”与“新建”，其实结果都是一个意思——New，用哪个本无所谓，但是在同一个产品中不统一的话，会给人不专业的感觉；导航菜单用词的主谓、动宾结构不统一，经常看到同一个产品中同时出现主谓结构的“系统配置”和动宾结构的“管理客户”等菜单；又如“保存”、“确定”不分，一般来说前者是伴随信息的提交，系统有写入数据库的动作，而后者只是让用户肯定刚才的行为；再如“邮局”、“邮箱”、“邮件”等近似词语的不准确使用。
高级阶段：语言风格不统一，产品气质不统一。我们经常会发现，产品里同时存在由开发工程师随手写的“成功、出错提示”，和前台小妹帮忙写的“欢迎、促销信息”，所以用户在使用产品的时候，一会儿看到“数据库错误，CorpID不能为空”这种过于专业的术语，一会儿又看到“哦”、“啊”、“☺”结尾的感情丰富的句子，这两种明显不同的风格同时出现在文案中，简直是让用户冰火两重天。所以由一个人最终来统一语言风格是很有必要的，而语言风格又是由产品想传达给用户的气质决定的，比如聚友（myspace.cn）可以在用户登录后的欢迎词里写“好久没见，你是不是忙着去拯救全人类了？”如图4-17所示，我们看了会会心一笑，而这句要是出现在Oracle的财务系统里，那简直就要让人崩溃了。
图4-17 聚友的欢迎词
最后，需要给大家泼点冷水，虽然我们这么用心地去琢磨文案，但产品里的文案却是越少越好。用户都是凭着自己的感觉去使用产品，他们通常不会去看帮助、不会去看说明书，甚至不会看页面上一句话的提示，如果一个功能需要配合100个字的说明，那我们就要考虑这个功能是不是做得有问题了。
4.2.3 “阴险狡诈”的运营师
如果说规划师是产品的父母，把产品生出来；设计师是产品的老师，把产品教育好；那么运营师【16】就算是产品的老板吧，他们要把产品卖出去，让产品从“叫好”到“叫座”，让更多的人愿意使用产品。
这两年，网络上很多流行的人物、事件，后来都被披露是网络推手所为，他们策划、制造话题，运用病毒营销、事件营销等方法，让某些人获益。“幕后黑手”、“无商不奸”、“阴险狡诈”等词反映了他们不怎么好的口碑。不过如果大家只想这些词中的积极因素，倒是正好很贴切地描述了产品运营师。
产品做出来之后，不能直接向用户介绍功能，而是有一个把“功能转化为卖点”的过程，先要告诉用户产品“有什么用”，用户才有兴趣了解“怎么用”，之后要关注产品的市场反应，推动产品改进。所以，运营的工作非常重要，幸运的是，在几款产品的早期，我也参与过一些运营的工作，大家一起准备材料、策划方案，收获不小。
但很多PD一提到运营，除了微笑，还会咬牙切齿，为什么？我们先来看看产品与运营的战与和。
产品与运营的战与和
一方面，产品需要好的运营。今天已经不是“好酒不怕巷子深”的年代了，各种产品都极其丰富，没有运营，产品只能“养在深闺人未识”，慢慢消亡。另一方面，运营也需要好的产品，运营只能把人带来，而把人留住就必须要靠产品了，只有产品真的有用、能用、好用，才能看到运营产生的持续效果。
这样看起来产品和运营的同学应该亲如兄弟，但在现实中，产品与运营却总是充满矛盾，经常看到他们吵得面红耳赤，这又是为什么呢？
通常是因为运营的同学背着更直接的商业指标，比如年底前网站的PV（Page View）要达到1亿，用户活跃度要达到60％。大老板们的出发点通常都是好的，但传达到执行层面以后，就只是一个数字了，大家忘记了数字背后的目的。虽然说这样的简化、量化便于管理，但麻烦的是，数字总是有漏洞可以钻的，所以经常就是运营为了数字而数字。
如图4-18所示，是我身边的一个网站产品在2008年底做的运营活动，当时用了很多手段，有些甚至近乎“流氓”，可以看到数字是出现了爆发式增长，达到了PV的预期目标，但问题在于：PV并没有留住，两个月后再看PV的时候，发现和运营前没什么区别，数字背后的目的——增加网站用户数，并没有达到。
图4-18 运营的短期与长期效果
产品团队与销售团队也常常因为类似的问题而争论。这是运营的错，没分清目的与手段，只为提升PV拉了很多垃圾流量，而如果挖掘真正的用户则需要做更多工作——去寻找目标用户、去调研、去与产品团队合作；也是产品的错，那么多的PV，居然一点儿人都没留住；也许，更是数字惹的祸，老板们是否可以用更合理的数字来避免问题？比如追求注册用户数、活跃用户数等，而不是PV？也许，那些数字更难，或者看上去不会这么好看。
身边发生的这件事让我很困惑，特别是几个月后，这个团队获得了高层的褒奖，因为他们是数字完成得最漂亮的团队。但我仍然不是很认可这件事情，我不愿意去想，如果我背负着类似的KPI【17】，难道能强悍到不做同样的事吗？
客观地看，不论是高层、运营，还是产品团队做的事情，都是在平衡短期与长期利益。有时候产品与运营共同承担商业指标会好一些，但运营的同学总会显得急一些，他们希望尽快看到效果，而产品的同学则热衷于练内功，好在大家的根本目的是一致的，只是这个度需要双方共同寻找平衡点。
个人博客运营实例
有人说史玉柱是最好的产品经理，他强就强在对用户、市场、产品的理解上，他可以为了卖脑白金和N个大爷大妈聊天，也可以为了做网游没日没夜地玩……看过他写的脑白金推广计划，确实有酣畅淋漓的感觉，如同一场战争的策划。在我心目中，一次好的运营就是事前“预谋”，事中按计划执行，事后拿到结果并为下一次运营积累经验。自己在工作中一直没有完整地主导过运营活动，所以在2009年的二三月，我拿自己的博客练了练手，好好玩了一把。下面是当时情况的一些摘录。
2009年春节，行动前的策划。
定下原则：不花钱，只花时间；用户“质”重于“量”，所以不在意流量，绝对不会在无关的高流量场合做推广；第一轮运营以1个月为周期，KPI定为可以体现高质量用户数的“RSS订阅数”，1月底约200，2月底争取达到500。
几点考虑：
► “人人都是产品经理”必须以内容为王，要保证原创的数量和质量，这些是核心竞争力，所以春节期间的两周主要是积累材料，将MSN Space上已有的文章转移到新博客，并且做了一些推广活动的预研，考察了几个相关网站、特定版面的人气情况，初步判断各个推广渠道的优先级。
► 春节后的第一周先做试探性推广，主要考虑到还有一些目标受众没有开始上班，没有进入状态，全面出击定在2月9日开始的那一周，这是因为考虑到工作的第二周大家不会很忙，同时新年新气象，又都很有激情，互相学习讨论的氛围较好。
► 具体的推广渠道如下：（略）
执行到2月底的时候，我做了个小结。
回顾了2月的第一轮运营，只看我最关注的订阅数：推广进行到2月14日的时候，订阅数就达到了500，所以后两周我取消了推广计划，保持静默，做个无推广的对比，到月底订阅数自然增长到670。
然后，根据第一轮的经验，我制订了3月份运营计划，也是第二轮大面积推广的计划，希望订阅数达到1500。
以一周为单位分成4小轮推广，以4篇《产品经理值得……》系列原创文章为主打，说实话有点标题党，不过内容应该还是很实在的，它们分别是：
第一周，《产品经理值得听的13个培训》，谈谈参加过的培训；
第二周，《产品经理值得看的16个博客》，谈谈经常看的博客；
第三周，《产品经理值得交的10个朋友》，谈谈我梦想的人脉；
第四周，《产品经理值得读的12本书》，谈谈对我帮助很大的书。
每轮都是比较严格地按照计划执行的，周一中午发出博文，同步转载至UCDChina、CSDN专家博客，很幸运这两处都很帮忙，当天就上了首页；周二上午11点刚过开始QQ群推广，二线渠道的转载，比如豆瓣、5G、ChinaPM【18】、我在MSN上的旧博客等；周三开始选择性顶帖，在UCDChina上转载一篇旧博文；周四发一篇辅助博文保持更新频率。
到了4月初，我总结了3月运营的结果。
推广渠道方面，UCDChina、CSDN专家博客、QQ群是三大功臣，它们都带来不少访客。此外我注意增加了文章里的站内链接，其中第一、第四篇主打文章里都有很多站内链接，增加了不少额外的访问。而订阅数目标也完成得很漂亮，也许是我定得太保守了，3月10日订阅数就突破了1000，3月25日突破1500，3月31日突破1800。
并且，我又想出了一些新招，比如除了寻找产品经理聚集地以外，还把特定的文章，如写项目管理、网络营销、交互设计等的推荐给有想法转行的工程师、项目经理、市场人员；多和相关的优质博客沟通，互相推荐；充分利用QQ群邮件等。
在整个推广的过程中，我发现，运营就和任何事情一样，即使没有专门学过，但只要去做，就能不断提高，越做越好。经过二三月的推广，博客已经有了惯性地自然增长，直到2010年2月，我最看重的订阅数已经突破了10000大关。
一次无意识的“事件+病毒营销”
我在写本章初稿的时候，并没有这一节。虽然我做很多事情都是事先有计划的，但这次的“事件营销”和“病毒营销”，完全是无意识的行为。缘起是2009年10月26日晚上，我在博客上发布了一篇博文——《又是四年整，说个小故事，大家低调一点》。
2005年10月26日晚，Google中国成立不久，李开复来到浙江大学讲演。
► 我作为一名普通的学生粉丝，参与了这次活动的组织。
► 那天晚上，开复一行人挺多，演讲前后一直在永谦小剧场的休息室里休息。
► 我们给他们冲咖啡，但是发现没有足够大的壶。
► 所以很土地想到用脸盆，确实很诡异。
► 我比较空，以最快的速度跑回宿舍拿。
► 自己的脸盆正好装了脏衣服，已经泡起来了，没法用。
► 就顺手拿起室友的，学校发的那种，除了编号，都一样。
► 之后一切顺利，我还搞了一本开复签名的《做最好的自己》。
直到临睡前，我在电脑前，突然听到厕所里室友很疑惑地喊：
“啊，我的脚盆里怎么有股咖啡味儿？”
！！！……
PS：我后来去内场帮忙了，那盆咖啡到底谁喝过，我至今都不知道。
小明：“请允许我先囧一下……好了，继续吧。”
发帖之后，我没做任何事情，和其他帖子的几百到数千PV不同，到11月中旬，这个帖子的PV破万，也许对于大网站来说这不算什么，但它却成为iamsujie.com的第一热帖，要知道2009年3月我刻意推广的几篇文章，到2009年底PV最多也不过9000。这篇帖子的PV曲线如图4-19所示，
图4-19 帖子的浏览量曲线
从图4-19中可以看出，10月27日还算正常，只是稍微有一些转帖、分享的行为，谈几点：
► 博客本身数千订阅用户中，总会有人乐于分享；
► 自己的各种SNS、微博客的自动同步，可以带来一些浏览；
► 我从来源中发现，搜狐白社会（bai.sohu.com）、豆瓣等网站……都带来了几十个PV。
爆发出现在10月28日下午4点多，李开复老师（weibo.com/kaifulee）自己写了一条微博：
“朋友传给我一个博客，说我在浙大喝了‘特殊咖啡’。http://sinaurl.cn/hVnvI 怪不得喝完感觉‘脸色’特别好。”
之后，引起了爆发性的增长。开复老师提到有朋友转帖给他，那么这个转帖人就起到了关键作用，应该是博客的某个订阅者。直到11月12日，这个帖子的日均PV才降到100以下，而其中大部分都是开复那条微博里的链接带来的。有几点值得说。
► 这个事件本身具有一定的娱乐性，且没有恶意，不会伤害任何人；
► 那段时间李开复老师的创新工场的事情正火爆，他也正在高校巡讲，并且刚去过浙大；
► 微博的力量：转发当时李开复在新浪微博人气第一，有16万多的粉丝；
► 引起转载120多条，不过转载后链接过来的数量之和与开复老师的比起来都只是个零头。
这个事情的受益方也许是：
我的博客？这个帖子确实带来了很多流量，但质量不佳。访问者中，新访客占到了约80％，远超出我博客整体50％左右的新访客比例，只看一个页面就离开的比例，即跳出率达到70％，也高出博客整体十几个点。所以说他们大多数都是看热闹的，似乎并没有多少我在乎的“-1到3岁的产品经理”。这也是为什么我一直没有做“只要流量不要质量”的类似运营的原因。
李开复老师？10月28日的粉丝大约16万，领先第二名不到6000。到11月21日再看，已经30万，不过姚晨已经以33万高居第一，可以看出新浪微博开始从内测阶段的IT圈内逐渐走向大众。毕竟，李开复还是相对小众圈子的名人，从这个帖子另外两个流量较大的来源南京大学BBS（小百合）、上海交大BBS（饮水思源）就可以看出。所以，这条微博对他的亲和形象也许有帮助，但作用大小难以估计。
浙江大学？因为李开复后来又发了一条：
“浙大同学很好啊。我们这次去浙大，面试中脱颖而出的超过任何其他学校。以后他们入职后，我自己泡咖啡就是了。”
这篇引起了不少其他学校同学的妒忌和浙大同学的自豪感，有近百条评论与200多条转载。
这一切都是意外，但让我体会到了事件营销、病毒营销的力量。所以，这本书的营销，我已经尝试过几次，不知道你是否感受到了。
4.3 商业团队，冲锋陷阵
我是理工科出身，所以前几年总会觉得商业团队做的事情与技术团队比起来，都太虚，直到最近才渐渐体会到，我们觉得某样东西虚只是因为对它不熟悉而已。
前线的团队，主要任务是市场、销售，需要负责产品价格策略、促销策略、销售策划、渠道管理等；另一块任务是服务，也有细分，比如客户服务、技术支持、服务策划等。最最简化了以后的图示如图4-20所示。公司里经常出现的情况是谁直接创造效益谁牛气，所以经常是销售的同学“蹂躏”产品的同学，然后产品的同学又去“欺负”服务的同学。这里我特别想帮服务的同学说句话，他们经常被看成是支持部门，而实际上他们给产品带来的价值很大。“一手抓销售，一手抓服务，两手都要抓，两手都要硬”。他们都是和用户、客户最近的。如果说销售是增加新客户，让客户对某个产品第一次付钱，那么服务就是稳住老客户，让客户对某个产品不断付钱。
图4-20 商业团队简图
对于商业团队，很重要的一点就是在每一个项目的过程中，千万别忘了他们。因为PD主导的项目大多数工作都和技术有关，所以往往不关心，或忘记关心商业人员。这就需要我们主动一点，该叫他们的评审会都得叫上，上线前得酌情提供PPT或者组织内部培训，绝对要避免最后的产品演示会上，甚至已经发布以后才忽然暴露问题——这会侵犯代理商的利益，行不通！服务团队没有人手做服务……
手忙脚乱对大家都不好。
4.3.1 好产品还需市场化
因为公司里有专门的商业团队，所以很多工作PD平时接触得并不多。好在2008年我做的产品没有专门的运营团队，我能够参与销售、服务团队的方案讨论，这给了我接触相应领域的机会。正巧2008春节那段时间，看了《产品经理实战手册》【19】，它主要讲的是产品经理偏市场方面的工作，就几个印象较深的话题分享一下自己的体会。
包装：我们去超市、商场，买任何商品，都习惯于有个包装，不但给产品做宣传，还有保护产品、便于存储等诸多作用。传统软件，一般也都有一个光盘与盒子，只是到了这几年，很多互联网产品似乎没有了包装。不过我们可以这么理解，对互联网产品来说，包装就是产品的Portal、登录页面等，这些页面是产品给用户的第一感觉，重要性不言而喻。
定价：有很多种理论方法，比如成本导向、需求导向、竞争导向等，不过真实场景下没那么刻板，至少我经历过的几次产品定价，都是大家开会讨论出来的，似乎并没有刻意地使用某种理论。
促销：“广告”和“公关”【20】，似乎都可算为促销策略的一部分，这类活动是大量覆盖的面上攻击，杀伤力持久，好比空军的轰炸。
销售：好比地面部队，更精准的点对点的攻击，立竿见影。阿里巴巴的销售是业内出名的，人员所占比例高，单兵能力强，所以才会有很多人说阿里其实不是一家互联网公司，而是传统行业。
渠道：产品销售的方式，产品采用何种渠道，取决于性价比的综合考虑，比如我身边的多种产品，就有电话直销、上门直销、网上直销、线下渠道加盟等多种模式。
我觉得这本书的一个主要思想就是，好的产品需要市场化，不然就成了实验室里的样品，公司不能总是搞科研，必须得赚钱才能可持续发展。产品市场化要做的事情很多也很细，比如做一次公开的市场推广活动，就牵涉到市场预算的及时到位、宣传资料的准备、事前事后的PR轰炸等，确实需要经验丰富的“老鸟”来做。对于我这个成长中的产品经理，虽然现阶段接触的还不多，不过一定需要抱着一颗好奇心去尽量了解，下面就和大家聊聊相关话题。
定价与促销
回顾一下2007年，网店版的定价与促销策略。在那会儿我们真的是创业团队，由几个经验不太丰富的人讨论出来方案，并最终实施。我一直在想，如果有个经验丰富的人全程参与，网店版应该可以卖得更好，有更多的付费用户和收入。
当时，商业层面绝大部分工作是产品团队的同学在做。一是因为产品唯一的销售模式是在线直销，所以没有销售人员；二是因为产品要顾忌“淘宝继续免费3年”的口号，免得引起公众误会和对手攻击，所以市场和PR工作也都完全静默。
先说定价，网店版的SaaS【21】模式决定了我们与很多传统的竞争对手不同。他们大多数是客户端软件，所以多采取买断的模式。而我们则采用了租用模式，这点似乎从一开始就没有异议，因为我们卖的确实是一种服务，像水电煤，服务不停当然收钱不止。
具体的租金，开始考虑得最复杂：按模块、资源收费，用户完全自主选择自己需要的模块，有的模块里面有资源数的概念，可以额外购买；并且整体打包成“企业版”、“进阶版”、“普及版”三个预设包装；配合特定的细分用户群，我们再打出特色版本“某些模块+资源数”的组合，如“进销存版”；配合前期促销，我们再打包出“试用版”。最终感觉这样太复杂，一方面用户的理解难度增大，另一方面我们的工作量增大，在多轮讨论之后，砍掉了资源概念，砍掉N多版本，只推出一个付费的进阶版，包月租金30元，口号：“一天一块钱，帮你管网店”。另外将部分模块屏蔽，推出了一个免费的普及版。
最后我们发现，当自己对某个领域不熟悉的时候，做起事来总会把问题想象得很复杂，把自己知道的所有知识都用上，而真正的高手，是可以一下子就找出问题的关键，然后用最最简单的办法就搞定。
再说促销，产品上线以后，一开始就要用户直接掏钱显然是不太现实的，所以我们给所有符合一定条件的活跃用户都免费“试用”了一个月的收费产品。再后来，我们还采取了其他方法：先是直接降价，短期的买一送二，买一送一；之后，感觉不好意思直降了，就变相降价，过年过节送红包，或者强行想出个理由来送红包；还有，与其他付费产品打包销售，如与淘宝商城、付费推广、消费者保障计划等结合，再与淘宝分成。所以在2007年，我们基本上是以10元每月的底线销售的，因为那一年的主要目标是“付费用户数”而不是“收入”。有一段时间，老板甚至给出了5元每月的底线，但我们挺住了没降下去。
2008年开始，由于公司的战略调整，我也去做其他产品了，不过网店版在几乎没有追加投入的情况下，收入突破每月百万人民币，应该说是个不错的成绩。
销售与渠道
到了2008年，“e网打进”销售火爆，出于工作需要，我浏览了一些渠道相关的书籍，说说相关的体会。
先来点基础知识，销售有两大模式：直销VS.分销。分销要通过渠道，渠道又分代理和经销。他们的区别是“代理”赚佣金，没有产品所有权和库存风险；“经销”赚差价，产品所有权发生转移，比如批发商。
现在网络上的付费产品，生产商和消费者之间有了互联网的连接，更容易直接接触，加之网络支付等服务的成熟，所以网络个人应用，大多数都采取了直销。而我们的“e网打进”是面向企业用户的，而国内中小企业现在相应的知识和意识还略显落后，所以我们选择了渠道销售。
在渠道战术的推拉方面，所谓“推”是集中力量做渠道工作，用高额利润去刺激渠道主动推销产品，快速抢占市场；而“拉”是通过PR、广告、传播等手段启动市场，刺激消费者，促使渠道来找厂商。推适合企业规模小、技术含量高、销售过程复杂的产品，一般来说：新产品推，老产品拉。“e网打进”用的显然是推的方法，其驱动路线是“厂商→渠道→终端用户”。
对销售和渠道的话题，我作为外行不再多言，回到产品设计的角度说几句。第一，通过渠道销售的产品，新增功能和改动功能的时候，还需要额外考虑公司内渠道管理人员的培训成本、渠道商的培训成本，要他们把一个功能说明白很不容易。第二，既然选择通过渠道来销售，就说明终端用户对互联网的应用能力不足，所以相应的设计思路也要转变。第三，在渠道终端的用户一般是企业，企业用户与个人用户的差异也不得不考虑。比如支付，企业用户就会有开发票的问题，不能只简单地考虑网上支付途径。第四，由于渠道的介入，多级的定价，分成比例，开发票的流程，渠道政策都要有相应的系统支撑。
最后，爱好用户体验的人对销售渠道又会提出一个问题：社会发展导致对效率的优化——分工，也是出于成本考虑，我们的产品采用渠道销售——一种非核心业务外包的形式。我们的终端客户是不会了解中间细节的，他们会把外包服务的不爽怪罪到产品上，给产品的体验减分，那么最终一个很大的似乎也只能折中解决的问题，就是：如何保证渠道的服务质量进而控制合作公司来保障产品的整体体验？
留给我们长期思考。
另一种产品版本细分策略
2009年春，我在网上闲逛的时候看到一张图，如图4-21所示，然后很自然地想到了一个经典的销售策略，图中的产品，压根就没打算卖“标准版”，甚至让你觉得，买、卖的人是傻子……
图4-21 网易企业邮局的版本细分策略
再来个经典的例子，大家可以用关键词搜“报告，电子版，纸介版，价格”，随便贴几个例子，你发现了什么？
《2009-2012年火力发电行业深度评估及市场调查研究发展分析报告》：纸介版7200元、EMAIL电子版7800元、两个版本8000元。
《2008年中国羊剪绒市场行情分析报告》：纸介版7900元、电子版8500、纸介版+电子版9000元。
想一下，买最便宜的纸介版是不是很难受？买电子版吧，随便打印一下也就有纸介版了。而双版的价格远远低于前两种版本的价格之和，考虑到产品特性，对于绝大多数不是花自己钱的购买决策者来说，是不是诱惑也很大？每份报告的定价一定是这三种同时摆出来给你看的，不管少了哪一种，味道好像都不对了。
回归正题，我觉得产品的版本细分有两类。
一种是做功能区分，打细分市场，这个同学们都比较熟悉，比如笔记本的高中低端产品、手机的各种型号，不用多说。
另一种是为了促进销售，利用消费者心理，纯策略性地做出“炮灰版”，完全是和你玩虚的，常有手法如下。
第一，有的在原有版本的基础上，添加一些鸡肋功能做一个价格高出很多的“高价炮灰”，让消费者觉得商家真正想卖的那个版本特别实惠。一个特殊的例子就是在“抢市场而非赚钱”的商业目标指引下，主推免费版的同时还放出一个其实并不想卖的付费版本，以保持免费版的价值感【22】。另有一种类似的策略属于技术性炫耀，比如汽车厂商的概念车、显卡厂商不成熟的发烧版本，他们可以让产品用户心理满足以提高忠诚度。
第二，删掉核心功能做一个价格稍低的“低价炮灰”，反正就是要让用户觉得他要是买那个便宜的版本就是脑残，而商家推出这个便宜的版本更是脑袋被门挤了，从而满心欢喜的、好似占了多大便宜似的赶紧买下那个价格稍高的、商家真正想卖的产品。例子很多，如本文开始的那个图，又如行业报告的纸介版，再如星巴克的“中杯”、“大杯”、“超大杯”。
这些策略其实是和用户玩了一个心理游戏，在理论上属于社会心理学的范畴。一方面，购物前获取商品的所有相关信息是根本做不到的；另一方面，很多人购物时不会对功能、价格做理性分析，在乎的是“相对实惠”、“感觉划算”。那么为其营造一个可选择局部相对最优的购买环境，树立一个性价比不高的炮灰版本让用户“抛弃”，使其产生“比较”后、通过智力活动“自由选择”的快感，大家开心，何乐而不为？
有一点一定要注意，做“炮灰版本”的成本要足够低，这个策略才是靠谱的。回顾一下上面几个例子，都是这样，而这样的产品往往都是“虚拟”的，所以互联网、软件行业会特别适用，反之如手机就比较难用“炮灰版”的策略。
自己的一些产品，经常在考虑是不是搞出一些炮灰来促进销售，而这些思路，我是跟传统行业学的。一直觉得做互联网、软件的同学应该好好地去了解传统行业，传统行业已经上百年，而互联网总共才十多年，所以传统行业有很多非常成熟的套路值得我们学习。现今的各种创新，已经很难有突破性的了，往往是整合性的，所谓创新，最怕的就是因为自己知道得太少，自以为想出的办法是个创新，其实这早就是别人玩剩下的，说不定还是被玩烂的几种方法中比较拙劣的一个。避免这种悲剧的办法只能是自己不断学习和借助群体智慧，所以行业、产业交叉是很好的突破口，推荐大家有空看看《美第奇效应》【23】，说的就是这个道理。
最后给个与本文内容有关的小故事，看看前辈们是怎么理解类似现象的。
麻省理工学院的斯隆管理学院曾经让100个学生对订阅《经济学人》杂志的方式进行选择。第一种：花费59美元在网上订阅，好像不算贵；第二种：买125美元的印刷版，价格有点高，但还算可以；第三种：印刷版加电子版套餐同样价格125美元。结果是：单订电子版59美元的有16人；单订印刷版125美元的有0人；印刷版加电子版套餐125美元的有84人。
在这个实验中，你可能不知道59美元的单订电子版是否优于125美元的单订印刷版，但你肯定知道125美元的印刷加电子版套餐要优于125美元的单订印刷版。事实上，你可以准确无误地从合订套餐中推算出：电子版是免费的呀！我是否可以听到那些营销人员在耳边这样喊着？我不得不承认，如果当时决定订阅的话，我本人十有八九会选择套餐。
斯隆管理学院的学生可都是些精明透顶的家伙，他们全都看得出印刷版加电子版套餐相对于单订印刷版的优势。第一种阅读选择：花费59美元在网上订阅，我们把它称作“竞争者”；第二种阅读选择：买125美元的印刷版，我们把它称作“诱饵”；第三种阅读选择：印刷版加电子版套餐同样价格125美元，我们把它称作“目标”。三种阅读方式的设置，就是为了让更多的人选择“目标”，这才是杂志社的营销目的。
开阔视野的水平营销
此节的最后，和同学们一起开阔一下思路。市场营销大师科特勒的《水平营销》【24】是很好的一本书。这本书给我最励志的心得：纵向营销是Evolution（进化，特点是渐变），水平营销是Revolution（革命，特点是突变）。大家也一定都渴望突破性的革命而不是慢慢地进化吧。
水平营销其实是一种创新思维的方法，具体的理论大家可以去看书，但有个例子特别想与同学们分享，专门摘录了Mars同学的博客【25】里写过的“卖包子”的一些有趣创意让大家初步领略水平营销的魅力。
假如我要卖包子，垂直营销的话我就得越来越细分市场，包子做成大号、中号、小号，另外做32种不同的馅，做到累死。假如要水平营销，我可以按照书中说的几个维度、几种手法来激发自己的创意。
首先想市场层面。
需求维度：吃包子的同学们需求是什么呢？填肚子。
替换：好吧……不填肚子了，吃我的“中药包子”可以治病，吃“美容包子”可以养颜，另外，再开发“精品包子”，开发包子作为“礼品”的需求，今年过节不收礼，收礼就收大包子。
结合：除了填肚子，或许还可以满足“表达”的需求，比如画红心什么的，假如喜欢上某人又不好意思，可以帮她或他买早点，早点上面有个红心可以让她/他自己去领会……
反转：本来吃包子是为了填肚子，吃我的包子可以有助于消化，让肚子空空。本来是我卖你包子，我把它倒过来变成做包子教学，你来我铺子，我提供素材教你做包子，做好了你可以送你男朋友……给我家教的钱。
目标维度：本来的目标应该是中国人。
替换：想办法卖给外国人，搞些大红灯笼、竹叶什么的做背景，把包子渲染成“神秘的东方膳食”主攻外国人市场；本来目标是人，也可以转向宠物市场，狗狗常常想吃人吃的东西，但是主人又不放心给他们吃，可以制作专门给它们吃的包子给那些想让狗狗尝鲜的人买，配方可以针对狗狗调整，既保证安全，又能符合狗狗的口味。
地点与情境维度。
替换：一般都是在“吃”的情境里面。但是像什么“抢包山”之类活动，包子就出现在了竞技运动的情境里面。如果通过有效的市场沟通，打开新的情境，就能扩大市场。比如宣传说中国传统里面，小孩生日大家都要吃包子，小孩就能白白胖胖……或者拿牛郎织女做宣传，说每年见面一次鹊桥要走很远，所以每人都带了包子在路上吃，象征着坚贞不渝的爱情。或者宣传说“爱她就带她吃哈根达斯”是说给小情人听的，“真的能做老婆的人，就是和你一起吃包子，一边幸福地看着你的人”，让包子成为“稳定感情”的代表，表达小情侣之间稳定下来的意愿。如果他们搞定了，婚后对于“包子”的感情也会不一样，应该也会吃得频繁一点。
时间维度。
替换：一般人早上吃包子，可以开发一种包子，专门针对夜宵市场，说里面放了××中药，可以让你吃完睡得更香。
体验维度。
结合：把包子和“文化”结合。包子一般是随便吃吃的，说不定可以打造一个高档的“皇城包子”，做成中高档的饭店，供应各种包子和相应的饮食。旁边弹弹古筝什么的，搞得好像吃包子很有文化的样子……
然后是产品层面。
有形的产品或服务。
替换：把包子里面的肉换成水果沙拉；把包子皮换成豆皮。
结合：加一根吸管，用吸的，很多人已经这么做了。
夸张：每个一斤重，内含蔬菜和肉，管饱；每个只有旺仔小馒头大小，当零食吃。
品牌特征。
替换：一般是中式的包子，想办法找到外国人做包子的方式，改良一下再重新引进到中国，这个概念说不定可以吸引人尝鲜，如果好的话说不定就会成为忠实客户。就好像“港式西餐”，虽然不正宗，但是很多中国人喜欢。另外，挂着“西式包子”的概念，创新起来就更没有传统包袱。
换序：一般吃包子都是为了填饱肚子，对于品牌来说最重要的特征是“好吃”。可以宣传“健康”概念，说自己的包子馅经过严格测试，营养均衡，少油少味精，吃了不会胖，突出“健康”特点。
使用或购买。
替换：每天买包子很麻烦，在便利店可能还要排队，所以可以改“购买”方式，从每天付钱买，改成月付。一次性在便利店买30个筹码，每天去便利店拿几个包子就往旁边箱子里丢几个筹码，这样店员也方便（同时还可以服务别的客人），你也方便。
倒序：平时都是别人先包好包子，你再来买。可以推出一种服务，你先打电话或者在线订包子，可以指定要多少、多大、什么馅、馅要多少，过两个小时再去最近的便利店拿。
……
卖个包子都可以有这么多的创意，我们看到，营销也不一定要一个劲地让产品在红海【26】中搏杀，而是可以通过这些点子帮助产品在愈加同质和超竞争的市场中找到自己的蓝海。
4.3.2 我们还能做什么
商业感觉，只能随着工作经历的丰富不断提升，而不是通过上几年学、看几本书就可以学到的。所以，随着阅历的增加，对于商业团队的事情，我们可以做的也越来越多。
对市场销售，我们可以分析数据，给他们的决策提供支持；我们可以提供总结好的核心功能与卖点，而不是给出功能列表让销售自己想；我们可以参与销售策略的制定；我们可以为产品上市的新闻发布会出谋划策……我们还能帮市场销售团队做什么？且看“老板，要光盘吗”。
和服务有关的事情，除了在产品正常运行的日子里做好技术支持一类的工作，一起更新产品的帮助，我们还能参与服务策略的制定。且看“算出来的服务策略”。
“老板，要光盘吗”
小明：标题让我想到了城市天桥上买光盘的小贩……
2008年开始，我们在卖“e网打进”。用户买到的是什么？拿用户的话说，花几千块买了两串数字——一个叫账号，一个叫密码。中小企业付钱的老板晕了，渠道商晕了，销售晕了，最后我们终于也晕了。到头来大家发现，做企业级产品不能像个人网络应用这么玩，太时尚了，我们还是要结合传统，搞点实在的东西。
于是有了如图4-22所示的光盘和包装，无中生有地给一款基于网页的软件搞出一些实体化的东西，这就是包装，事后证明靠谱。我发起和参与了整个过程，这期间做的事情很多都不是典型互联网、软件行业的产品经理的工作了，通过光盘与包装的制作，学到了很多传统实物产品的设计思路，待我慢慢回忆。
图4-22 “e网打进”的光盘与包装
2008年4季度，“e网打进”的活跃度提前达到预设的目标，老板提出了更高的要求，于是我的小组接到任务，只有一句话——提高产品用户的活跃度！于是围绕“活跃度”，兵分两路做了如下事情。
治标的运营活动：奔着数字指标，直接对“1个月登录4天以上为活跃”下药，将用户按登录频率切分群体，启动“小福星”运营项目，尝试将“1个月登录1至3次”的用户往4次转化。运营2周后，发现效果不理想。我们继续分析数据，发现减少“1个月登录4至8次”用户的流失率，提升空间也不大，于是这条线暂停。
但这个过程产生了一些有价值的副产品。一方面，发现很多用户通过线上运营无效，因为他们根本就不是“真正用过产品的用户”。于是联合销售部门、服务部门一起做了用户监控系统，来检测虚假用户、对问题用户报警。另一方面，进一步对活跃度的KPI提出自己的观点，确定在“活跃用户与付费用户之间，应该添加使用用户的概念”，并且定量地证明了老板给出的新KPI数字在当时的状况下是没法达到的，后来这个数字也就不了了之了。插一句，对于如何把“老板你不靠谱”这个想法向上传达，虽然需要技巧，但是在我看来，最重要的还是要有个通情达理的好老板。
治本的用户研究：我先分析了用户最近几个月的登录日志，试图寻找阻碍活跃度进一步提升的问题；通过电话访谈、实地访谈，了解引起问题的原因，分析总结后归为从主到次的4类。
原因1：渠道商失责或造假，用户没用过产品。
解决方案：继续分析数据提供支撑，营销、产品、服务部门共同制定明年的渠道政策。渠道建设考虑混合模式，即“经销+代理”。参与策划三大计划：营销辅助计划，我们大力推广品牌，帮助经销商造势；服务培训计划，提升经销商服务能力；销售培训计划，提升经销商销售人员的能力。
原因2：产品太虚，记不住账号、网址，用不起来。
解决方案：发起“鸡毛信”项目，产品实体化，也就是做了产品包装，下面会详细讲述。
原因3：产品没人用，用的人不对。
解决方案：发起“天使计划”，做了服务外包的试验，我们找人来帮用户使用软件，直接把通过软件获得的潜在生意机会输出给用户。
原因4：网站流量低，产品难以发挥作用。
解决方案：长期思考，除了产品转型以外，暂时还没找到突破。
其他动作不展开，其中原因2的最终产物就是图4-22中的光盘及其包装，整个过程稍微展开如下。
明确目的：主要解决“用户记不住账号、产品网址”的问题，顺带着有辅助销售、辅助产品初始化的作用。
说服老板，申请预算和资源：把问题和解决方案做成PPT，说服老板。我把需要做的东西分解为“光盘内容、盘面、光盘包装”，便于后续多人协作。申请预算，实物的表现形式会影响预算，特别是包装的形式，我们最终还是选择了一个相当省钱的方案。
联系供应商：联系包装供应商、看已有样品，依照想展现给用户的内容，选择光盘包装的大小、版式、材质。联系光盘供应商，这个过程中了解到光盘也有很多种形状，比如大盘、小盘、名片盘，各有优劣与特色。
具体设计：盘内内容的设计，盘面设计，包装的每页上都放哪些内容。这些都是基于产品目的、对用户的了解，以及各种限制下的选择，太细节的思路，不再详述。可以举个小例子：我们在光盘里设计了一个很土的“安装软件”过程，可是对于在网页上使用的软件有什么要安装的呢？其实我们的安装过程就是在用户的桌面添加了一个到产品登录页面的快捷方式，事实证明很有用。
“e网打进”这个产品一直没找准方向，留一个共性问题我们一起思考。对于产品部门来说，一定是先确定目标用户再设计产品。而对市场销售等商业部门来说，现实中往往是先拿到产品，再去考虑去主打哪些市场与用户，他们并不管产品部门原先定义的目标用户是怎样的，而是去寻找最容易的突破口。所以，产品与市场两边的配合很重要，需要互相调整来彼此适应，这样的轮回并不是一个闭环，而是螺旋上升。有的时候一个产品已经做出来了，原先设想的目标用户并不买单，我们也别急着去找哪些功能设计错了，怎么改产品，而不妨先换个角度想，产品与市场不匹配，除了改产品，也可以改市场嘛，有可能这个产品对另一部分市场和用户正合适，真的是“歪打正着”。
算出来的服务策略
服务部门是为昨天的利润工作，给已经购买产品的客户提供承诺的价值；销售部门是为今天的利润工作，把产品变成利润，争取更多的客户；开发部门是为明天的利润工作，确保明天我们有优秀的产品可以卖；研究部门是为后天的利润工作，了解趋势、发展科技，保证永远处于领先位置。
维护一个老客户的成本大约是开发一个新客户的成本的四分之一。
由此可以看出服务团队的重要性，他们一直在高效地完善产品，所以我们来要帮一下服务团队。如图4-23所示是用户从签单到使用的监控过程部门包括简图。我们公司里参与这个过程的部门包括营销、产品、服务，每个部门在不同的时间点上要做不同的事情。毫不夸张地说，这幅图里的每一个过程有哪些动作，它们之间的先后顺序，动作的时间点，都是通过数据分析算出来的。
图4-23 与商业团队共同制定的用户初始化策略
在图4-23的背后，产品部门的同学做了大量的数据分析工作。最终的结果，举几个例子说明：
在用户签单以后，一周内应该完成初始化动作1、2、3，否则需要督促并惩罚渠道商。
用户签单1个月时，应该有第一通电话回访，主要目的是验证渠道商提供的用户联系方式正确，确保用户的正常使用。
用户签单3个月二次回访，主要目的是拉升活跃度。
用户签单9个月三次回访，主要目的是促进第二年的续签。
第二三次回访，对不同的用户，是用E-mail、电话，还是上门，也都可以依赖于数据分析的结果。
将来系统更强大以后，可以针对每个用户的使用情况，算出应该回访的时间与方式。服务的最高境界就是：用户使用正常的时候，绝不打搅，而当用户需要帮助的时候，电话立刻就响了。
看起来很高科技吧，正好，下面我们就要看到真正高科技的团队了——技术团队。
4.4 技术团队，坚强后盾
这节来谈谈技术团队，他们做的事情很多已经在第3章“项目的坎坷一生”中讲过了，这里主要说说做如图4-24所示中这些事的人。
图4-24 技术团队简图
外行眼中的技术分工
在互联网、软件行业的项目中，需求评审通过后，紧跟着几种技术上的设计：编码设计、数据库设计、测试设计……这时技术人员会全面介入，在各项设计完成并执行以后，再部署发布，下面就谈谈各技术中的技术人员。
编码设计，有软件架构师或系统分析师，具体到编码的执行工作就是最常见的开发工程师，他们也会有分工，有人偏前台应用，有人偏底层数据库，有人专做搜索引擎等。此外，可能会出现专职的开发经理，配合项目经理管理整个开发过程，比如协调人员、制订开发计划等，他自己并不是项目的开发人员，可以同时担任多个项目的开发经理。
数据库设计，对于大用户量的应用特别重要，比如淘宝、支付宝这类服务的用户数实在是太多，所以相应的人员——DBA【27】，在业界也确实是比较强的。
测试设计，相应的人员就是测试工程师，再细分一点有功能测试与性能测试等，一般来说性能测试会写一些自动执行的脚本，感觉更高科技一点。大一点的项目还会有一位测试经理，协调管理测试相关的工作。
突然想起测试同学的一句口头禅：你这样做是不对的……当PD们激情四溢地乱冲乱撞时，有个严酷、冷酷、残酷的测试同学控制着，确实太有必要了——他们因为职业的关系，总给人一种很鲜明的性格印象：理性、冷静、挑剔、完美主义……
不知道为什么，我们经常把测试也叫做QA，原来一直以为QA和测试是一个概念，其实QA是Quality Assurance，质量保证人员，主要做流程管理（如需求变更流程、发布流程），文档管理（如开发规范、测试规范）等。测试和QA常常是归属于同一个部门的。在软件项目的整个过程中，需要在流程和规范上控制以防止低级失误的发生。比如，有时候需求人员会觉得某个功能的改动很小，就直接叫开发人员修改而不告知测试人员，这样违反流程的行为对于复杂的系统是极其危险的。经典的CMM【28】说了很多这方面的事情，有兴趣可以去研究。
对于不断发布的产品、多分支同时开发的产品，软件配置管理员【29】就显得非常重要了。有他们的控制，就不会发生“某个Bug在新代码发布之后重新出现”这样的低级失误。像简单地用SVN来管理代码、软件版本的变更、每日构建等，都是SCM的职责范围。
上述各项工作完成之后，就要把各方面准备好的产出物拼在一起部署发布，那么就牵涉到硬件方面的管理，这就是SA【30】，系统管理员。对于复杂的系统，可能涉及成百上千台服务器，且服务器的任务各自不同，其设计与管理的复杂度并不比软件低。
有这样两种工程师
上面提到的各种人员，都可以看做广义的工程师、技术人员，他们是很有特点的一类人，给外人的印象或许是执著、冷静、沉默、高傲……我在工作中经常遇到的有两类很典型的风格。
一类是技术痴迷者，常见于工作不久的新人，或者少数工作很久且一直醉心于技术的牛人。这类人价值很大，在项目碰到技术难题的时候，往往是攻坚的主力，要把他们这些好钢用在刀刃上。但他们的优点也正是其弱点，技术痴迷者工作的目的似乎就是学习更多、更强、更新的技术，并乐于在项目中尝试“高科技”，他们追求的是解决难题的快感，而对项目本身在商业上成功与否并不关心。他们会为了技术而搞出一些用户并不需要的功能，即所谓的“镀金需求”。这就需要PD与他们充分沟通，让他们具有成本意识，不要盲目创新，这类同学都很理性，比较好交流。
有极少数热衷于技术的人，缺乏必要的责任心和使命感，做项目是为了钻研新技术，钻研新技术是为了更好地跳槽，把项目的成败放到次要地位，甚至在项目的最关键时候提出辞职以此要挟老板涨工资。碰到这类人只好自认倒霉，去找HR【31】哭诉吧。
另一类是实用主义者，常见于工作过一段时间的老人，或者只是把技术当做工具的工程师。他们的典型特点是KPI导向，公司考核他们什么，他们就做好什么，尽量少做事，做简单的事，稳字当头。看似不思进取的态度也有其巨大价值，他们往往经验丰富，在做事之前充分考虑，让每一份付出都有超额回报。他们能在一团乱麻中找出最简单稳妥的解决方案，他们很清楚自己需要什么、公司需要什么、你需要什么，有一定的商业感觉，可算是职场中人见人爱的“老狐狸”。
这种人中也有极少数让人头疼的，他们是真的不思进取，做一天和尚撞一天钟，每天只给你交一份刚好60分的作业，这就要看你的公司是否有办法把他的激情再调动起来了，好在我几乎没有碰到过这样的工程师。
如何与工程师合作
2007年秋，在公司内部的一次交流会上，聊到PD如何与工程师合作的话题，大家很有共鸣，所以我也利用一次团队分享的机会收集了开发、测试、PD等同学对合作沟通的期望，整理出来和同学们分享。
第一，综合大家的需求，大家最看重的居然是一个很大的话题：“流程”，但仔细想想就一点都不奇怪了，一群超级理性的人很明白“没有规矩，不成方圆”的道理，他们喜欢被规则管理而不是被人管理，当事情由人来控制的时候，总给人一种不安全、不稳定的感觉，而有流程可依的时候，心里就比较踏实。
具体到实施方面，大家再次达成共识，需求确认的时候相关人员一定要悉数参加，以免后期才发现大家对需求理解的不一致。如时间允许，每个人都应该尽早参与到需求评审中。
另外提到非常多的一点就是需求变更的流程，说明大家对“需求总是在变”这件事情已经是深恶痛绝并且有些恐惧了，但同时又意识到需求的本性就是“总在变”，所以非常希望有一个流程化的规定来严格控制这件“恐怖”的事情。
但好的流程是需要执行的，不过感觉在实施的时候还是有些困难，产品现有的发布流程不能说完善，但很简单实用，如果能严格执行，相信已经可以减少很多问题了。
第二大的问题就是“沟通”，这是团队合作必不可少的一个环节。站在PD的立场上，我们会把自己作为产品的中心，这个角色注定要和各种各样的人交流，客户、老板，以及开发、运营、测试、客服、合作等部门的同事。
开发者们提出了很有意思的一点，希望大家在交流的过程中避免情绪化。人性的弱点决定了在争论的过程中每个人都希望自己得到认同，而这点往往导致思路的变形，不再考虑产品怎么做更好，而是去想如何说服对方，并且，经常有同学会把对人的反感转移到对此人观点的反对上，这很可怕。我自己觉得沟通中还有一点很重要，就是每个人都要主动一点，这样才能形成互动的氛围，也可以减少信息不畅引起的问题。
第三点是PD要不断提高自我修养，大家希望PD给出的文档在质量上更进一步，准确、全面、简洁，即时更新、保持最新。我自己觉得PD有空多了解一点技术也会大大改进与工程师沟通的效果。对于有的工程师你可以和他讲商业价值，而另外一些，你与他讨论一些技术实现更有效，当然不是技术细节。
最后，顺便提一下与工程师差异极大的业务人员，我与他们的沟通、合作似乎总很顺利。虽然他们总是个个能说会道，但其思维的逻辑性、严密性不如工程师，可能突然因为想到某个主意就很激动，马上就想去实施，这时候需要我们来协助，把事情想周全，凡事有得必有失。PD们在商业与技术之间，起到了平滑过渡的作用。有了我们，可以让业务人员冷静下来，让技术人员兴奋起来。这样，团队就更和谐了。
4.5 容易被遗忘的角落
产品、商业、技术，好像说完了？没有！我们忘了最关键的——公司高层、老板。
高层一般会在产品和项目的早期积极参与、影响决策，之后就闪人了。他们一般超级忙，所以会忘了我们，但我们不能忘了他们。他们不但是资源的提供者，而且是背黑锅的人，在做产品的过程中，我们总会碰到“顶不住”的时候，这时候你问我该怎么办，我想说：“顶不住”了先尽力顶，“真的顶不住”了就向老板喊救命。
容易被遗忘的还有默默奉献着的法务、财务、行政等，他们和老板们一起构成了产品的支撑团队，如图4-25所示。
图4-25 支撑团队简图
各种分工的产生都是因为做事的人越来越多，需要专人专岗以便提高效率，那么如果公司再大的话，还会出现什么职位呢？比如商业智能部门（Business Intelligence，简称BI），他们承担起数据分析、数据挖掘、给商业决策提供建议等责任。在这个团队逐步扩大之后，甚至会出现专门负责情报收集、竞品分析的职位。他们属于支撑团队、技术团队，还是商业团队？不好说，也不重要，了解了本章后，碰到再庞大的团队，再复杂的职位设置，也可以慢慢理出个头绪。
最好的资源：老板
刚从学生变成一个职场人士时，总会保留一些习惯，比如把老板当做老师，总是心存敬畏。几年下来，我的体会是，不要怕老板，或者仇视老板，而是要把老板当做最好的资源，“利用”他们促成自己不断成长，下面是一个菜鸟成长的故事。
最初，菜鸟什么都不懂，蒙着头做事，眼巴巴地盼着老板光临，好汇报一下工作。而往往当老板主动找你问事情的时候就是他开始担心的时候。这时期的菜鸟很容易把事情做偏，吃力不讨好。
渐渐地，菜鸟觉得这样太辛苦了，于是每走一步就问老板，“我碰到一个问题，应该怎么做”，这叫让老板做问答题。老板每每给出答案，菜鸟再也不会做无用功了，做起事来也踏实多了。但是老板心里嘀咕起来，太烦了，终于在某次菜鸟又来问问题的时候，冲了他一句：这些问题你怎么自己不先想想，你什么信息都不给我，我怎么告诉你答案……
菜鸟继续体会，发现让老板做问答题，老板是很累的，需要让老板做选择题。于是，每次有问题的时候，他都会自己先收集很多的背景资料，然后选出几种可行的解决方案，再拿着所有的这些资料给老板做决定。现在好多了，老板开始有点轻松了。并且在这个过程中，菜鸟发现有些问题在自己寻找解决方案的过程中，已经被自己解决了，大喜。
又是很久过去了，突然有一天，菜鸟发现一件有意思的事情：那就是还可以更进一步，让老板做判断题。于是菜鸟在每次呈现给老板几条解决方案以后，又会加上自己的选择：我觉得A方案是最好的，因为什么什么……当然，菜鸟毕竟是菜鸟，因为各种原因，经常与老板的判断不同，但菜鸟在疑惑中又学会和老板讨论，渐渐地学到了一些老板的判断方法。
白驹过隙，慢慢地老板发现，自己做的判断题答案都是“勾”了，似乎每次菜鸟的汇报自己就是听听，嗯嗯两声就没什么事情了，但是菜鸟仍然在及时地问，不停地汇报，也越来越学会跟老板开条件，要资源，当然目的是为了把事情做得更好，这就是：事情我做，黑锅你背，各司其职。这是职业的思维，老板“嗯”了一声，就意味着这事情菜鸟做起来是经过授权的，出了问题是要老板承担责任的。对于菜鸟来说，稚嫩的肩膀经受不起，所以要找人帮忙，是出于对自己的保护。
再往后，事情如果向好的方向发展，那就是老板不用再帮你背了，你完全可以自己决策了，爽吗？其实，只是新的轮回，可以自己背黑锅以后，必然碰到更大的黑锅，还是要让老板背，也许是更大的老板，只不过在这个过程中，自己的肩膀得到了锻炼。
默默奉献着的团队
辛辛苦苦把产品做出来，可能会因为某项与短信相关的业务违反了行业规定而无法上线，可能会因为在线支付的方式没法给用户开发票而导致大面积投诉，那真是崩溃。可悲的是，这些都是我真实碰到过的问题。
在这些问题的预防和解决过程中，有一些团队在默默奉献着，而且他们至关重要。
“任何一项新业务在法务眼里都是‘违法犯罪’！”这是我们开玩笑的说法。
法务团队，会在做产品的过程中搞定一切与政策法规相关的问题，比如产品的使用协议应该怎么写？付费协议又怎么写？哪些输入的内容是敏感词等。我们公司的法务团队还承担了知识产权的工作，他们会帮助各款产品申请软件著作权、商标、专利等，比如“e网打进”在2008年、2009年就有超过20个专利进入公示期，把产品结结实实地保护了起来。
“几千、几万块，都是先收进来再说；十几、几十块，居然要对方先开发票！”这是我们对财务的调侃。
财务团队，会特别照顾我们的付费产品。有些产品还有第三方的经销商参与，所以钱在用户、经销商、厂商之间如何流转，预付款与尾款怎样分开处理，发票如何开，如果发生退款应该怎么处理等，在产品设计的过程中都需要听取他们的专业意见。
行政与IT，这是真正的后勤团队，我们各种办公资源的正常运转都仰仗他们。大到公司的办公环境、出差的酒店机票预定、名片制作、快餐盒饭，小到每一次开会，会议室、投影仪、网络、白板、马克笔的准备，都有他们的默默付出。
衷心感谢他们。
4.6 大家好才是真的好
上面把和团队有关的人、事、物都梳理了一遍。我们的产品靠的是大家的共同努力，而大家努力做事的基础是做得开心。随着产品的发展，团队也要有相应的发展，组织才能持续前进。听过太多的人说，公司最大的财富就是人、是团队，只要人在、团队在，哪怕现在的产品没有了，也能重新杀出一条血路。
所以，不能只是谈产品好，为了达到“大家好才是真的好”这个目标，我们再聊聊“团队文化”和“无授权领导”这两个话题。
4.6.1 所谓团队文化
很多人都在讲企业文化、团队氛围，阿里在这个问题上备受争议，外界有人觉得这种文化很好，可以让人有激情，有战斗力，也有人觉得是在洗脑，会迷失自我，对此颇为不屑。任何人的观点都只能是管中窥豹，但我知道，如果一个团队里的每个人每天都开开心心，就是很好的。
团队文化的三五事
回想了一下自己所在的团队，工作中似乎一直保持着一种很“不正经”的交流方式，非常重要的邮件也可以用“hi 美女/帅哥”开头；我坐在淘宝办公，会冷不丁走过一个不认识的美女说“亲爱的，那个谁谁去哪儿了？”；开会的时候，经常有人抢着买一些零食、饮料给大家；借不到会议室的时候，发现附近哪个总监、副总裁不在，就会不打招呼地临时征用他的办公室，甚至偷吃他桌上的糖……这段话在我的博客上贴出过，立刻引来了如下回复。
jollyant说：在我们的公司要是这么做，老板要疯掉的～～
燕燕说：我们这也绝对是，现在感觉部门死气沉沉的～～～
可惜我没换过工作，不知道那种死气沉沉的滋味如何，我想大约就是“老板老板着脸，总监总监视人，总裁总裁人，小兵唯唯诺诺地接受任务，应付了事，不敢创新，也不愿创新吧”。下面举几个日常工作中的例子，同学们可以设想一下，这样的风格你受得了吗，你的老板受得了吗？
► 产品的KPI数据日报，太枯燥了，所以搞了个每日副刊，力求每天让大家轻松一下，某个产品的第一期副刊是这样的，前面正经的数据部分略过：
======我是敬业的分割线 以下是每日副刊部分======
1．鸣谢现在与将来的原始数据提供者：徐××、阮××、楼××、李××、朱×……
2．评论员文章：180个付费用户意味着什么？每个“A产品”卖2900元，笔者算了一下，按每天一顿“红草莓”（注：那段时间大家一天吃两次，深恶痛绝的快餐品牌）计，可以供一个人吃179年！而今年的3万用户的目标可以吃到公元第三百一十九世纪！同学们，加油，明天再见！
► 午餐时的赌局：
团队很久一段时间都是在一家小饭店点菜叫外卖解决午餐的，一般11:50就要开始抢包厢（会议室），吃完免不了要收拾残局。之前一直是几个勤劳朴素的人（当然包括我）做，可是后来勤劳的人也受不了了，于是出现了赌局。
赌具：一个杯子＋三个骰子。
玩法：豹子（三个一样的，6>...>1）>顺（456>...>123）>对（对子一样大，比第三个）>单【32】。
结果：每天掷出2个人收拾。
最早是2个最小的收，后来玩着就开始变花样了。
1．每天由前一天收拾的人定规则；
2．规则可能是：2个最大的收、最大和最小的收；
……
管你是经理还是总监，输了就得收拾。
► 某位男同学的“休假知会”邮件：
因地球猪流感严重，受联合国委托，特派大使前往火星交流防流、抗流经验，为期一周（5.28～6.4）。深知肩上责任重大，即日启程，兄弟尤其是，姐妹们勿挂念……
就这些吧，我觉得挺好，不过关键还是老板们的亲力亲为，才能让这种风格真正地流行起来，如图4-26所示。
图4-26 马云的白雪公主与朋克造型
4.6.2 虚无的无授权领导
但凡讲到产品经理的基本要求，总会提到“无授权领导”，就是说在行政职位上，我们并没有下级，但在做产品的过程中，需要领导整个团队朝着目标前进。团队不“为我所有”，真的能“为我所用”吗？我们先从“管理”和“领导”的异同说起。
管理VS.领导
这个命题对于我来说太高深，说实话，无论是管理还是领导，我的资历都太浅，所以只用一系列的对比给出我的理解。
管理更像科学，领导更像艺术；
管理靠的是权力，领导靠的是魅力；
管理者强调稳定，领导者喜欢冒险；
管理者依法治人，领导者以德服人；
管理的对象是行为，领导的对象是思维；
管理管正确的做事，领导管做正确的事；
管理是一步一个脚印，领导是不走寻常路；
管理者注重短期目标，领导者注重长期发展；
管理者是职业经理人，领导者是企业家和创业者；
管理是汽车的制动系统，领导是汽车的驱动系统；
管理是告诉团队怎么做，领导是告诉团队为什么做；
管理对人的影响由外而内，领导给人的力量由内而外；
管理让团队能完成这些事，领导让团队喜欢做这些事；
……
我们需要理解，管理者与领导者并不存在好坏之分，一些人有能力成为出色的管理者，但是不能成为优秀的领导者；另一些人具备巨大的领导潜力，却由于种种原因很难成为优秀的管理者。对于一个人来说，自身也可能同时具备管理能力和领导能力，这两种能力也必须一起提升才能发挥更大的作用。
产品经理应该是管理者吗
从上节的对比里可以看出，产品经理必须是一个好的领导者，而工作职责使得产品经理也要做很多的管理工作，那么，为什么不给我们一个管理职位呢？或者说，本节的标题更准确地说是——产品经理应该拥有管理职位吗？有不少前辈对这个问题进行过讨论，我权且谈谈自己的观点。
先回顾一下第4.1.3节的“我身边的矩阵型组织”里提到的部门经理与产品经理兼任带来的问题，假设我们自己能很好地平衡，那么还会有什么问题？答案一上来就可以定调子。如果产品经理是管理职位，必然既有优势也有劣势，我们不妨从优劣势的对比中寻找现象背后的本质。
优势在于：
管理岗位利于拥有话语权，不知你是否同意，对产品经理最大的激励是成就感。国内很多公司的现状是，没有职权就没有话语权。当产品经理不是管理者的时候，很可能就成了一个实现别人观点的执行者。更悲惨的，作为外行的老板决策，我们执行，出现“外行领导内行”的局面，这样怎么会有成就感？解决之道，我们可以培养“专业的人做专业的事”的价值观，让产品经理在他熟悉的业务领域拥有话语权。
管理岗位利于获取信息，就现实而言，公司里很多重要信息都是自上而下传递，如果能参与管理会议，就可以掌握先机。产品经理需要做很多决策，而决策失误的一个重大原因就是信息不充分，如果不是管理者，就算你的老板能传达，也有时间延迟和信息失真。这个问题，当然也有很多办法解决，比如部分重要信息是通过用户调研、数据分析自下而上传递的，又如让重要的非管理人员参与管理会议的业务讨论。
管理岗位利于争取资源，跨团队沟通是一件很麻烦的事情，如果你是一个有权力的管理者，做事也挺靠谱，那么专制、独裁是最高效的手段。在争取资源的时候，至少有保底的招数——行政命令，特别是对于国情现状，“官本位”的思想多少存在于每个人的潜意识里，君不见很多团队里，其实那个大老板就是一个产品经理。从这点我们可以发现，如果产品经理有临时的资源支配权，也可以解决大部分问题。
劣势在于：
管理岗位有很多行政工作，这些工作会占据产品经理大量的时间。而产品经理的所有工作，最能产生效益的都是与产品直接有关的，无论在产品生命周期的哪个阶段，跨部门沟通、做规划、跟进项目、接触用户、分析数据等都已经忙不过来，如果再来一块“官场”有关的事务，那必定不堪重负。所以，我们应该让产品经理“对事负责”，对业务负责，而其他的一些事务性工作，不妨留给其他管理岗位的同学。
管理岗位会让人脱离群众，一方面是因为自己心态，认为自己高人一等就会有意无意地忽视别人的意见。如果把各种评审会上的正常争论认为是对自己权威的挑战，对产品更是致命的，久而久之大家甚至都不愿意和你讨论。这个问题还好办，我们学学真正的高手就可以了，他们往往都是很谦虚低调的。另一方面就更致命了，官与民之间总是有隔阂，最明显的现象，我待过的团队，一定有一个全团队的旺旺群，也一定有一个全团队除了主管之外所有人的旺旺群。很多时候大家对一个管理者的观点有异议，也没法像对普通同事一样直接提出，总会在心中先掂量几次，很多可以帮助产品提升的机会就在这些掂量中白白溜走。从这点上看，产品经理不在管理岗位上会比较有利于工作。
这样看来，其实产品经理是不是管理者并不重要，重要的是公司应该创造出一个良好的环境，让上述几点优势可以发扬，劣势可以避免，这样产品经理才能发挥出最大的作用。看到这里，你可能想到了解决办法，其实很多公司都想到了：设计管理、专业两条晋升线路，让优秀的产品经理在专业线路上拥有高级别；对于产品、业务的决策有充分的话语权；可以参与管理会议的业务讨论；可以拥有临时的资源支配权，并给管理层提供同事的考核建议；但不负责管理者的行政工作，而是继续和同事打成一片，用产品证明自己。
这，似乎是一条很好的路。
如何让团队更开心
作为产品经理，有时候带项目会有一些项目经费，怎么花真有很大的学问。2009年的时候，我开始对社会心理学产生了浓厚的兴趣，期间看了一本书，叫《别做正常的傻瓜》【33】，它揭示了人们在工作和生活中熟视无睹的决策误区，并教你如何纠正。书中的第9章，题目是“你想让朋友和员工更开心吗——赠送礼物和激励员工的艺术”，给了我很多启发，与大家分享一下。“道”的东西，我很怕自己理解成“术”，希望大家也不要误解如下九条。
大中之小不如小中之大：送礼的时候后，在一个不太昂贵的礼物类别中选择一个比较贵的礼物，要比在一个比较昂贵的礼物类别里选一个比较便宜的礼物收到的效果更好。比如送一条1000块的围巾效果好于送一件1200块的衣服，我们应该尽量找一些高级的小玩意。
有用的不如无用的：最好的礼物应该是吃不掉、用不掉、送不掉也扔不掉的东西。比如有纪念意义的水晶奖杯，刻上他的名字，千万不要是几瓶酒、几条烟，能喝掉、能抽掉、能送掉。
需要的不如想要的：你应该把人们想买却舍不得买或者想买却不好意思买的东西送给别人做礼物或作为奖励。比如5星级酒店1000块一顿的高档餐券，更多的是心理满足感。
有选择不如无选择：奖励或送礼的时候最好不要让接受奖励或礼物的人自己选择。不然的话他会有“我放弃了另外一种选择的感觉，患得患失反而不开心”，经典反例就是：奖励团队“海南游”或每人“现金2000元”。
小奖不如没奖：人们做事往往是出于自己的内在动力，而一旦与奖励挂钩，就变成了一个经济交易，做事的人会开始衡量投入产出的物质性价比，所以给小奖反而不如不给奖。惩罚也是如此，受到小的惩罚后反而会让人感觉心安理得，还不如没有惩罚。
晚说不如早说：在期待的过程中，让员工的快乐最大化，从而增强激励的效果；让朋友在期待的过程中提前享受到礼物所带来的欢愉。比如尽早宣布奖励大家去海南玩，如果可能的话，在项目开始前就给出承诺。
一次送不如两次送：如果你打算给别人两件礼物的话，那么最好分两次给。因为快乐也是边际效用递减的。同样的道理，有很经典的结论：好消息要分两次说，坏消息要一起说，大的好消息与小的坏消息一起说，小的好消息与大的坏消息分开说。
公开不如不公开：工资体系最好还是不公开的好，以避免员工互相比较而心理不平衡，也就不必用涨工资的方式来进行协调了，因此避免了整体工资水平的提高。
涨工资不如发奖金：涨工资不如发奖金给员工带来的快乐大；同时，发奖金有比较大的回旋余地。对于这类物质激励，一般效用期比较短，发奖金是一次性的，涨工资是长期的，涨了就不好降回去，从第二个月开始，激励效果就微乎其微，孰优孰劣一目了然。
要记住，奖励或送礼的目的并不是真正给对方最大的效用，而是要让对方开心，并且感激和记住你。最后，作为产品经理的你，请把本节标题想成“如何让用户更开心”，再看一遍上述的几条，独立思考，批判吸收。
跟着我，有肉吃
终于讲完了我身边的团队，当我对团队有了一些认识之后，就更加强了自己是产品主人的认识。再看一眼本章里提到的各种职责的全图，如图4-27所示，要让这么多人跟着自己走，就必须找准方向，说服了自己，自己先激动了，才能说服大家，让大家激动起来。
图4-27 “我的产品，我的团队”详图
要想“我的产品”好，就要对“我的团队”好。其实也很简单，没事与同学们多聊聊天，成为朋友，多帮团队争取利益，真心地对大家好。最后分享一封“魔方计划”项目发布后不久，我拿项目经费组织的一次团队活动的邮件。
发送时间：2009年4月10日 12:00
主题：魔方计划项目团队活动啦～～～
Hi all，魔方计划项目已经顺利发布，大家期待已久的活动也将于明天进行。
活动安排如下：
1．上午大家可以睡个懒觉，起床后自行前往“清溪余韵”。
a）地址：下茅家埠12号，都景生故居旁，醉白楼附近，公交茅家埠站附近（y3、y6、y2、27都到），大方向在杨公堤以西不远，龙井路上；
b）中午农家饭，下午喝茶、棋牌、聊天……
c）建议大家11点之前到，考虑到必然有人会没吃早饭，所以我们开饭会早些，大约11:30。
（这段是清溪余韵的美景图片与介绍，略过）
2．晚饭去东方威尼斯吃中西海鲜自助。
a）地址：文二路387号，就在文二路万唐路口附近，3F，威尼斯国际V2自助餐厅；
b）赶早，17:30开场，大部队直接从“清溪余韵”杀过去，零星的同学自行前往，到地头汇合。
（这段是东方威尼斯的美食图片与介绍，略过）
热线电话：137****2411（苏杰），大家有问题随时骚扰，☺
在群里的同学都会收到邮件，不能去的就过过眼瘾，找个墙角蹲着画圈圈吧……
当听到大家说“跟着你，有肉吃”的时候，你会比自己吃肉更开心。
注释
【1】这两本书的作者杰弗里·摩尔，被称为高科技营销魔法之父，图书内容是创新管理相关，附录里会做简单介绍。
【2】Geek，中译“极客”或“奇客”，可简单解释为新技术的狂热爱好者。
【3】“微笑曲线”（Smiling Curve）由宏基集团的创办人施振荣先生于1992年提出。曲线的两端朝上，表示在产业链中，附加值更多体现在两端，即研发和营销，处于中间环节的制造附加值最低。
【4】刘未鹏的个人博客，http://mindhacks.cn，他的《暗时间》一书值得细读。
【5】本节提到的两本书的英文原名是The Design of Everyday Things与Emotional Design，附录里也有对它们的简单介绍。
【6】卡洛曼茶壶是一个完全不可以用的茶壶，因为茶壶嘴和茶壶柄在同一边。它是由法国艺术家卡洛曼创造的，卡洛曼称它为咖啡壶：一个“专为受虐狂设计的咖啡壶”。
【7】TC：Test Case，测试用例。
【8】需求分析师：Requirement Analyzer，简称RA。
【9】产品概念图：Concept Map，以下简称概念图。
【10】此图英文直译为“用户模型图”，与概念图类似，都是说用户是如何使用产品、产品如何运作的。原图太大，只能缩略，删除了很多细节。出处为http://soldierant.net/，一位老外的博客。
【11】本书全名是《Web信息架构：设计大型网站》，涵盖了信息架构基本原理和实践应用的方方面面。
【12】用户体验部门有时候也称UED部门，UED即User Experience Design。
【13】网页产品的Portal又称产品主页，通常指访客或用户在网站上登录进入产品页面之前可以看到的页面，一般会有产品介绍、如何购买等信息。
【14】UV：Unique Visitor，指网页的独立访客数。
【15】极限编程：Extreme Programming，简称XP，是由Kent Beck在1996年提出的一种敏捷开发方法。
【16】产品运营师：Product Operation，简称PO。
【17】现实中的KPI往往是这样，我理想中的KPI应该具有更广泛的含义，第5.4节“KPI，KPI，KPI”里有相关描述。
【18】ChinaPM：chinapm.com.cn，中国产品经理联盟，这个网站里有不少传统行业的产品经理潜伏。
【19】这本书是金山的王欣、夏济写的，很实用的操作读物，看起来比较轻松，可以放在手边没事翻几页。
【20】公关：公共关系，Public Relationship，其简称PR可能更有名。
【21】SaaS：Software-as-a-Service的缩写，意思是软件即服务，是基于互联网提供软件服务的软件应用模式。
【22】保持免费价值感的方法还有很多，比如Google Wave的邀请机制，可以算是一种“饥饿营销”。
【23】人们把各个领域和学科的交叉点上出现的创新发明或发现，称为“美第奇效应”。
【24】《水平营销》阐明了相对纵向营销而言的水平营销的框架和理论。引入横向思维来作为发现新的营销创意的又一平台，旨在获得消费者不可能向营销研究人员要求或建议的点子。
【25】Mars的个人博客：http://www.marsopinion.com/，有不少网络营销相关的好文章。
【26】红海代表现今存在的所有产业，也就是我们已知的市场空间；蓝海则代表当今还不存在的产业，这就是未知的市场空间。《蓝海战略》一书中对这个话题有详细的阐述。
【27】DBA：Database Administrator，数据库管理员。
【28】CMM：Capability Maturity Model For Software，软件能力成熟度模型。
【29】配置管理员：SCM，Software Configuration Management。
【30】SA：System Administrator，系统管理员。
【31】HR：Human Resource，指公司里负责人力资源的同事。
【32】如果最大的单一样大，那么比第二大的单。更多规则细节，本书就不跑题去解释了。
【33】此类思维训练的书籍值得一读，附录里会推荐几本。
