人人都是产品经理02-07章摘要

7.1从想清楚到做出来

7.1.1原型验证与NPS

POC（Proof of Concept），产品概念测试。
在这一环节，需要用尽量低的成本，做出某种形式的产品原型或Demo，来让用户试用。对于制作原型的工具和方法，网上资料很多， 不再细说，本书重点提一个叫NPS的概念。
NPS（Net Promoter Score）指净推荐值，是一种计量用户将会向其他人推荐某产品可能性的指数。作为一种流行的用户忠诚度分析指标， 它专注于用户口碑，在产品早期验证用户价值时，尤为重要[2] 。

净推荐值的计算公式：
NPS =（推荐者数 – 批评者数）/总样本数×100%

确定净推荐值时，可以直截了当地问用户一个问题：“您是否会愿意将某某产品推荐给您的朋友或者同事？”然后让用户根据愿意推荐的程度，在0到10分之间来打分，最后根据打分情况把用户分为推荐者、 被动者和批评者。
►推荐者： 打分在9～10分之间，是具有狂热忠诚度的人，他们会 继续使用产品并将其引荐给其他人，可以帮助产品成长。
►被动者： 打分在7～8分之间，总体满意但并不狂热，会用但不 会传播，可能考虑其他竞争对手的产品。
►批评者： 打分在0～6分之间，使用后不满意，或者对你的产品没有忠诚度，可能有负面口碑，会阻碍产品成长。 然后，再根据推荐者和批评者的人数来计算NPS的数值。 NPS的得分值在50%以上就已经比较理想，如果达到70%～80%， 则说明产品拥有一批忠实拥趸。而实际情况是，很多产品的NPS值远远 低于50%，甚至是负数。如果你的产品还没有测试过NPS，那么赶紧去 测试一下吧，这个测试永远都不晚。如果分数太低，建议马上把推广甚 至研发生产停下来，回过头来好好想清楚产品定位。产品上市后，NPS 也应该定期测试，以指导后续策略。

7.1.2产品委员会与关键节点

因为资源投入方向要阶段性地做出判断，所以产品委员会要在每 个关键节点召开产品会议。经过筛选，以下四个关键节点是必不可少 的。
1.概念筛选
根据各种背景信息，判断要不要对某个产品概念进行细化、展开。 如果认为可行，就要启动全方位的需求采集工作。这是本书第03章讲的 事情。
2.立项组队
对产品进行原型验证，评估需要投入多少研发生产资源，有多少 险及如何应对等。如果立项获批，就要启动项目、组队开干。这是本章 前半部分的内容。
3.上线发布
产品完成开发后，千万不要因为怕浪费而仓促上线。这时还是要先用真实产品找种子用户验证，如果没有通过验证，就不要上线，以免浪费更多的客服、销售、运营维护资源。
4.营销推广
为提升用户量，上线之后马上就开始推广，也是常见的错误。应该先花一段时间考察用户是否活跃，是否会再次使用产品。当这些指标达到预期后，才可以大力推广，否则就是浪费资源。

在大公司，这四个节点是申请资源的关键节点；
在创业公司，这四个节点是引入外部投资、关键岗位人才的重要节点。产品经理们只有把自己的视野拓宽一下，站在老板或投资人的立场去想想他们到底想要什么，才更容易理解获取资源更有效的途径。接下来讲立项时具体需要搞定哪些资源。

7.2立项：搞定各种资源

7.2.1关于人：团队 组织

一群人到底为什么要聚在一起做一件事情？只有想清楚了这个问题，才能真正搭建一支有战斗力的团队。
我们从组织形成的三种原始动力说起。
权力：强力组织，比如国家政府，用“枪杆子”保证“绳之以法”。
利益：商业组织，比如公司企业，用“钱袋子”支撑“诱之以利”。
共识：松散组织，比如公益社团，用“笔杆子”达成“晓之以理、动之以情”。 这三种原动力，在人类发展的不同阶段，所起的作用也各有不同。 资源匮乏时容易形成暴力组织，随着资源越来越丰富，组织越来越倾向于用利益和共识这些力量来维系。

任何组织的凝聚力都是这三种原动力的混合，只不过配比不同。每一个团队中，也都有不同的人。有的人很职业，在他们的认识里，工作就是工作，接了任务就有义务想方设法完成；有的人则讲求物质回报， 只要钱给足，保证活漂亮；也有的人更看重对团队目标的认可，将其放在首要位置。

