第4章 我的产品，我的团队

4.1　大产品，大设计，大团队

4.1.1　产品之大

时间之大：产品生命周期

空间之大：商业、产品、技术

4.1.2　设计之大

产品设计的五个层次

我用五个层次来写书

设计的“现实与浪漫”

4.1.3　团队之大

想当年，一个比一个猛

从几个人到一家公司

接口人存在的价值

我身边的矩阵型组织

4.2　游走于商业与技术之间

4.2.1　心思缜密的规划师

从概念设计到信息架构

PD的出身及其优劣势

4.2.2　激情四射的设计师

产品新首页诞生记

当交互设计遇到敏捷开发

信息展现设计的例子

聊聊细节，文案设计

4.2.3　“阴险狡诈”的运营师

产品与运营的战与和

个人博客运营实例

一次无意识的“事件+病毒营销”

4.3　商业团队，冲锋陷阵

4.3.1　好产品还需市场化

定价与促销

销售与渠道

另一种产品版本细分策略

开阔视野的水平营销

4.3.2　我们还能做什么

“老板，要光盘吗”

算出来的服务策略

4.4　技术团队，坚强后盾

外行眼中的技术分工

有这样两种工程师

如何与工程师合作

4.5　容易被遗忘的角落

最好的资源：老板

默默奉献着的团队

4.6　大家好才是真的好

4.6.1　所谓团队文化

团队文化的三五事

4.6.2　虚无的无授权领导

管理VS.领导

产品经理应该是管理者吗

如何让团队更开心

跟着我，有肉吃

4.1 大产品，大设计，大团队

1. 下面我们会站在一个比较高的位置，一看“产品之大”，了解一下“产品生命周期”与“商业、产品、技术”的铁三角；二看“设计之大”，从多个角度看看不同层次的设计；三看“团队之大”，辨析“职位与职责”的区别，体会“从几个人到一家公司”的过程。

4.1.1 产品之大

2. 产品之大，我想可以从时间和空间两个角度来说。 时间是指产品的生命周期，我们在之前两章中讲到做需求、做项目，忙了半天产品的1.0版本上线之后，其实才走完了生命周期的一小步，产品刚刚呱呱坠地，后面还有产品的青年、壮年、老年，每个阶段都有不同的挑战等待着我们。 空间是指做产品需要考虑的三个大方面：商业、产品、技术。任何一个产品，扩大至公司，都是由这三方面组成的，三方面有一点做到极致就很不容易，再配合上不是很弱的另外两方面，可能就是一个成功的产品和公司。

时间之大： 产品生命周期

3. 我觉得产品与对应的市场、用户好像都是有生命的，他们都会从幼小发展到成熟，最终老去，不同时期的产品与市场、用户都有其特点，最佳状态就是彼此之间完美的配合。结合自己做过的产品，从五种用户群体的角度，说说其间的过程与体会。这五种用户群体如图4-2所示。

4. 创新者（Innovators）：新鲜感强，消费能力强，但是忠诚度不高，需要新鲜的东西不断刺激。这批人都有Geek【2】气质，乐于探索。产品刚上市，甚至未上市的时候，主流用户往往是创新者。 他们的特点与产品设计人员比较像，很容易打成一片，比如建立共同的IM群，经常交流，创新者经常给产品提出很好的意见和建议。所以设计此阶段的产品会让我们比较兴奋，似乎创意总像地里的野草，割都割不完。不过，虽然我们可以利用创新者帮助产品尽快成长，但由于创新者总是极少数，所以商业利益无法保证。更何况创新者“喜新厌旧”，往往比产品开发走得更快，想尝试新技术甚于解决问题。所以这些创意也正像“野草”，必须由我们做出价值判断，要防止产品被它们变成荒地。

5. 早期追随者（Early Adopters）：观念比较新，但是需求目的性很强，需要迅速能够解决其问题的产品。他们是信息达人，可能很早就知道产品了，但不会盲目试用，而是先从其他渠道主动了解这个产品是干什么的，反复验证，确认对自己有用以后才会尝试，好在这批人如果开始用了会比第一种人忠诚度高很多。 我比较像这种人。早期追随者和创新者最大的区别在于，早期追随者不是为了尝试新技术而使用某产品，而是为了解决某些需求才使用，早期追随者也会给产品提很多的想法，但他们是从需求出发的。这批用户对产品发展价值极大，最好牢牢抓住，将来可以发展为产品的种子用户，不断地给产品提供改进意见。产品上市后的早期，主流用户通常是早期追随者，这时候产品可以做得偏向“专家用户”，产品的进化主要体现在功能的不断创新上。

6. 早期主流用户（Early Majority）：是产品大规模产生商业价值的用户群，他们是典型的实用主义者，也是生活中最常见的一批人，偶尔被动地听到过新产品，但觉得正在使用的老产品也能解决问题，就不会更换，但心中还是对新产品存在期待，希望有机会试一下。

7. 《跨越鸿沟》里说的“鸿沟”，就是冲出“早期追随者”进入“早期主流用户”的阶段。这时候的产品与早期有很大的不同，需要面向主流的“中间用户”和“新手”，而非“专家”了。所以在产品进入这个市场，接触这批用户的时候，需要尽量做得简单易用，才能迅速占领尽可能多的市场份额，因为这帮用户没工夫研究，他们需要的是一个能够更好地解决问题的产品。从这个阶段开始，产品渐渐稳定，小修小改也不那么让人激动，回顾一下第2.2.5节的“生孩子与养孩子”里说的，从这时候开始，我们的主要工作从“生孩子”变成了“养孩子”，不过这也是真正获得商业回报的开始。

8. 晚期主流用户（Late Majority）：这部分主流用户和早期的区别也许是心态上的。早期主流用户对新产品有尝试的愿望，而晚期主流用户对新产品心存抵触。他们直到老产品已经渐渐地出现明显的劣势，才会很不情愿地使用新产品。 比如我家里的一些长辈就是典型，全自动洗衣机已经成为主流之后，他们在购买的时候还是会考虑老式的双筒洗衣机，除了价格因素之外，他们最大的理由就是“用习惯了，全自动的按钮太多，不知道怎么用，不想学”。这个阶段产品已经定型，用户其实对产品也比较了解，市场竞争也相当激烈，所以仅仅通过功能竞争来获得用户再也不够，是典型的市场营销发力的时刻，需要通过强大的心理攻势来赢得晚期主流用户的认可。这也就是“微笑曲线”【3】右半边上翘的嘴角发力的时候。营销的创新，如果做得好，就可以达到“一招鲜吃遍天”的效果，并且相对于研发阶段的投入比较少，产出快速、可预期，是收割商业回报的大好时期。

9. 落伍者（Laggards）：最后一批用户，他们的附加值已经比较低了，如果我们实际一点，就可以更注重眼前利益，在不违背道德标准的前提下，赚一票是一票吧。这时候，产品渐渐退出，市场也渐渐萎缩，或者说转移，因为必定有新产品成长起来，长江后浪推前浪，前浪必然死在沙滩上。

10. 上面的生命周期只是一种解释，现实的产品、市场、用户并不会严格按照这里所说的阶段走，有的产品某个阶段也许特别长，或者非常短，甚至没有；有的产品也许会同时处于多个阶段，一浪又一浪地重叠在一起，部分功能已经走到晚期主流用户，部分功能还在早期追随者阶段。 所以，对于我们来说，必须找到背后不变的应对之策，不管哪个阶段，都是要先明确，我们现在要主打哪种类型的市场与用户，他们的特点是怎么样的，然后再决定应该做什么产品、用什么功能来满足相应的需求。

空间之大：商业、产品、技术

11. 产品最终的商业化成功与否，推及一个公司的成功与否，所有的影响因素似乎都可以归结到“大产品”的空间上，具体点说，是商业、产品、技术三个方面，如图4-3所示。

12. 商业，在公司里主要由市场、销售、服务等部门来考虑，他们决定产品的销售渠道、价格策略、促销策略、服务方式等。比方说，再好的产品，如果卖得太贵，目标用户负担不起，那注定要死掉。又如促销活动与产品库存的准备没有配合好，结果很多用户下单却无法满足，也会给公司造成极大的损失。

13. 产品，此处是狭义的，由我们平时说的“产品部门”，包括产品设计、用户体验、产品运营等部门来考虑，他们决定了产品的功能范围、交互流程、视觉表现、运营手段等。这些是我们最熟悉的，试想一款单制冷的空调，在夏天热得要死，冬天又冷得要死的长三角，是注定卖不好的。

14. 技术，主要由开发、测试、运维等部门考虑，他们决定了产品的稳定性、性能、Bug数量等特性。我在2003年前后曾经使用过一款摩托罗拉的T720手机，当短信的收件箱里有50条以上的短信时，再看新短信都出奇的慢，要等10秒以上，很快就让我无法忍受，换了手机，把它送给了收发短信都不太多的长辈。上面这个例子说明性能也会影响用户对产品的体验。 这三个方面共同构成了“大产品”在空间上的三个维度，我们可以理解成，他们的乘积决定了产品最终成就的大小，任何一个维度上的提高对产品都大有好处，任何一个维度太弱对产品也都是致命的。

15. 上述三方面，任何一个公司必然有它的强项和弱项，它不可能也没有必要在这三方面都很强，一是因为构建“性价比团队”的考虑，二是因为都强的话互相压不住反而造成内耗，所以更重要的是找到自己公司、或团队、或产品的那个突出的刀尖，也就是所谓公司的DNA。 非常明显，Google是技术主导的团队，从一位在Google做过市场工作的女生那里了解到，工程师在Google拥有绝对的话语权，而市场人员的地位相对较低；Apple则是无可争议的产品主导型公司，它的设计已经拥有了一种气质，它的产品几乎件件都是艺术品，就算现在Apple做个手电筒，叫iTorch，我相信也能卖出不少；而Alibaba就是第三个方面——商业主导的了，商业的强势也说明了阿里为什么不招技术很强的应届毕业生，而Business Sense，商业感觉是在真实的商业环境中工作磨炼出来的。不过个人感觉，这两年阿里开始体会到技术的瓶颈，已经在加大技术方面的投入了。 通过上面这段简单的分析，大家可能也发现，一家公司哪方面更强，其实也是和其产品的特点有关的，所以说到底，这些方面都可以看做是产品经理需要关注的事情。

16. 换个角度看，上面这段可以送给想找工作的朋友，大家在找工作的时候必须调查清楚自己的职位在公司里是不是最受重视的，是不是强势方，这很重要！举个不是很现实的例子，如果你在特种部队式的组织里，那么可以安心地做一个特种兵；但如果你进了塔利班或基地组织，那就抓紧时间进入管理层！

4.1.2 设计之大

17. 产品的设计之大，体现在产品设计的多个层次上。 产品战略层面上的设计，决定了“做不做”、“做什么”，在第2章谈需求的时候说了一部分，第5章谈战略会再说一些；狭义的产品设计层面上的设计，要决定“做多少”、“怎么做”，前两章及这章都有涉及；而产品实施层面上的设计，决定了“谁来做”、“何时做”，主要内容在第3章的“项目”里。

产品设计的五个层次

18. 战略层：明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点。例如，通常的商业目标是赚的钱越多越好，而用户则想花的钱越少越好，这种最底层的冲突没法通过产品设计解决，而要靠商业上找准价值的切入点。作为产品设计人员，早些年可能接触不到制定战略的过程，但仍然要深刻理解公司战略并尽可能发挥自己的影响力，这个话题是第5章的主要内容。

19. 范围层：明确“做多少”，对于软件类产品，是确定功能范围；对于网站类产品，则是确定内容范围。这时候要做好需求的采集、分析、筛选、管理、开发工作。复习一下第2章的主要内容，先要“尽可能多地收集”，灵活运用多种用户研究的方法，不要遗漏，再“尽可能多地放弃”，因为我们的资源有限，只能做最有价值的，先做的“收集”不是为了“放弃”，而是防止遗漏任何“有价值的”需求。

20. 结构层：考虑产品的各个部分互相之间是什么关系，上一步相当于把一桌子菜的原料都买来了，这一步就开始确定哪些原料组成什么菜，具体是蒸是煮是炒是炸了。对于软件类产品，主要工作有交互设计，对于网站类产品，主要工作有信息架构。这一步常见的产出物有软件的业务逻辑图、网站的站点地图等。一般来说，技术部门在这时开始全面介入。

21. 框架层：到了这一步，才出现用户真正能看到的东西。对于软件类产品来说主要的工作是界面设计，对于网站类产品则是导航设计，两者都有的是信息设计。大家经常看到的网页，是上下结构，还是左右结构，导航条在哪里，分几级，都是这个时候设计的。对新人来说，常见的错误就是认为从这里开始才算设计，接到一个任务马上就开始想网站的页面应该长成什么样子，而忽略了上面的几层，这样在大前提没思考清楚的情况下做出来的产品必然会成为一个悲剧。

22. 表现层：最后一步的主要工作包含了视觉设计和内容的优化，比如页面的配色、字体字号等，这里的表现决定了最终产品的气质。这部分是最有意思的，但好的设计师一定要理解商业和用户的目标才能做出正确的设计，毕竟我们不是艺术家。解释一下，设计师和艺术家的区别就在于要满足的对象不同，一个是“你！你！你！你！你！”，另一个是“我！我！我！我！我！”。

23. 产品设计的这五个层次，从整体看是抽象到具体的过程，是从概念到实现的过程，又有一点从商业到产品到技术的感觉。虽然在时间上是顺序的，但各层之间的界限模糊，彼此交叉，而且必须反复迭代。对于很多创业团队来说，也许一个人就要搞定所有的设计工作，也没法区分今天做的是哪个层次的工作，所以这五层并不用写在纸上，而是应该记在心里，有时候可能一天之内做的事情就囊括了五层，但速度再快，设计的思路都是在这里，逃不掉的。

我用五个层次来写书

（无）

设计的“现实与浪漫”

24. 诺大师把设计的目标分为三个层次，即本能水平设计，行为水平设计，反思水平设计，有观点说是对应了心理学里人脑的三种不同的加工水平：本能的、行为的和反思的。本能水平就是纯生理的视觉冲击，就像“第一眼美女”，看上去就喜欢，没什么好说的；至于行为水平，我认为就是《设计心理学》一书的主要内容，主要讲的是产品功能、用户与产品交互层面的设计；而反思水平则是诺大师思想的又一次升华，通过《情感化设计》一书，把纯心理需求也纳入了产品设计的考虑范围。 行为水平的设计，和我们日常的工作很接近，能把产品做到好用、贴心就已经很不容易了，毕竟生活中仍然存在太多让人不满的产品。

25. 行为水平的设计，和我们日常的工作很接近，能把产品做到好用、贴心就已经很不容易了，毕竟生活中仍然存在太多让人不满的产品。虽然大师举的都是传统产品的例子，但一些原则却是非常基础，让人印象深刻，比如： 反馈：动作前的可预测、动作中的积极响应、动作后的可评估。比如网页上的一个按钮，我把鼠标移上去它的样式有些改变，单击以后马上表现出被按下去的样子，点击完毕后告诉我后台的程序“正在查询，请稍候”。 容错：一些貌似多余的强制性设计，不可逆操作可以后悔。比如工业仪器上，设计师经常给一些重要的按钮上加个盖子，并且按下之后还需要再次确认。又如电脑USB接口的“防呆”设计，让用户只能从一个方向插入USB设备。对于错误的理解，我们要做到“用户没有错，所有的错都是设计的错”。 简化：充分利用用户已有的知识，利用心智模型，利用标准化，利用一切。比如现在各种软件默认的复制、粘贴功能，图标长得都很像，快捷键都是“Ctrl+C、Ctrl+V”。

26. 当一个产品在行为水平上做好以后，就可以算是一个优秀的产品了，但要做到伟大，大师觉得，反思水平上的情感因素变得更重要。这对设计师提出了极高的要求，只有更进一步的不但好用，而且想想都或开心、或伤感、或恐惧……的设计，才会华丽丽地升级为ART，这里我不用纯大写不足以表达“艺术”这个词的牛气。达到这一境界的产品，也许iPhone算一个，它确实让人用起来很爽，而且达到了“就算用户用得不爽，也会不好意思说，而是认为自己没有理解设计师意图”的境界；也许一些创意家居用品算，淘宝上很多，比如做成花一样的台灯、人形的调料罐；也许游乐场里的过山车、海盗船算，用户的需求本身就是情感化，为了寻找刺激的。