随着时代的发展，共识驱动的比例越来越大，而我们也应该努力寻找这样的团队。这是因为，对于权力驱动 的团队，一旦权力不在，团队就散了；而对于利益驱动的团队，一旦利益不在，组织也就没了；只有共识是内生的，不会消失，由其驱动的团 队往往表现为，成员归属感强且彼此信任。为加深体会，可以用以下这 些关键词来描述共识驱动的团队：使命感、责任感、成就感、互信、价 值感、内驱力、自激励。

7.2.2关于物：政策 资金

先比较一下MRD和PRD这两个产品经理最常写的文档。

MRD： Market Requirements Document，市场需求文档，除了描述问题，解释为什么要做这个产品，还要给出解决方案。这个文档比较像产品规划和商业计划书（BP，Business Plan），是写给资源拥有方看的。

PRD： Product Requirements Document，产品需求文档，是在项目过程中写给开发、测试、设计师看的，仔细描述产品功能要怎么做。

7.3组队：聊聊初创团队

7.3.1如何快速知己知彼

不管怎样，事情只要已经开始，就说明已经凑齐了一支看起来可以开干的团队。大家并不是很熟的时候，做起事来总会一团和气，但过一 段时间，每个人都会发现，过程、结果并没有想象得那么美好。于是， 团队进入频繁吵架的阶段，大家都在找合适的当口发泄自己的失望和不满。吵架的原因，往往是一些底层的东西并没有达成一致，导致观念冲突，团队成员之间不信任、不理解、没有默契。当出现这种情况时，就说明有些统一思想的事情漏做了。我们要花最少的时间，让大家感觉到 彼此已经熟识多年，互相很清楚对方想要什么。

大公司里的专业HR可能会更早意识到这一点，然后提醒业务人员。但对于创业团队，只能靠老大自己发现，然后决定团队成员是不是需要聊聊，以及在什么场合下聊。场合很关键，找到一个大家都很想聊聊的场合，是达成默契的第一步。

所以，在团队里比较和谐的场景是，某天下午大家又因为一个具体的业务问题，从讨论逐步发展到争吵，继而开始对彼此的思维模式、做事套路不认同……正当大家精疲力竭的时候，老大问了一句：“晚上都没事吧？一起去吃饭，我请客。”这就是一个良好的开端。

在非工作时间、非工作地点 ，沟通更容易敞开。这时候可以一起聊这样几个方面的话题，每个人都要发言。
► 为什么要来这个团队？
► 对一年后收获的底线预期。
► 个人对团队的帮助。
► 自己能做什么？
► 自己想做什么？
► 项目失败最可能的原因是什么？

批评与自我批评的意图是继续暴露问题，因此前提是沟通气氛到 位，才可以继续聊这个话题。

7.3.3小团队与大公司的区别

以下是我在知乎上对“在大公司和小公司做产品经理有哪些异同点？”的回答。

2014.12月，一个小的创业项目启动，我作为创始人，完整体验了 从0开始的全过程。2015.1月，基本上我是团队的产品、运营、商务、 测试……把体会给大家分享一下。
大公司： 写规划，过规划——老板那边又没过，郁闷。
小公司： 没人管，自己决定做什么。谁来告诉我这么做到底对不对？有人来喷喷也好啊，但找喷都是要钱的（至少得请人吃顿饭吧）。

大公司： 竞品分析——那个谁谁也做了类似的东西吗？——没事，我大××怕过谁，灭了他。
小公司： 那个谁谁也做了类似的东西吗，大公司？额，怎么避开 他……小公司？找他聊聊，看有没有合作的可能。

大公司： 用户研究——申请用研团队的资源，输入目的，拿到报告。
小公司： 直接约人吃饭、喝咖啡、聊天；隔两天，继续约人吃饭、喝咖啡、聊天。所以，只能做一件身边有很多目标用户的事儿。

大公司： 评优先级——最好我提出来的都是最高优先级的，把别人的需求PK掉，哈哈哈。
小公司： 没有“别人”，先做哪个自己说了算，但反而要更认真地 想——能不能再砍一点，再砍一点，特别心疼开发在没那么重要的功能 上花时间，越是能低成本验证的成功率越大。

大公司： 需求文档——按模板写啊，谁知道这次分配到哪位来开 发……
小公司： 自由流太爽了——和开发确认一下能不能看懂就行—— 用Excel写逻辑，用Visio画图，用Axure做示意Demo，完事儿。