27. 不过，对于要给大多数普通用户用的产品来说，本能水平、行为水平、反思水平的设计还是要挨个满足的。第一个层次，本能水平的设计是基础，产品要有用，能满足用户的某种需求；第二个层次，行为水平的设计是保证，产品要能用，好用，顺利地解决用户的问题；第三个层次，反思水平的设计是升华，是难以捉摸的“用得爽”，对大多数公司来说，最多只是面包上的果酱，行为水平还没做好就去追求反思水平真的没有必要，真的做一个没有行为水平、只有反思水平的“卡洛曼茶壶”【6】，那也只能给那些没事儿就愿意穷得瑟的用户们去用了。 大家再一起默念一百遍：我们是现实的设计师，不是浪漫的艺术家……

4.1.3 团队之大

想当年，一个比一个猛

28. 似乎，每个团队都是从这样开始，每个人都是全能战士，那个时候的感觉挺好，但随着产品的发展，团队总是从很少的几个人起步，渐渐产生了分工，最后变为一家公司。

从几个人到一家公司

29. 上一节的故事给我的启发是，有必要思考一下做产品的团队，是如何从个人进化成一家公司的？这中间的各种职责为什么要切分？各种职位又为什么会出现？

30. 公司大了，人多了，新的难题出现了，那就是—— 如何设计各种职位，让各种人（职员）与各种事（职责）互相匹配。

31. 很多人问我最佳的产品团队应该是什么样的组织结构，怎么设置各种职位。现在你知道了，职位并不关键，在想明白做一个产品要完成哪些事情，做这些事需要拥有哪些能力的人，团队处于什么阶段之后，应该设置哪几种职位的答案自然就出来了。所谓最优团队，每个个案都不一样，别人没法告诉你。

接口人存在的价值

32. 公司大了，必然会出现各部门分工做不同的事情，但是，有些事情总是分不清楚，总是需要多个部门之间来配合。比如产品上线以后，PD都会遇到日常的Bug处理、工单处理这类事，常见的故事是这样的：

33. 我们开始很有激情，给客服的同学培训完产品以后，许下诺言：“以后用户那边，有什么搞不定的问题都转给我好了，把我的手机号给用户都可以……”。这时候PD也的确急切地想通过一切途径了解用户对产品的反馈。前几天还不错，每天都有客服转过来的几个问题，有时候也会把用户的联系方法要过来，直接和用户交流，收获不小。渐渐地，随着产品的用户越来越多，问题也越来越多了，我们感到忙不过来，更头疼的是发现很多问题是类似的，占据了日常工作的大部分时间，让人烦躁不堪。有一天，我们终于受不了了，跟老板说，我要变成客服的客服了……老板说，很简单啊，让客服部门确定一个接口人吧。

34. 于是就像如图4-5所示，接口人做了你做的大部分工作，他不存在“变成客服”的抱怨，他本来就是客服的同学。之后，接口人给你的问题才是真正的疑难杂症，才是真正体现你价值的问题。

接口人存在的价值

35. 不管是客服还是其他部门，接口人一般会让相关部门中比较资深的同学来担任，他起到了问题过滤的作用，可以解决大部分一般同学搞不定的问题，并对相似问题进行合并。 后来，我体会到接口人还有个好处，就是缓解“办事要靠脸熟”的问题，一般让沟通能力比较强、已经和公司里多数人很熟的人来做接口人，事先明确了他们的职责，通过他们来连接多个部门的陌生人，可以减少部门合作时，陌生人之间的沟通成本。当然，最好能在公司里培养起“对事不对人”的文化，那会使得沟通成本大大降低。 我的理解是，部门协作出现问题，是因为“找不到共同的利益”，如果不是公司内部的合作就更头疼，合作的基础就是有共同的利益，或物质或精神，或短期或长期，但务必要找到。

我身边的矩阵型组织

36. 任何一个超过几十人的团队，就必然脱离“一个班长带几个兵”局面，产生自己的组织结构，常见的有职能型组织、项目型组织和矩阵型组织。组织结构是对项目、产品等的支撑，组织结构的设计也可以看做是一种很高级的产品设计，这一节来谈谈我对它的理解。

37. 职能型组织是把相同职责的人划分在一个部门里，有利于同类资源共享，互相学习提高，但公司的目标在分解到各部门之后，很容易不一致，而且每个部门唯一的客户就是“上面”，都只对“上面”负责，导致没有人对真正的客户负责。我和同事讨论认为，这种形式比较适合大规模运作型的公司或部门，适合计划经济，比如大多数工厂的车间，人真的可以当做可替换的“资源”的情况。

38. 项目型组织正好相反，是把各种职责的人组成一个个的项目组或产品线，团队目标一致，有利于快速推进项目，但是会资源浪费。项目组发展下去就是事业部，甚至分公司。说明一下，从组织结构的角度讲，项目型组织的头是项目经理或产品经理（为了方便起见，这一段下面单说产品经理），和职能型组织的头——部门经理相对应。

39. 矩阵型组织则是上述两种组织结构的融合，如图4-6所示，就是前两年某段时间我身边的组织结构，横向是产品线、业务线，为了对客户负责；纵向是资源线、行政线，为了资源共享。如果说职能型组织比较适合防守型的业务，项目型组织适合进攻型业务，那么矩阵型组织就是全攻全守。但它也有很明显的问题：对员工来说，一面是部门经理，另一面是产品经理，这样的“双头领导”总是很让人头疼，那么这两种职位可以通过兼任来解决矛盾吗？

矩阵型组织

40. 有一次培训的时候，老师解答了这个问题，答案是否定的。产品经理主要管事，有成就感，像“猎人”，类比到军事上，就是对打仗负责，需要有攻城拔寨的能力；部门经理主要管人，有权力，像“农民”，对练兵负责，贡献技术与人，有防守与后勤的感觉。那么，部门经理如兼任产品经理，就会用权力来寻求成就感，或者在产品KPI的重压之下，放弃农民的责任去做猎人，造成行为的短视，主动或被动地忽视团队能力的提升。这是人性的弱点，无法避免，目标不同导致手段不同。在矩阵型组织下，部门经理和产品经理就应该各司其职，至于“双头领导”的协调，应该由用人的产品经理提供建议，养人的部门经理决定对员工的考核，同时培养每个人对事负责的态度。

41. 不过，在很多公司中难免会有同一个经理既管事又管人的情况发生。我想，只要明白了上一段提到的问题，这样也未尝不可，只是当事人需要自己权衡两边的得失了。

4.2 游走于商业与技术之间

42. 有一种说法说我们的性格，去做工程师会显得太外向了，而去做销售又显得太内向了，工程师们把我们当做业务人员，市场销售们却把我们当做技术人员……这就是我们，游走于商业与技术之间的产品团队

4.2.1 心思缜密的规划师

43. 首先要讲的是狭义的产品团队，具体是指产品经理及其带领的产品规划师、产品设计师和需求分析师【8】，通常在团队中，都被简称为PD，但各人的具体分工会稍有不同。产品经理和产品规划师，更偏向于产品前期的规划，比如产品的市场定位、各个版本发布的时间计划等，在这个层面上，商业目标、用户需求是思考的焦点，当然，公司的管理层也会充分参与这个过程，较大的决策通常由老板们最终拍板。产品设计师侧重于做功能级的设计，编写需求文档，在某个模块上，他们很像一个小产品经理，比如，要做进销存，具体到库存管理是否需要提供库存警戒功能，警戒数字是只有上限或下限、还是都有，警戒数字设置是否需要批量操作等。更为细分的RA，只在部分部门里存在，在这种分工下，PD的工作尽量往前走，偏市场、用户，产品的规划；而RA尽量往后走，偏实现、技术，即写UC，做系统设计。 总的来说，狭义的产品团队所做的事情，最符合互联网、软件行业产品经理的招聘广告里的描述，他们有大局观，逻辑严密，理智而冷静，我们不妨叫他们为“心思缜密的规划师”。

从概念设计到信息架构

44. 概念设计的产出物是产品概念图【9】，个人认为它比较像第2章里提到过的业务逻辑图，但比业务逻辑图更抽象。产出概念图应该是在需求采集之后，需求筛选之前，基本和需求分析属于同阶段的任务，在纷繁复杂的各种用户需求之中，我们需要通过概念图来理清思路，找出到底应该“做什么”，并将这些打算做的需求整合为一个合理的系统。 如图4-8所示是一张流传甚广的典型概念图

Flicker产品概念图

45. 不过，上面这种图毕竟太难画，要把产品想得很清楚才能画出来，这往往是产品已经成型之后了。那么，有没有简单一些的做法？我们常用的是以下两种。 第一，在思维导图上改画出概念图。用户需求采集上来，我们或简单转化为产品需求，或直接画在一张思维导图里。然后，开始整理这堆“乱七八糟”的东西，比如把各种需求做简单的分类，把一些条目打上各种标记，把相关的需求连几条线，写一些注释，就算完成最粗糙的概念图了。 第二，是找个会议室，用马克笔在白板上画出自己对将来产品概念的想法，完全不要受拘束，然后大家一起讨论改进。这样手绘的概念图很酷，大家可以试试，画完了拍下来，存到电脑上，有必要的话可以重新画成更漂亮的电子版。 这步做完，产品相当于有了整体的业务架构，下面就可以进入需求筛选阶段，大家来决定先做哪一部分、后做哪一部分了。所以说，概念图其实描述的是整个产品的内外关系，形式并不重要，重点要表达出下面两点。

46. ►　产品与外界的关系：把产品整体看做一个系统，描述它与上下级系统、并列系统的关系，可能的话，勾勒出产品所处的产业链结构。 ►　产品内部的关系：产品有多少模块、模块之间的关系如何，不用涉及数据流等细节，重点描述清楚不同的角色在系统里的身份。 概念设计是为内部而做的，为了团队的沟通，便于大家对产品达成共识。所以我觉得，完成概念设计之后，才可以开始信息架构的工作。相对的，信息架构是为外部而做的，为了设计出更合理的方式，把信息传递给用户。这个先内后外的过程，也可以看做是从“做什么”到“怎么做”的过程

47. PD和普通用户看产品、想问题的角度通常是不一样的：PD习惯于从内向外，从本质出发；而用户习惯于从外向内，从表面看起。所以，不论是概念设计，还是信息架构，都应该从用户的角度出发，以用户为中心，这意味着将来产品的表现要更接近用户的心智模型。而技术架构层面真的不用太关注用户，我们留给工程师们吧。

PD的出身及其优劣势

48. 那么，各种出身的PD的优劣势是什么呢？我的答案很简单，你之前做的事情是你擅长的，那就是你的优势，也是你的劣势。对PD这种职位来说，没有任何一项技能是没用的，而任何人也没法掌握全部需要的技能。 从个人角度解释一下，比如一位从开发工程师转型为PD的同学，擅长的事情很显然是技术方面的，这时候就看他怎么用自己的“背景”了。在整个团队中，他最大的优势是懂技术，用好了，可以在产品早期的时候思考更全面，能在一开始就判断出哪些事情根本就不靠谱，从而避免浪费资源，并且在进入实施阶段后会与工程师沟通得更顺畅；最大的劣势也是懂技术，用不好，就会让技术压倒商业，在业务逻辑还没确定的时候就考虑过细的实现难度问题，导致方向走偏，进度受限。所以说，PD之前做什么不重要，我们必须是一个通才而不是专才。

49. 从PD团队的角度来看，成员组成就应该尽量丰富，商业、技术等各种背景的同学都有会比较合理，这样可以优缺点互补，考虑问题更加全面。我身边有的团队，大部分PD都是做传统软件的项目管理或开发出身，在做产品的过程中，他们深感对互联网产品的“感觉”不到位，对用户体验有心无力，这就成了产品的短板。另外，公司里新人过多也是大问题，这也是小公司、高速成长团队必然存在的问题，老中青的梯队还是必要的，个人感觉经验在一年内的同学最好不要超过一半，而且需要有三年以上经验的同学压阵，这样的结构才稳定。

4.2.2 激情四射的设计师

50. 规划师更多的是“结构化思维”，保证产品有用，能满足用户的某些需求，让产品“从无到有”；而设计师更多的是“形象化表达”，保证产品好用，能让用户用起来舒服，让产品“从有到优”

51. 用户体验部门各种职责的细分，通常主要有如下几种。

52. 用户研究员（User Researcher），一看就知道，是做用户研究工作的，他要利用各种方法进行用户研究，给产品决策提供建议。

53. 交互设计师（Interaction Designer），他要负责人机交互界面、用户操作流程的设计，典型的工作有导航设计、信息设计等，必须要了解很多商业的内容，理解功能的商业价值。举个例子，比如在商业目标是“注册用户数”的前提下，去设计注册流程是一页搞定还是分几个“下一步”，出错提示如何处理等。

54. 视觉设计师（Visual Designer），在很多小作坊被简称为“美工”，他与交互设计师的界限也挺模糊的，他们主要做视觉设计，即用户第一眼看到的效果，比如页面结构、配色方案、字体字号、按钮的形状、颜色、大小、质感等。

55. 前端工程师（Web Developer），互联网行业特有的一个偏技术的职位，要运用前端技术进行Web页面的开发，实现产品体验的良好传达。我们在网页上看到的各种很炫的效果，通常都是他们的杰作。

产品新首页诞生记

56. 一开始，大家一起讨论，手绘出首页的大概样子。PD要表达清楚每一个模块的商业目标，可以给出自己对页面的布局建议，但最终的页面结构由UE主导确定。 然后是线框图，PD有时候也会直接给出这个图，但在“变脸”项目中，是UE做的。大家仍要讨论确定，UE这时候会在设计的过程中融入很多自己的想法，PD要做到的就是防止走偏，保证大家对商业目标理解的一致。比如在图4-12中，大家讨论后确定页面为“左侧大、右侧小”的双列结构，并且左侧的内容主攻普通访客，右侧的内容主攻付费用户。 接着，UE做出页面效果图，PD安排销售、服务等相关方来做一次Demo评审，告诉他们这就是将来看到的页面，征求意见。他们一定会有各种疑问，这时候PD和UE需要确保每一个细节设计都是有理有据，包括每块区域的位置、长宽，每行文字的字体、字号，每张图片的颜色等，都不只是为了好看，而一定是与商业目标相符合的。

当交互设计遇到敏捷开发

57. 让我们先回忆第3章谈论敏捷开发的时候说，我们说要快，先发布再说，慢慢改；而交互设计的理念是精雕细琢，慢工出细活。我们在纠结，大师们也纠结过。 2002年1月15日，交互设计之父Alan Cooper和极限编程【15】创始人Kent Beck在PK，话题是“当交互设计遇到敏捷开发”。 ►　Cooper大爷认为子弹很贵，因此在每次开枪之前一定要精确地瞄准。负责瞄准的人应该是专业的交互设计师。Cooper大爷很适合做一个狙击手，点射的命中率几乎能够达到100％。 ►　Beck大师认为有了敏捷开发，子弹变得很便宜，不需要瞄太准，打不准就再放一枪，没什么大不了，最终总能打中目标。Beck大师很适合做一个机枪手，机枪是不可以点射的，一般都是扫一片，用密集的火力消灭敌人。

58. 还是那个道理，方法只有合适与否，没有好坏之分。也许“交互设计”比较适合传统领域、成熟公司、时间资源充裕的，公司在某领域中已经处于领先地位，目的是求稳，不犯错就是胜利；而“敏捷开发”适合新兴行业、创业公司，时间紧迫，大家都在赶，谁先出头谁就能占得先机，或者作为挑战者进入某个行业，团队本身灵活，失败了损失也不大，重来的成本低。从这点上看，互联网行业似乎更偏向于使用敏捷开发的方法，但敏捷绝不是在时间紧迫下被动的放弃交互设计，而是主动为之的一种思想，并且要将交互设计融入其中。 “交互设计”之于“敏捷开发”，正如哲学里“对立统一”的概念，有点像楷书与草书，没法评价哪个好哪个差，也许结合一下又出现了很赞的行书。两者考虑问题的角度不大一致，其实并不存在大的冲突。相反，交互设计与敏捷开发方法如果能够结合起来，就能以更小的成本交付令用户满意的产品。