大公司： 老板给的开发资源不够啊——走，吵架去。
小公司： 算算现在几个全职，几个兼职，开销多少，再加人一个 月又要多几万块成本——更充分地体会到“时间就是金钱”——都是资源，容我纠结一下……

大公司： 怎么还有这种低级Bug，测试干什么吃的。
小公司： 自己测，大家一起测——总是担惊受怕，觉得测得不完整，漏了什么。你问为啥不找个测试？产品早期，能省就省……

大公司： 需求变更——发现一个地方可以简单优化一下，可能要走流程什么的，最快两三个礼拜吧。
小公司： 如图7-2所示，我发现了一个小问题，提给客户端同学； 正在讨论方案的同时，服务器端同学已经把问题改掉了，几分钟解决。

大公司： 产品数据不好看（但也是以“万”为单位），找运营聊聊，再搞点流量。
小公司： 自己琢磨用户和内容，怎么零成本冷启动，找各种资料补课。

大公司： 团队组建，产品1人，设计2人，技术5人，测试2人，运营2人…… 小公司： 比例一样，只不过是——产品0.3人，设计0.3人，技术1.5 人，测试0.2人，运营0.2人……有零有整是因为有兼职同学，或者有人是劈成几个岗位来用的。

大公司： 参加聚会，别人过来搭讪，你们正在做什么呢？
小公司： 只参加“有用”的聚会，目的性特别强地去主动搭讪—— 嗨，我们正在做什么什么。

大公司： 上班上知乎，偷个闲，嘿嘿嘿。
小公司： 连回答这个问题都是有潜在目的的，比如说为了招人……

大公司： 睡觉前想想，今天没干什么又收入几百块。
小公司： 睡觉前想想，今天没干什么又花了几千块。

现在，有些大公司也在尝试着内部分解，分出很多的小团队来运作，以获取两种状态下的优势。不管你们现在处于哪种状态，都应该好 好享受、珍惜，互帮互助、祝福彼此。

7.3.4借助第三方力量做产品

缺钱怎么办？旧模式下就是募资。缺人怎么办？旧模式下就是招人。对于这种比较传统、比较重的模式，其问题在于，资源往往只能优先满足最优秀的公司，很多新的、还没什么名气的团队很难搞定。这时，可以尝试一下新模式。
新模式下应对缺钱的方案是众筹，应对缺人的方案是众包。这里重点讲讲众包。

我认为，众包服务又分两类。
1.一类是帮助现有的人节省时间，通常是借助工具，还有一类是借助外面的人力。 前者，比如做项目管理，本来要花技术负责人20%的时间，现在可以借助项目管理的工具，省掉部分精力，再如要给App加一个客服功能模块，可以借助第三方组件，几行代码搞定。现在各种技术服务已经非常发达了，磨刀不误砍柴工，准备撸起袖子做一件事之前，多研究一下市场上是不是已经有现成的服务。初创团队千万不要重复造轮子，条件允许最好花钱买时间。

2.再说说借助外面的人力。这其实是一个知识经验领域共享经济的概念。将来的公司和个人的关系，一定比现在更加灵活。个人不再是公司的附庸，公司反而变成了个人的平台。在用人上，越来越多的公司会认可“为我所有不如为我所用”的理念。

这种人才的专业能力众包，又可以分成四个层面。
►第一个层面：分享 ，就是我说你听，借的力只是一个想法和做 法，我并没有帮你做事，而且针对性也不是很强。
►第二个层面：座谈 ，可以有针对性地进行讨论，给出一些有针 对性的建议。
►第三个层面：咨询 ，给你指导，带着你做。
►第四个层面：外包 ，直接上手，帮你搞定。

7.4研发生产时我们做什么

简单地讲，原型验证完成、产品委员会评审通过以后，要经历立项、需求、开发、测试、发布几大环节，然后再拿着做出来的产品找用户验证，最后做项目总结。

►立项环节
►需求环节
►开发环节
►测试环节
►发布环节

7.4.2如何做一个让Ta们讨厌的人

1.开始实施之前
►不说清需求价值。
►不去想功能细节。
►帮技术评估工作量。
►逼着技术团队承诺。

2.实施过程之中
►做了一半改需求。
►开发过程中消失。
►过度关注实现细节。
►发布后没有反馈。
►任务无节奏感。

3.全程适用
►优柔寡断无决断。
►报喜不报忧。
►不要把他们当人。

以上内容正话反说，希望能对大家有所触动。当然，所有配合顺畅的大前提是，每个人在自己的岗位上都要专业靠谱。