信息展现设计的例子

59. 图4-13已经把所有的信息都展示出来了，但重点不够突出，各种信息都使用一样的字体，让人不知道一开始看哪里，而如图4-14所示的图表就优化了很多。首先各种文字用了不一样的字体，图表的标题最明显，让人一眼就知道这个图表是说什么的。月份与城市信息稍微弱化以突出数据内容，特别值得一提的是这里用了不同深浅的颜色来突出数据，让人很容易解读出某个城市全年整体的降水情况，降水季节分布等信息。

把数据表格化

60. 我常说“字不如表，表不如图”，再回忆一下上面的图表，你还能记住Miami在8月的平均降水量吗？我是不能，但我记得Miami在夏季的降水量很大。这给了我们启发，其实要传递的并不是具体的数字，而是每个城市在全年的降水量整体情况与分布，所以说某个城市某个月的降水量，表达成类似“很多、多、少、很少”的形式会更好，数据只是给极少数做科学研究的人，在需要的时候可以查到就可以了，在表现形式上，我们可以处理成鼠标悬停在某个区域的时候，就展现出相应的数字。于是，我们进一步优化出如图4-15所示的图表，用很符合读者心智模型的水滴大小、颜色深浅来表示不同的降水量区间。现在更加一目了然了，San Francisco最干，冬天稍微好一些；而New York全年降水很平均……

突出重点信息 数据可视化

61. 图4-16可以与用户交互，把时间轴做了个动态展现，拖动时间轴，我们可以看到几大城市，甚至可以推测出全美国在一年中各地的降水情况。当然，如此炫的表达也有其弱点，那就是没法如图4-15一样一次性看到所有信息了，这个需要我们来权衡利弊。

聊聊细节，文案设计

62. 这里不是指网站里大段文字的编辑工作，而是指产品中随处可见的文字问题。自己的体会：

63. 低级阶段：错别字，病句，错误标点。

64. 中级阶段：用词不统一，不准确。

65. 高级阶段：语言风格不统一，产品气质不统一。

66. 最后，需要给大家泼点冷水，虽然我们这么用心地去琢磨文案，但产品里的文案却是越少越好。用户都是凭着自己的感觉去使用产品，他们通常不会去看帮助、不会去看说明书，甚至不会看页面上一句话的提示，如果一个功能需要配合100个字的说明，那我们就要考虑这个功能是不是做得有问题了。

4.2.3 “阴险狡诈”的运营师

67. 如果说规划师是产品的父母，把产品生出来；设计师是产品的老师，把产品教育好；那么运营师【16】就算是产品的老板吧，他们要把产品卖出去，让产品从“叫好”到“叫座”，让更多的人愿意使用产品。

产品与运营的战与和

68. 一方面，产品需要好的运营。今天已经不是“好酒不怕巷子深”的年代了，各种产品都极其丰富，没有运营，产品只能“养在深闺人未识”，慢慢消亡。另一方面，运营也需要好的产品，运营只能把人带来，而把人留住就必须要靠产品了，只有产品真的有用、能用、好用，才能看到运营产生的持续效果。

69. 这样看起来产品和运营的同学应该亲如兄弟，但在现实中，产品与运营却总是充满矛盾，经常看到他们吵得面红耳赤，这又是为什么呢？ 通常是因为运营的同学背着更直接的商业指标，比如年底前网站的PV（Page View）要达到1亿，用户活跃度要达到60％。大老板们的出发点通常都是好的，但传达到执行层面以后，就只是一个数字了，大家忘记了数字背后的目的。虽然说这样的简化、量化便于管理，但麻烦的是，数字总是有漏洞可以钻的，所以经常就是运营为了数字而数字。

70. 产品团队与销售团队也常常因为类似的问题而争论。这是运营的错，没分清目的与手段，只为提升PV拉了很多垃圾流量，而如果挖掘真正的用户则需要做更多工作——去寻找目标用户、去调研、去与产品团队合作；也是产品的错，那么多的PV，居然一点儿人都没留住；也许，更是数字惹的祸，老板们是否可以用更合理的数字来避免问题？比如追求注册用户数、活跃用户数等，而不是PV？也许，那些数字更难，或者看上去不会这么好看。

71. 客观地看，不论是高层、运营，还是产品团队做的事情，都是在平衡短期与长期利益。有时候产品与运营共同承担商业指标会好一些，但运营的同学总会显得急一些，他们希望尽快看到效果，而产品的同学则热衷于练内功，好在大家的根本目的是一致的，只是这个度需要双方共同寻找平衡点。

个人博客运营实例

72. 在我心目中，一次好的运营就是事前“预谋”，事中按计划执行，事后拿到结果并为下一次运营积累经验。

一次无意识的“事件+病毒营销“

（无）

4.3 商业团队，冲锋陷阵

73. 我是理工科出身，所以前几年总会觉得商业团队做的事情与技术团队比起来，都太虚，直到最近才渐渐体会到，我们觉得某样东西虚只是因为对它不熟悉而已。

商业团队简图

74. 前线的团队，主要任务是市场、销售，需要负责产品价格策略、促销策略、销售策划、渠道管理等；另一块任务是服务，也有细分，比如客户服务、技术支持、服务策划等。最最简化了以后的图示如图4-20所示。公司里经常出现的情况是谁直接创造效益谁牛气，所以经常是销售的同学“蹂躏”产品的同学，然后产品的同学又去“欺负”服务的同学。这里我特别想帮服务的同学说句话，他们经常被看成是支持部门，而实际上他们给产品带来的价值很大。“一手抓销售，一手抓服务，两手都要抓，两手都要硬”。他们都是和用户、客户最近的。如果说销售是增加新客户，让客户对某个产品第一次付钱，那么服务就是稳住老客户，让客户对某个产品不断付钱。

4.3.1 好产品还需市场化

75. 我觉得这本书的一个主要思想就是，好的产品需要市场化，不然就成了实验室里的样品，公司不能总是搞科研，必须得赚钱才能可持续发展。产品市场化要做的事情很多也很细，比如做一次公开的市场推广活动，就牵涉到市场预算的及时到位、宣传资料的准备、事前事后的PR轰炸等，确实需要经验丰富的“老鸟”来做。

定价与促销

76. 先来点基础知识，销售有两大模式：直销VS.分销。分销要通过渠道，渠道又分代理和经销。他们的区别是“代理”赚佣金，没有产品所有权和库存风险；“经销”赚差价，产品所有权发生转移，比如批发商。

77. 现在网络上的付费产品，生产商和消费者之间有了互联网的连接，更容易直接接触，加之网络支付等服务的成熟，所以网络个人应用，大多数都采取了直销。而我们的“e网打进”是面向企业用户的，而国内中小企业现在相应的知识和意识还略显落后，所以我们选择了渠道销售。

78. 在渠道战术的推拉方面，所谓“推”是集中力量做渠道工作，用高额利润去刺激渠道主动推销产品，快速抢占市场；而“拉”是通过PR、广告、传播等手段启动市场，刺激消费者，促使渠道来找厂商。推适合企业规模小、技术含量高、销售过程复杂的产品，一般来说：新产品推，老产品拉。“e网打进”用的显然是推的方法，其驱动路线是“厂商→渠道→终端用户

79. 第一，通过渠道销售的产品，新增功能和改动功能的时候，还需要额外考虑公司内渠道管理人员的培训成本、渠道商的培训成本，要他们把一个功能说明白很不容易。第二，既然选择通过渠道来销售，就说明终端用户对互联网的应用能力不足，所以相应的设计思路也要转变。第三，在渠道终端的用户一般是企业，企业用户与个人用户的差异也不得不考虑。比如支付，企业用户就会有开发票的问题，不能只简单地考虑网上支付途径。第四，由于渠道的介入，多级的定价，分成比例，开发票的流程，渠道政策都要有相应的系统支撑。

另一种产品版本细分策略

80. 一种是做功能区分，打细分市场，这个同学们都比较熟悉，比如笔记本的高中低端产品、手机的各种型号，不用多说。 另一种是为了促进销售，利用消费者心理，纯策略性地做出“炮灰版”，完全是和你玩虚的，常有手法如下。

81. 第一，有的在原有版本的基础上，添加一些鸡肋功能做一个价格高出很多的“高价炮灰”，让消费者觉得商家真正想卖的那个版本特别实惠。

82. 第二，删掉核心功能做一个价格稍低的“低价炮灰”，反正就是要让用户觉得他要是买那个便宜的版本就是脑残

开阔视野的水平营销

83. 纵向营销是Evolution（进化，特点是渐变），水平营销是Revolution（革命，特点是突变）。大家也一定都渴望突破性的革命而不是慢慢地进化吧。

84. 假如我要卖包子，垂直营销的话我就得越来越细分市场，包子做成大号、中号、小号，另外做32种不同的馅，做到累死。假如要水平营销，我可以按照书中说的几个维度、几种手法来激发自己的创意。 首先想市场层面。 需求维度：吃包子的同学们需求是什么呢？填肚子。

85. 目标维度：本来的目标应该是中国人。

86. 卖个包子都可以有这么多的创意，我们看到，营销也不一定要一个劲地让产品在红海【26】中搏杀，而是可以通过这些点子帮助产品在愈加同质和超竞争的市场中找到自己的蓝海。

4.3.2 我们还能做什么

87. 对市场销售，我们可以分析数据，给他们的决策提供支持；我们可以提供总结好的核心功能与卖点，而不是给出功能列表让销售自己想；我们可以参与销售策略的制定；我们可以为产品上市的新闻发布会出谋划策……我们还能帮市场销售团队做什么？

88. 和服务有关的事情，除了在产品正常运行的日子里做好技术支持一类的工作，一起更新产品的帮助，我们还能参与服务策略的制定。

“老板，要光盘吗”

89. “e网打进”这个产品一直没找准方向，留一个共性问题我们一起思考。对于产品部门来说，一定是先确定目标用户再设计产品。而对市场销售等商业部门来说，现实中往往是先拿到产品，再去考虑去主打哪些市场与用户，他们并不管产品部门原先定义的目标用户是怎样的，而是去寻找最容易的突破口。所以，产品与市场两边的配合很重要，需要互相调整来彼此适应，这样的轮回并不是一个闭环，而是螺旋上升。有的时候一个产品已经做出来了，原先设想的目标用户并不买单，我们也别急着去找哪些功能设计错了，怎么改产品，而不妨先换个角度想，产品与市场不匹配，除了改产品，也可以改市场嘛，有可能这个产品对另一部分市场和用户正合适，真的是“歪打正着”。

算出来的服务策略

90. 服务部门是为昨天的利润工作，给已经购买产品的客户提供承诺的价值；销售部门是为今天的利润工作，把产品变成利润，争取更多的客户；开发部门是为明天的利润工作，确保明天我们有优秀的产品可以卖；研究部门是为后天的利润工作，了解趋势、发展科技，保证永远处于领先位置。

91. 维护一个老客户的成本大约是开发一个新客户的成本的四分之一。

92. 由此可以看出服务团队的重要性，他们一直在高效地完善产品，所以我们来要帮一下服务团队。如图4-23所示是用户从签单到使用的监控过程部门包括简图。我们公司里参与这个过程的部门包括营销、产品、服务，每个部门在不同的时间点上要做不同的事情。毫不夸张地说，这幅图里的每一个过程有哪些动作，它们之间的先后顺序，动作的时间点，都是通过数据分析算出来的。

与商业团队共同制定的用户初始化策略

93. 在用户签单以后，一周内应该完成初始化动作1、2、3，否则需要督促并惩罚渠道商。 用户签单1个月时，应该有第一通电话回访，主要目的是验证渠道商提供的用户联系方式正确，确保用户的正常使用。 用户签单3个月二次回访，主要目的是拉升活跃度。 用户签单9个月三次回访，主要目的是促进第二年的续签。 第二三次回访，对不同的用户，是用E-mail、电话，还是上门，也都可以依赖于数据分析的结果。 将来系统更强大以后，可以针对每个用户的使用情况，算出应该回访的时间与方式。服务的最高境界就是：用户使用正常的时候，绝不打搅，而当用户需要帮助的时候，电话立刻就响了。

4.4 技术团队，坚强后盾

外行眼中的技术分工

94. 在互联网、软件行业的项目中，需求评审通过后，紧跟着几种技术上的设计：编码设计、数据库设计、测试设计……这时技术人员会全面介入，在各项设计完成并执行以后，再部署发布，下面就谈谈各技术中的技术人员。

95. 编码设计，有软件架构师或系统分析师，具体到编码的执行工作就是最常见的开发工程师，他们也会有分工，有人偏前台应用，有人偏底层数据库，有人专做搜索引擎等。此外，可能会出现专职的开发经理，配合项目经理管理整个开发过程，比如协调人员、制订开发计划等，他自己并不是项目的开发人员，可以同时担任多个项目的开发经理。

96. 数据库设计，对于大用户量的应用特别重要，比如淘宝、支付宝这类服务的用户数实在是太多，所以相应的人员——DBA【27】，在业界也确实是比较强的。

97. 测试设计，相应的人员就是测试工程师，再细分一点有功能测试与性能测试等，一般来说性能测试会写一些自动执行的脚本，感觉更高科技一点。大一点的项目还会有一位测试经理，协调管理测试相关的工作。

98. 突然想起测试同学的一句口头禅：你这样做是不对的……当PD们激情四溢地乱冲乱撞时，有个严酷、冷酷、残酷的测试同学控制着，确实太有必要了——他们因为职业的关系，总给人一种很鲜明的性格印象：理性、冷静、挑剔、完美主义……

99. 不知道为什么，我们经常把测试也叫做QA，原来一直以为QA和测试是一个概念，其实QA是Quality Assurance，质量保证人员，主要做流程管理（如需求变更流程、发布流程），文档管理（如开发规范、测试规范）等。测试和QA常常是归属于同一个部门的。在软件项目的整个过程中，需要在流程和规范上控制以防止低级失误的发生。比如，有时候需求人员会觉得某个功能的改动很小，就直接叫开发人员修改而不告知测试人员，这样违反流程的行为对于复杂的系统是极其危险的。经典的CMM【28】说了很多这方面的事情，有兴趣可以去研究。

100. 上述各项工作完成之后，就要把各方面准备好的产出物拼在一起部署发布，那么就牵涉到硬件方面的管理，这就是SA【30】，系统管理员。对于复杂的系统，可能涉及成百上千台服务器，且服务器的任务各自不同，其设计与管理的复杂度并不比软件低。

有这样两种工程师

101. 一类是技术痴迷者，常见于工作不久的新人，或者少数工作很久且一直醉心于技术的牛人。这类人价值很大，在项目碰到技术难题的时候，往往是攻坚的主力，要把他们这些好钢用在刀刃上。但他们的优点也正是其弱点，技术痴迷者工作的目的似乎就是学习更多、更强、更新的技术，并乐于在项目中尝试“高科技”，他们追求的是解决难题的快感，而对项目本身在商业上成功与否并不关心。

102. 有极少数热衷于技术的人，缺乏必要的责任心和使命感，做项目是为了钻研新技术，钻研新技术是为了更好地跳槽，把项目的成败放到次要地位，甚至在项目的最关键时候提出辞职以此要挟老板涨工资。碰到这类人只好自认倒霉，去找HR【31】哭诉吧。

103. 另一类是实用主义者，常见于工作过一段时间的老人，或者只是把技术当做工具的工程师。他们的典型特点是KPI导向，公司考核他们什么，他们就做好什么，尽量少做事，做简单的事，稳字当头。看似不思进取的态度也有其巨大价值，他们往往经验丰富，在做事之前充分考虑，让每一份付出都有超额回报。他们能在一团乱麻中找出最简单稳妥的解决方案，他们很清楚自己需要什么、公司需要什么、你需要什么，有一定的商业感觉，可算是职场中人见人爱的“老狐狸”。

104. 这种人中也有极少数让人头疼的，他们是真的不思进取，做一天和尚撞一天钟，每天只给你交一份刚好60分的作业，这就要看你的公司是否有办法把他的激情再调动起来了，好在我几乎没有碰到过这样的工程师。

如何与工程师合作

105. 第一，综合大家的需求，大家最看重的居然是一个很大的话题：“流程”，但仔细想想就一点都不奇怪了，一群超级理性的人很明白“没有规矩，不成方圆”的道理，他们喜欢被规则管理而不是被人管理，当事情由人来控制的时候，总给人一种不安全、不稳定的感觉，而有流程可依的时候，心里就比较踏实。 具体到实施方面，大家再次达成共识，需求确认的时候相关人员一定要悉数参加，以免后期才发现大家对需求理解的不一致。如时间允许，每个人都应该尽早参与到需求评审中。 另外提到非常多的一点就是需求变更的流程，说明大家对“需求总是在变”这件事情已经是深恶痛绝并且有些恐惧了，但同时又意识到需求的本性就是“总在变”，所以非常希望有一个流程化的规定来严格控制这件“恐怖”的事情。

106. 第二大的问题就是“沟通”，这是团队合作必不可少的一个环节。站在PD的立场上，我们会把自己作为产品的中心，这个角色注定要和各种各样的人交流，客户、老板，以及开发、运营、测试、客服、合作等部门的同事。

107. 开发者们提出了很有意思的一点，希望大家在交流的过程中避免情绪化。人性的弱点决定了在争论的过程中每个人都希望自己得到认同，而这点往往导致思路的变形，不再考虑产品怎么做更好，而是去想如何说服对方，并且，经常有同学会把对人的反感转移到对此人观点的反对上，这很可怕。

108. 第三点是PD要不断提高自我修养，大家希望PD给出的文档在质量上更进一步，准确、全面、简洁，即时更新、保持最新。我自己觉得PD有空多了解一点技术也会大大改进与工程师沟通的效果。对于有的工程师你可以和他讲商业价值，而另外一些，你与他讨论一些技术实现更有效，当然不是技术细节。

109. 最后，顺便提一下与工程师差异极大的业务人员，我与他们的沟通、合作似乎总很顺利。虽然他们总是个个能说会道，但其思维的逻辑性、严密性不如工程师，可能突然因为想到某个主意就很激动，马上就想去实施，这时候需要我们来协助，把事情想周全，凡事有得必有失。PD们在商业与技术之间，起到了平滑过渡的作用。有了我们，可以让业务人员冷静下来，让技术人员兴奋起来。这样，团队就更和谐了。

4.5 容易被遗忘的角落

110. 产品、商业、技术，好像说完了？没有！我们忘了最关键的——公司高层、老板。 高层一般会在产品和项目的早期积极参与、影响决策，之后就闪人了。他们一般超级忙，所以会忘了我们，但我们不能忘了他们。他们不但是资源的提供者，而且是背黑锅的人，在做产品的过程中，我们总会碰到“顶不住”的时候，这时候你问我该怎么办，我想说：“顶不住”了先尽力顶，“真的顶不住”了就向老板喊救命。 容易被遗忘的还有默默奉献着的法务、财务、行政等，他们和老板们一起构成了产品的支撑团队，如图4-25所示。

111. 高层一般会在产品和项目的早期积极参与、影响决策，之后就闪人了。他们一般超级忙，所以会忘了我们，但我们不能忘了他们。他们不但是资源的提供者，而且是背黑锅的人，在做产品的过程中，我们总会碰到“顶不住”的时候，这时候你问我该怎么办，我想说：“顶不住”了先尽力顶，“真的顶不住”了就向老板喊救命。 容易被遗忘的还有默默奉献着的法务、财务、行政等，他们和老板门一起构成了产品的支撑团队。如图4-25所示。

支撑团队简图

112. 刚从学生变成一个职场人士时，总会保留一些习惯，比如把老板当做老师，总是心存敬畏。几年下来，我的体会是，不要怕老板，或者仇视老板，而是要把老板当做最好的资源，“利用”他们促成自己不断成长，下面是一个菜鸟成长的故事。

113. 最初，菜鸟什么都不懂，蒙着头做事，眼巴巴地盼着老板光临，好汇报一下工作。而往往当老板主动找你问事情的时候就是他开始担心的时候。这时期的菜鸟很容易把事情做偏，吃力不讨好。 渐渐地，菜鸟觉得这样太辛苦了，于是每走一步就问老板，“我碰到一个问题，应该怎么做”，这叫让老板做问答题。老板每每给出答案，菜鸟再也不会做无用功了，做起事来也踏实多了。但是老板心里嘀咕起来，太烦了，终于在某次菜鸟又来问问题的时候，冲了他一句：这些问题你怎么自己不先想想，你什么信息都不给我，我怎么告诉你答案…… 菜鸟继续体会，发现让老板做问答题，老板是很累的，需要让老板做选择题。于是，每次有问题的时候，他都会自己先收集很多的背景资料，然后选出几种可行的解决方案，再拿着所有的这些资料给老板做决定。现在好多了，老板开始有点轻松了。并且在这个过程中，菜鸟发现有些问题在自己寻找解决方案的过程中，已经被自己解决了，大喜。 又是很久过去了，突然有一天，菜鸟发现一件有意思的事情：那就是还可以更进一步，让老板做判断题。于是菜鸟在每次呈现给老板几条解决方案以后，又会加上自己的选择：我觉得A方案是最好的，因为什么什么……当然，菜鸟毕竟是菜鸟，因为各种原因，经常与老板的判断不同，但菜鸟在疑惑中又学会和老板讨论，渐渐地学到了一些老板的判断方法。 白驹过隙，慢慢地老板发现，自己做的判断题答案都是“勾”了，似乎每次菜鸟的汇报自己就是听听，嗯嗯两声就没什么事情了，但是菜鸟仍然在及时地问，不停地汇报，也越来越学会跟老板开条件，要资源，当然目的是为了把事情做得更好，这就是：事情我做，黑锅你背，各司其职。这是职业的思维，老板“嗯”了一声，就意味着这事情菜鸟做起来是经过授权的，出了问题是要老板承担责任的。对于菜鸟来说，稚嫩的肩膀经受不起，所以要找人帮忙，是出于对自己的保护。 再往后，事情如果向好的方向发展，那就是老板不用再帮你背了，你完全可以自己决策了，爽吗？其实，只是新的轮回，可以自己背黑锅以后，必然碰到更大的黑锅，还是要让老板背，也许是更大的老板，只不过在这个过程中，自己的肩膀得到了锻炼。

默默奉献着的团队

114. 辛辛苦苦把产品做出来，可能会因为某项与短信相关的业务违反了行业规定而无法上线，可能会因为在线支付的方式没法给用户开发票而导致大面积投诉，那真是崩溃。可悲的是，这些都是我真实碰到过的问题。 在这些问题的预防和解决过程中，有一些团队在默默奉献着，而且他们至关重要。 “任何一项新业务在法务眼里都是‘违法犯罪’！”这是我们开玩笑的说法。 法务团队，会在做产品的过程中搞定一切与政策法规相关的问题，比如产品的使用协议应该怎么写？付费协议又怎么写？哪些输入的内容是敏感词等。我们公司的法务团队还承担了知识产权的工作，他们会帮助各款产品申请软件著作权、商标、专利等，比如“e网打进”在2008年、2009年就有超过20个专利进入公示期，把产品结结实实地保护了起来。 “几千、几万块，都是先收进来再说；十几、几十块，居然要对方先开发票！”这是我们对财务的调侃。 财务团队，会特别照顾我们的付费产品。有些产品还有第三方的经销商参与，所以钱在用户、经销商、厂商之间如何流转，预付款与尾款怎样分开处理，发票如何开，如果发生退款应该怎么处理等，在产品设计的过程中都需要听取他们的专业意见。 行政与IT，这是真正的后勤团队，我们各种办公资源的正常运转都仰仗他们。大到公司的办公环境、出差的酒店机票预定、名片制作、快餐盒饭，小到每一次开会，会议室、投影仪、网络、白板、马克笔的准备，都有他们的默默付出。 衷心感谢他们。

4.6 大家好才是真的好

4.6.1 所谓团队文化

115. 很多人都在讲企业文化、团队氛围，阿里在这个问题上备受争议，外界有人觉得这种文化很好，可以让人有激情，有战斗力，也有人觉得是在洗脑，会迷失自我，对此颇为不屑。任何人的观点都只能是管中窥豹，但我知道，如果一个团队里的每个人每天都开开心心，就是很好的。

团队文化的三五事

4.6.2 虚无的无授权领导

116. 但凡讲到产品经理的基本要求，总会提到“无授权领导”，就是说在行政职位上，我们并没有下级，但在做产品的过程中，需要领导整个团队朝着目标前进。团队不“为我所有”，真的能“为我所用”吗？我们先从“管理”和“领导”的异同说起。

管理 VS. 领导

117. 管理更像科学，领导更像艺术； 管理靠的是权力，领导靠的是魅力； 管理者强调稳定，领导者喜欢冒险； 管理者依法治人，领导者以德服人； 管理的对象是行为，领导的对象是思维； 管理管正确的做事，领导管做正确的事； 管理是一步一个脚印，领导是不走寻常路； 管理者注重短期目标，领导者注重长期发展； 管理者是职业经理人，领导者是企业家和创业者； 管理是汽车的制动系统，领导是汽车的驱动系统； 管理是告诉团队怎么做，领导是告诉团队为什么做； 管理对人的影响由外而内，领导给人的力量由内而外； 管理让团队能完成这些事，领导让团队喜欢做这些事； …… 我们需要理解，管理者与领导者并不存在好坏之分，一些人有能力成为出色的管理者，但是不能成为优秀的领导者；另一些人具备巨大的领导潜力，却由于种种原因很难成为优秀的管理者。对于一个人来说，自身也可能同时具备管理能力和领导能力，这两种能力也必须一起提升才能发挥更大的作用。

产品经理应该是管理者吗

118. 从上节的对比里可以看出，产品经理必须是一个好的领导者，而工作职责使得产品经理也要做很多的管理工作，那么，为什么不给我们一个管理职位呢？或者说，本节的标题更准确地说是——产品经理应该拥有管理职位吗？有不少前辈对这个问题进行过讨论，我权且谈谈自己的观点。

119. 优势在于： 管理岗位利于拥有话语权，不知你是否同意，对产品经理最大的激励是成就感。国内很多公司的现状是，没有职权就没有话语权。当产品经理不是管理者的时候，很可能就成了一个实现别人观点的执行者。更悲惨的，作为外行的老板决策，我们执行，出现“外行领导内行”的局面，这样怎么会有成就感？解决之道，我们可以培养“专业的人做专业的事”的价值观，让产品经理在他熟悉的业务领域拥有话语权。

120. 管理岗位利于获取信息，就现实而言，公司里很多重要信息都是自上而下传递，如果能参与管理会议，就可以掌握先机。产品经理需要做很多决策，而决策失误的一个重大原因就是信息不充分，如果不是管理者，就算你的老板能传达，也有时间延迟和信息失真。这个问题，当然也有很多办法解决，比如部分重要信息是通过用户调研、数据分析自下而上传递的，又如让重要的非管理人员参与管理会议的业务讨论。

121. 管理岗位利于争取资源，跨团队沟通是一件很麻烦的事情，如果你是一个有权力的管理者，做事也挺靠谱，那么专制、独裁是最高效的手段。在争取资源的时候，至少有保底的招数——行政命令，特别是对于国情现状，“官本位”的思想多少存在于每个人的潜意识里，君不见很多团队里，其实那个大老板就是一个产品经理。从这点我们可以发现，如果产品经理有临时的资源支配权，也可以解决大部分问题。

122. 劣势在于： 管理岗位有很多行政工作，这些工作会占据产品经理大量的时间。而产品经理的所有工作，最能产生效益的都是与产品直接有关的，无论在产品生命周期的哪个阶段，跨部门沟通、做规划、跟进项目、接触用户、分析数据等都已经忙不过来，如果再来一块“官场”有关的事务，那必定不堪重负。所以，我们应该让产品经理“对事负责”，对业务负责，而其他的一些事务性工作，不妨留给其他管理岗位的同学。

123. 管理岗位会让人脱离群众，一方面是因为自己心态，认为自己高人一等就会有意无意地忽视别人的意见。如果把各种评审会上的正常争论认为是对自己权威的挑战，对产品更是致命的，久而久之大家甚至都不愿意和你讨论。这个问题还好办，我们学学真正的高手就可以了，他们往往都是很谦虚低调的。另一方面就更致命了，官与民之间总是有隔阂，最明显的现象，我待过的团队，一定有一个全团队的旺旺群，也一定有一个全团队除了主管之外所有人的旺旺群。很多时候大家对一个管理者的观点有异议，也没法像对普通同事一样直接提出，总会在心中先掂量几次，很多可以帮助产品提升的机会就在这些掂量中白白溜走。从这点上看，产品经理不在管理岗位上会比较有利于工作。

124. 这样看来，其实产品经理是不是管理者并不重要，重要的是公司应该创造出一个良好的环境，让上述几点优势可以发扬，劣势可以避免，这样产品经理才能发挥出最大的作用。看到这里，你可能想到了解决办法，其实很多公司都想到了：设计管理、专业两条晋升线路，让优秀的产品经理在专业线路上拥有高级别；对于产品、业务的决策有充分的话语权；可以参与管理会议的业务讨论；可以拥有临时的资源支配权，并给管理层提供同事的考核建议；但不负责管理者的行政工作，而是继续和同事打成一片，用产品证明自己。 这，似乎是一条很好的路。

如何让团队更开心

125. 赠送礼物和激励员工的艺术

126. 大中之小不如小中之大：送礼的时候后，在一个不太昂贵的礼物类别中选择一个比较贵的礼物，要比在一个比较昂贵的礼物类别里选一个比较便宜的礼物收到的效果更好。比如送一条1000块的围巾效果好于送一件1200块的衣服，我们应该尽量找一些高级的小玩意。 有用的不如无用的：最好的礼物应该是吃不掉、用不掉、送不掉也扔不掉的东西。比如有纪念意义的水晶奖杯，刻上他的名字，千万不要是几瓶酒、几条烟，能喝掉、能抽掉、能送掉。 需要的不如想要的：你应该把人们想买却舍不得买或者想买却不好意思买的东西送给别人做礼物或作为奖励。比如5星级酒店1000块一顿的高档餐券，更多的是心理满足感。 有选择不如无选择：奖励或送礼的时候最好不要让接受奖励或礼物的人自己选择。不然的话他会有“我放弃了另外一种选择的感觉，患得患失反而不开心”，经典反例就是：奖励团队“海南游”或每人“现金2000元”。 小奖不如没奖：人们做事往往是出于自己的内在动力，而一旦与奖励挂钩，就变成了一个经济交易，做事的人会开始衡量投入产出的物质性价比，所以给小奖反而不如不给奖。惩罚也是如此，受到小的惩罚后反而会让人感觉心安理得，还不如没有惩罚。 晚说不如早说：在期待的过程中，让员工的快乐最大化，从而增强激励的效果；让朋友在期待的过程中提前享受到礼物所带来的欢愉。比如尽早宣布奖励大家去海南玩，如果可能的话，在项目开始前就给出承诺。 一次送不如两次送：如果你打算给别人两件礼物的话，那么最好分两次给。因为快乐也是边际效用递减的。同样的道理，有很经典的结论：好消息要分两次说，坏消息要一起说，大的好消息与小的坏消息一起说，小的好消息与大的坏消息分开说。 公开不如不公开：工资体系最好还是不公开的好，以避免员工互相比较而心理不平衡，也就不必用涨工资的方式来进行协调了，因此避免了整体工资水平的提高。 涨工资不如发奖金：涨工资不如发奖金给员工带来的快乐大；同时，发奖金有比较大的回旋余地。对于这类物质激励，一般效用期比较短，发奖金是一次性的，涨工资是长期的，涨了就不好降回去，从第二个月开始，激励效果就微乎其微，孰优孰劣一目了然。

127. 奖励或送礼的目的并不是真正给对方最大的效用，而是要让对方开心，并且感激和记住你。

跟着我，有肉吃

“我的产品，我的团队”详图