概论

前言

人人都是产品经理

为了做好网站，我觉得自己还是有必要阅读一下这本书。

这本书出版已经有很长时间了，书中提到很多有参考价值的内容。

比如投资界常用的方法：

其次，投资人给钱时，不同轮次的关注点不同。基本上，种子轮只看团队，只要团队靠谱，就算还没确定方向，拿个几十万到一两百万人民币是没问题的。天使轮，就要看产品了，产品做出来且通过了早期的用户验证，就能拿到大几百万到一两千万人民币，可以用于继续发展。投资业内有个说法，大公司里出来的，或者已经有过靠谱创业经历的明星创业者，刷脸就能拿两轮，说的就是种子轮和天使轮。再往后，产品进入市场运营、销售及品牌积累阶段，就要看数据增长、能否找到商业模式、收入、赢利、市场份额等这些指标和因素，这时候再拿钱就是ABC轮等。所以，作为一个创业者，在早期最需要关注的是团队和产品。

……

还在阿里时，我就拜访过不少投资人，他们挑选早期项目的普遍原则是——先看人，后看项目。因为项目做着做着就会变，而人的能力是实打实的。君不见，知名天使投资人投的项目，团队核心成员都是星光闪闪的人物——大公司高管、海龟、名校、有成功经历……而在内部，来赛马的多为基层员工，换言之都是那些手里没资源的人。但凡有点资源的，也不用通过赛马这样的通道来实现想法。这样的选手和团队，创业成功的概率更低。

书中还谈了「产品经理要不要懂技术」，作者认为要懂基本的技术，要达到和技术人员沟通基本无障碍的地步。

产品设计需要有PRD、MRD，而产品需要有MVP。我们需要「省时间的低成本验证」。书中提到了一个利用公关手段的例子：

再来一个案例，假设你想做一个垂直领域的导航站。

这个站点可以告诉创业者，创业过程中都会碰到哪些问题，可以用哪些服务解决，可以去什么站点获取资讯。我的建议是，先不要做网站，而是把精心整理的各种资料，通过一篇高质量的文章来传播，收集阅读、收藏、转发的数据，或者挑一些目标用户来问问反馈，再决定下一步怎么做。

最后来说一种有趣的低成本验证方法——利用公关手段。

经常看到阿里PR稿件中出现“阿里又要推出×××”“阿里开始进军×××”“阿里正在秘密研发×××”这样的标题，而这很多时候都是有意为之的小动作，甚至产品、技术团队都毫不知情，更谈不上真正开始投入资源了。而很多对手会被带到沟里，开始研究对策、排兵布阵。

大机构想推出新政策的时候，先借助合适之人如专家的嘴，或其他渠道如非官方媒体、小道消息等来透露给社会大众，试探他们的反应，得到相应的结果后，或顺水推舟地证实，或矢口否认地辟谣。不用担心最终没做会辜负期待，用户总是很健忘。回顾一下以往的新闻，能想到很多这样的例子。

广义的公关之法，其本质就是先不做，却告诉受众我已经做了，从而收集反馈，其优势在于成本非常低，验证非常高效。

小结一下，低成本验证的核心，就是看谁能用更少的资源、时间等成本，拿到一些假设是否成立的结论，而更深层次的目的，还是为了更好地服务用户，更好地达成公司的商业目标。

书中认为运营和产品同样重要，要按照实际情况分配职权。

不管你是产品经理还是非产品经理，即使你把这本书的内容全忘了，也希望你还是能记住这一句话，一句需要每天不断念叨的话：

用心听，但不要照着做。

这在社会治理上也同样适用。很多「需求」就是纯纯许愿——找个全能神满足自己所有的愿望，这样显然不符合「为仁由己，而由人乎哉」和「政者正也」的道理。

书籍简介

作者: 苏杰

出版社: 电子工业出版社

出品方: 博文视点

出版年: 2017-6

页数: 352

定价: 66.60

装帧: 平装

ISBN: 9787121313523

内容简介

《人人都是产品经理——写给产品新人》为经典畅销书《人人都是产品经理》的内容升级版本，和《人人都是产品经理2.0——写给泛产品经理》相当于上下册的关系。对于大量成长起来的优秀互联网产品经理、众多想投身产品工作的其他岗位从业者，以及更多有志从事这一职业的学生而言，这《人人都是产品经理——写给产品新人》曾是他们记忆深刻的启蒙读物、思想基石和行动手册。作者以分享经历与体会为出发点，以“朋友间聊聊如何做产品”的语气，将自己数年产品工作过程中学到的思维方法与做事方式，及其它们对自己的帮助，系统性地梳理为用户、需求、项目、团队、战略、修养几大话题，完整而生动地回答了“我们为什么而做”、“在做什么事，解决什么人的什么问题”、“何时，和谁一起做”、“需要什么能力”等人人都要面对的核心问题。

《人人都是产品经理——写给产品新人》面向“−1到3岁的产品经理”，既有知识与方法，也有流程与实战，更有感悟与思考，适合刚入门的产品经理、产品规划师、需求分析师，以及用户体验、市场运营、技术部门的朋友，特别是互联网、软件行业的上述人群，也同样适合对做产品感兴趣的学生。

作者简介 

苏杰，浙江大学硕士，2006年毕业加入阿里巴巴集团，一直担任产品经理至今。从2007年开始，作者每周记录自己在工作中的体会，直至2009年夏，积累近20万字，整理大半年以为此书。2012年6月，本书升级为1.1版。

作者现在主要负责产品的战略规划、业务架构、数据分析、用户体验，等等，并于2009年开始负责公司内产品经理入门的培训。

正文摘录

自序

下面简单说说这五本书的逻辑。

《人人都是产品经理》，是新手产品经理的方法论，适合-1岁到1岁的产品经理。2010年出版第1版，业内不少已经很优秀的产品经理，跟我说“是看这本书长大的”，我表示很无语。2012年出版V1.1.2014　年出版V1.2（也叫纪念版），截止2016年年底，实体书销售超20万本，不算正版和盗版的电子书。

《启示录：打造用户喜爱的产品》是做产品的高阶方法论，作者Marty有20多年的产品经验，适合产品管理者或资深的产品经理阅读。如果你认为上面那本太初级、太局限，那这本书就最适合你了。于2011年翻译引进，今天看依然不过时。

《四步创业法》是一本在国内被严重低估的书，2012年引进，其实这才是硅谷的创业圣经。《精益创业》的作者是《四步创业法》作者的学生和忠实信徒，李开复老师也推荐过它，如图3所示。做产品久了会发现，产品和创业的方法论其实很像，只是创业更难。在创业的方法论中，我们能学到很多对产品经理有用的东西。

《淘宝十年产品事》是一本案例集，正好于2013年淘宝成立十周年的时候出版。淘宝系产品的复杂度和多样性，可以说是国内互联网行业20年来独此一家，从前台到后台，从2B（to Business）到2C（to Customer），从Web到App，不一而足。产品经理成长到一定阶段，再看方法论已经作用不大，只能通过案例来提升。自己犯错后的成长最扎实。比如，早在2008年，阿里和微软合作的一个项目上，我就花掉了公司1000多万人民币的项目经费，这种机会不是每个人都能有的，所以通过别人的案例来学习会更加高效。

《有的放矢》于2014年引进，它更加适合2014年开始的略显癫狂的全民创业时代。全书只讲了一件事情——创业、做产品的过程中，怎样可以有的放矢，不做无用功，不浪费各种资源。不管你何时读到这里，都不妨回忆一下自己去年这个时候在做什么。是不是很多事情，如果当时不做，对现在的自己和公司也没有任何影响？再回忆一下，三年前红红火火的创业公司，是否绝大多数已经销声匿迹？如果你的回答是肯定的，那么这本书就能帮到你。

2015年到2016年，我把它们的精华合并在了一起，开发了一门课程，叫“互联网产品的从无到有”，给不少大小公司、机构、大会分享过，借这些机会也接触到不少新的案例、理解了一些方法论的局限性，愈发感觉有必要好好整理一下。

第00章 开始：写在正文之前

0.1 为什么会有这本书

0.2 本书的产品定位

0.3 本书内容与阅读方法

2014年，我第一次接触了“视觉引导”的概念，感到十分受用，在深入了解之后，更是充分体会到图形与文字在认知上的互相促进。在这个时代，感性与理性同等重要。所以，本书的大框架和每一章的要点，都会采用图0-2所示的这种图形化的方式来表达，希望大家喜欢[5] 。

本书从人开始，以人结束，中间说事，以一个产品从无到有的过程为框架——想清楚、做出来、推出去，外加一章综合案例。其中，最重要的想清楚、做出来、推出去，对应着互联网公司里三个最核心的岗位——产品、技术、运营，而本书的内容重点，则对应着“产品”。

接下来简单介绍一下各章的主要内容。

00 开始：写在正文之前

让用户了解本书的定位、整体架构和内容、阅读方法、局限性，以便更好地决定是否要花时间读下去。

01 初识：大话产品经理

介绍产品经理这个岗位的前世今生。从社会发展的角度，讨论这个岗位为何会出现，又会往哪里发展。然后，谈谈产品经理的思维方式与性格特点，以便读者进行自我判断：自己是否合适以此为业，需要做哪些改变。最后，聊聊产品经理如何入行、典型任务，以及身边的团队。

02 产品：关键词与分类

了解了产品经理这群人，再来看看他们做的产品应该怎么定义。世界上的产品多如牛毛，哪怕只是互联网行业里的产品也都已是千奇百怪。为了更清晰地理解它们，本书试着从多个角度，比如用户关系、用户需求、用户类型、产品形态等方面对产品进行分类，希望读者看完以后可以想清楚自己喜欢、适合做什么样的产品。

03 概念：提出与筛选

如何找到一个真正的机会？这不仅仅是灵光一现的idea，还要想清楚核心用户、刚性需求、典型场景和竞争优势。然后，从团队的能力与意愿、外部的价值与机会、成本与风险等多方面来衡量，这到底是不是一件值得继续做下去的事情。

04 需求：采集与用户研究

做产品就是解决问题，我们知道要对解决方案精雕细琢，但在“问题到底是什么”上花费的时间总是太少。本章，会讲解收集信息的各种方法以及各自的优劣。随着信息的逐渐充分，将会理解需求的三种深度，以及用户从抽象到具象再到抽象的过程。同时，也可以试着理解一些概念——用户故事、人物角色、产品原则。

05 转化：需求分析与Y模型

用心听，但不要照着做。本书认为这句话是产品经理思维方式和做事方法里最核心的一点，Y模型就是这句话的具体操作方法。本章将通过各种案例，从表面的用户观点、行为，到动机与目标，再到人性与价值观对需求进行讲解。了解需求的本质以后，又该如何从用户需求的角度匹配出合适的产品功能，让用户满意而归，这些都本章的重点。

06 功能：细化与打包

从用户需求推导出产品功能之后，到底做不做，还要看功能的价值高低、成本大小，以及类别归属。确定了实现的先后顺序，接着就要决定“下一个版本”到底做多少，这取决于很多因素。这个过程，也引出了需求与功能管理的话题，至此，“想清楚”大模块结束。

07 执行：立项组队与研发生产

从这章开始进入“做出来”的模块。首先会拿到各种资源，简单地讲就是“人和物”，其中团队又是最最关键的。在研发生产阶段，作为产品经理，对设计、开发、测试、运维等岗位的工作内容，多少得有些了解，才能做到顺畅配合。

08 成长：规划与迭代

产品的1.0上市，不是结束，而是开始。任何一个好产品都是慢慢变好的。本章将加入时间维度，聊聊规划与迭代这两个词的异同。二者都有一步步来的意思，实则有着截然相反的方法论内核。具体怎么做，本章会给大家讲一些真实的案例，作为“做出来”的收尾。

09 运营：先验证再扩张

一个产品做出来了，如果没人用就相当于零，所以还要“推出去”。本章将会聊聊产品与运营这对“死敌”，希望借此化干戈为玉帛。对于运营来说，不同的产品阶段有不同的目标和手法，验证、爆发、平台、衰退……方法错了，可能“彼之蜜糖，吾之砒霜”。至此，我们前面详细后面粗略地聊完了产品的整个生命周期。

10 创新：商业模式与行业

本章从模式、创新的角度综合来聊“整个产品”，教大家一个理解“行业如何运作”的小方法，谈谈各类型的公司在做创新时都会碰到什么坑。最后，谈几个作者感兴趣的行业，作为案例来提升大家的商业感觉。

11 蜕变：从产品助理到CEO

终于又回到人的话题：如何从一个菜鸟长成一个高手？本书把产品经理分成了7个层级。总有一天，大家都可能都不再做产品经理了，那么，我们的归宿是什么？最后，将本书的方法论进行升华：为什么它有可能成为对个人生活态度以及整个社会进步的推动力？

12 结束：写在正文之后

全书的最后，给出一些周边资源——盘点了十年来国内作者写的产品相关的图书，介绍了作为本书延伸的“读书会”，并列出更多可以去学习的资料，希望对大家有所帮助。

阅读本书，可以先浏览一下全书和每章的视觉引导图，对整体内容有个感性的认识。不一定需要按章节顺序阅读，大家可以根据每章的内容，结合当前工作的需要，自主挑选主题来阅读。在每一章最后，会根据本章主题，提供更多的阅读材料。

对于已经在做产品经理的读者，建议可以先读一下第11章，这样可以判断出自己目前的位置，从而更清楚接下来的努力重点。对于广义的创业者，可以先读一下第10章，特别是关于创新各种坑的内容，避免在上路之前就埋下隐患。对于想了解产品经理核心思维的人，建议先读第05章，了解“Y模型”这个通用的解决问题思路。

每一章的最后，还会布置几个任务，都是一些有实际作用，应该做，但很可能忙于日常事务而一直没做的事情，希望你能补上。

当你读完本书的全部或部分章节时，可以再看看对应章节的视觉引导图，建立起自己的知识地图，以便需要的时候可以更快地找到相关内容。

最后，再说说这本书的内容与《人人都是产品经理》V1.X版本的关系——是升级，但不是替代，有点儿像上下册，表现为以下几点：

第一， V1.X版本是以“从新人到老鸟的个人成长 ”为章节顺序，本书是以“从无到有的产品生长 ”为内容框架。

第二， V1.X里提到的很多细节，多为一个产品新人工作中每天的任务，本书中不再赘述。

第三， 本书也说了一些V1.X中没有的内容，比如创新、创业、小公司的做法、行业案例，等等。

所以，一定要区分定位的话，V1.X更合适初入职场的产品经理，有励志作用，更偏实操，涉及更多做事方法。是道法术的术。本书更适合自认为是“产品新人”的职场老人，更偏理念，涉及更多思维方法是道法术中的法，适合想了解怎么做产品的“泛产品经理”。

0.4 我与本书的局限性

第01章 初识：大话产品经理

1.1 从一个小故事谈起

这是我在知乎上获得最多赞的一个回答。没有字，只有一张网上找来的图，如图1-1[1] 。

问：什么是“伪需求”？能否举例说明？

时隔多年，我觉得不应该光抖机灵，还要来点有用的。

宾馆大爷的故事，其实在工作生活中经常发生——这个大爷，就是产品经理；这家宾馆，就是一个产品；而学生们，就是用户。不合格的产品经理处处可见，他们共同创造了一个可怕的世界。那么，这个例子中到底有哪些坑？

产品定位阶段

原来的定位是宾馆，因为几个用户的只言片语，直接修改定位，意味着进入完全不熟悉的市场，原来的竞争对手是其他宾馆、酒店，现在变成了学校里的图书馆、自习室。

需求采集阶段

各种方法要灵活应用，比如“不但要听用户怎么说，还要看用户怎么做”。此外，我们也经常提到，要看需求的普遍性，以及有没有特定时间、特定人群。不能用户说什么我们都满足。

需求转化阶段

从用户需求到产品功能，不能直接照着用户说的做，而要分析用户的目标。这依赖于领域知识和对目标用户的理解——从其“观点”、“行为”到其“目标”、“动机”。产品经理和用户通常不是一种人，这很考验“同理心”。

产品概念验证

即使自认为已想清楚新功能，在动手开发前，还是要再找几个用户沟通一下。还要注意方式方法，比如可以问用户：如果我们这里有自习室，你会推荐同学来学习吗？

新功能上线时

多使用灰度测试。简单地说，就是建议大爷不要一下子把整个宾馆都改成自习室，先改个一两间，看看市场反馈好不好。而且，上新功能时，也没必要把旧功能去掉。

人人都爱出主意，类似“用户提出的解决方案”这种伪需求是实践中的常态，而本例中“用户为了掩盖真实目的而欺骗”的情况反倒不是很多。作为产品经理，在面对这样的场景时，就需要找到这个用户提出解决方案背后要解决的问题，然后给出自己的方案。这就是产品经理思维方式和做事方法的核心：“用心听，但不要照着做 ”，说起来简单，但做起来并不容易。

1.2 产品经理的前世今生

1.3 思维方式与性格特点

1.4 产品经理的日常

看了这些性格加分项，如果你觉得“说得就是我啊”，那么我们就接着聊产品经理的日常，看看是不是你想要的生活。

1.4.1 　入行，社招与校招

这一节聊聊入行的话题，再给大家一个做产品的理由——这是个很难被机器替代的工作。

世上的学科，可以分成两大类：科学和人文。

科学的认知对象是“自然世界”，人文的认知对象是“人类经验”。我们经常听说，最厉害的产品经理要“站在科技与人文的交叉口”。这个交叉口是什么？其实就是广义的设计，其认知对象是“人造世界”，即用人类经验改造自然世界。

这里的广义设计，仅仅在日常所接触的工作中，就包含了产品经理、技术开发、设计师等很多岗位，而一线客服、销售、售后服务就很显然不是这种岗位。设计出人工世界、人造物，其实就是创新。由于真正会“设计”的机器还没有，所以这是一种安全的职业。

回到招聘和应聘，无非是找到事和人的匹配，你是否顶着“产品经理”的名号反而不重要了。

事：要我做的任务。对公司来说，想清楚业务是根本。

人：要具备的能力。为了做任务，需要具备什么知识、技能、态度。

我们可以根据招聘启事，总结出大家想要的是什么样的产品经理。不同层级、不同产品、不同任务侧重、不同团队的实际情况都会不同。建议想入行的同学可以去做一做“产品经理招聘启事”的分析报告，也算是练习一下“市场调研”的基本功。此外，校招、社招也有很大区别，前者是储备培养，后者是立刻干活，二者的搭配体现了长短期价值的平衡。

说一说校招面试时常问的一些问题吧，可以根据具体对话展开细节问答。

你是怎么准备这次面试的？

如果你是面试官，怎么处理霸王面的人？

对于简历有多页的人，会问，你的简历如果简化为一页，你打算删掉哪些模块，为什么？

经常用互联网产品吗？举几个例子。最常用的一个是什么？假设你是它的产品经理，你觉得它主要有哪几类用户？说说这些用户的优先级及其原因。你自己是哪一类？通常都用哪些功能？描述几个让你不爽的场景。怎么改进？你觉得他们为什么没这样改？

……

其实原则很简单，就是想办法问到一些面试者没法准备的问题，然后看对方解决问题的思路。

潜力怎么判断？几年前我不知道，但是现在有一点感觉。

只有一条的话：激情，即意愿 。

对某个领域的激情是能看出来的，不是说出来的。其实不在乎你怎么想，而要看你做了什么。比如，你说想做移动社交，可能要看看你的手机，能拿出来几个，都是什么系统和版本号，装了哪些相关的App，甚至还要看看里面的操作痕迹。是否是为了面试这两天才注册的……

更进一步地，“做过什么”是指“输出”而不是“输入”。诸如看过什么书，平时逛什么网站等，都是输入，而写过一些言之有物的文章，做过一些哪怕很小的Demo，都算输出。

再加一条的话：会不会学习，即能力 。

需要某件坚持做并达到一定水平的事情来证明，健身达人、境外游达人等都可以。要讲点能体现专业性的东西——任何领域，达到准专业水平都需要一些相似的素质，比如韧性与坚持、合理的方法论等。只说不练的不算，如果以上这些潜能在应聘者身上都没有发现，那就只能看已有成就了，比如名校、GPA高这些最简单的表征。

所以，对于面试，其实没什么可准备的。因为如上面所说，好的面试官会努力排除“准备是否充分”的影响，考察你过去很长时间的真实情况，而不是只依赖于面试的几十分钟。对我来说，如果你在网络上有些痕迹，比如知乎，会加分。

而对于社招，主要就是看候选人是否匹配当前岗位了，比如，有没有做过类似的产品，经手的产品有没有取得不错的成绩。找到一位合适的人要碰运气，可以去你的竞品那里找，去你认可的产品那里找，或去你认可的人那里找……

对于招人相关的话题，在第07章“立项组队”的话题里还会再说。当然，你也可以选择不顶着产品经理的Title，做产品经理的事，下面，就看一下产品经理都要做些什么吧。

1.4.2 　一天里的典型任务

显然，一个产品经理不可能同时做这么多事情，需要分阶段、分任务类型。最开始是产品的定义与架构，然后是产品设计，接着做出来，最后推出去，这个过程逐渐发展成四个可能的发展方向。

►产品架构 ：定义、规划产品，确定产品定位，规划、把握产品的节奏，对产品进行宏观把控，对经验要求较高。

►产品设计 ：负责产品细节设计。2C的产品，需要和交互设计紧密配合，注重用户体验；对于海量用户的产品，细节设计会产生很大价值（腾讯就是这个方面的典范），但职业天花板相对低；2B的产品，主要是业务逻辑、流程、规则的设计。

►产品管理 ：狭义的管理，偏资源协调、跟进实施和团队建设，有点像项目管理，负责把产品做出来。

►产品运营 ：负责产品大运营，解决产品“有人用”的问题，建立产品与用户的通路，负责营销推广。

一个产品经理能做到四项都强最好，这样可以节省巨大的沟通、管理成本，但培养这样的一个神，至少需要十几年。所以，在国外，常常看到一些40岁左右的产品经理，他们确实是能大包大揽的“真·产品经理”。而国内互联网行业以及产品经理岗位，发展时间还很不够，这种人至少要5～10年后才可能成批出现。现在，这批人就是行业里的CEO，他们根据实际情况来分权，带领几个各有擅长的产品经理，甚至把部分任务分给技术、设计这类“泛产品经理”，从而完成整件事情。大家也可以考虑自己擅长哪方面，根据公司需要和个人兴趣选择发展方向。

1.5 延伸阅读与练习

第02章 产品：关键词与分类

2.1 产品：解决某个问题的东西

“问题”包含了三个关键词：用户、需求、场景，分别用来讲述一个重要的概念。

►用户： 这个问题是谁的问题。

►需求： 问题的核心是什么。

►场景： 用户在什么情况，以及何时何地碰到这个问题。

接下来，对这三个词展开详述，这是任何一个产品人都需要掌握的最核心的概念。

2.2 常见的产品分类维度

从产品与用户的关系角度，分为三类：单点、单边、多边，其中多边又可以分为双边、三边等。下面各举一例以方便理解。

先说结论，从用户需求角度，把产品分为6大类：工具、内容、社交、交易、平台、游戏。但必须提前说明，这个分类的界限并没有那么严格，很多产品是多个分类的混合体。

2.3 延伸阅读与练习

第03章 概念：提出与筛选

3.1 产品概念的提出

提出产品概念很简单，要确定五个关键要素，参见图3-1：

►核心用户： 产品目标用户中最重要的用户是谁，表达为一个抽象的人群。

►刚性需求： Ta们碰到最痛的痛点是什么。

►典型场景： 这些痛点最常出现在怎样的生活、工作情况下。

►产品概念： 用什么方案解决，用一个词、最多一句话概括你的解决方案。

►竞争优势： 相对已有方案，有什么突出优势。

以上的五个要素，就是产品的“切入点”（并不是完整的产品），下面一条条来讲述。通过前三个要素，可以顺便加深对第02章说的“用户”、“需求”、“场景”的理解。

……

任何一种用户的需求都有很多，其中最重要的那些，叫作刚性需求。

刚性需求要满足下面三个条件：真实、刚需、高频 。

►真实：需求是真的存在，还是幻想出来的。 我们要对需求的真伪做一个判断。经常听到用户说的可能都是一些伪需求，比如用户说“我希望能做到每天早起锻炼身体，你这个App能不能每天提醒我”，你真的做给他了，他可能懒得用，如果用户有心要锻炼，这是个闹钟可以解决的问题，如果无心，再提醒也白搭。

►刚需：特指需求是否强烈，不满足能否忍受。 一些需求到底是不是很刚性，其实很难说。举个例子，要在很繁华的闹市区停车的话，可能更刚需的是要找一个车位，毕竟绕了20分钟停不下来实在受不了，相对弹性一点的可能是省停车费，能省点最好，实在省不了也就忍了，这是是否刚性的区别。

►高频，需求发生的频次是高是低。 这比较容易理解，有的需求发生的频次可能每天都有，比如叫外卖，有的需求发生的频次可能一年才有一次，比如春运。有些需求2C低频，但2B就高频了，可以通过服务B来化解，比如家庭日常水电维修，对每家每户来说肯定是低频，但可以尝试作为小区物业的服务提供商。

同时满足以上三点很难，所以要综合考虑，满足刚性需求要优先于弹性需求。

3.2 概念提出的综合案例

3.3 产品概念的筛选

3.4 概念筛选的综合案例

3.5 延伸阅读与练习

第04章 需求：采集与用户研究

4.1 需求采集方法的分类

4.2 一些实用的采集方法

4.3 用户、需求的再理解

4.4 产品原则与初心

4.5 延伸阅读与练习

第05章 转化：需求分析与Y 模型

5.1 从问题到解决方案

前两章提出并筛选了产品概念，采集了需求，研究了用户，随着信息收集得越来越多，对各种“用户需求场景”也理解得越来越透彻。这一章要开始琢磨解决方案了。

几年前读马斯洛的《动机与人格》时，发现有一章专门在谈论“问题”与“方法（解决方案）”这两个词。书中最难理解的地方，也许就在于“问题中心（Problem Centering）”与“方法中心（Means Centering）”这两个概念，这需要我们一起来理解和思考。

下面列出了产品经理们工作中常见的一些疑问：

a）PRD怎么写，给我个模板吧？

b）写PRD是什么目的，给谁看，要对方了解什么？

c）最优的团队组织结构应该怎样？

d）我们的团队做现在这个产品，需要哪些能力，谁有这样的能力？

e）我们应该用什么流程？

f）现在的流程会出什么问题？如果出问题怎么解决？

进一步分析可知，上面的问题可分为两类：a、c、e问，是典型的方法中心，而b、d、f问，是典型的问题中心。二者的区分可以概括为：方法是手段，问题是目的。而新手产品经理常犯的错误，就是过于重视方法，或过于忽视问题。

问题中心是“手里拿着钉子，看什么都是锤子”，更多思考“问题”相关的事情。如果你对任何问题的解决方案都能信手拈来， 已达到“手里无锤，飞花落叶皆可为锤”的产品高手境界，那么的确可以只关注问题本身。方法中心是“手里拿着锤子，看什么都是钉子”，更多思考“解决方案”相关的事情。如果你真的打造出“雷神之锤”，可以用来解决任何问题，那你的产品需求解决能力确实也可以天下无敌。

从“问题中心”的思路出发，只要能搞定问题，用什么方法就不再是最重要的事情。比如，旺旺对话框里的计算器，调用的是Windows的自带功能，从技术角度来看这一解决方案非常简陋，但的确能实实在在地满足买家、卖家沟通时讨价还价的现实需求，可以视为“问题中心”的成功典范。

从“方法中心”的思路出发，方法本身就是核心追求，至于这个方法究竟能解决哪些问题，可以暂不考虑。比如有些业内顶尖的公司，早在5年前就成立了研究人工智能的实验室，当时只是基于对未来趋势的预判，并不知道研究成果能用在哪里，但大家心里清楚，等数据量积累足够多、计算能力足够强、算法足够厉害之后，总能找到应用场景。

长久以来，国内的教育导向都是强调方法而忽视问题。而从事产品经理这个工作，可以让我们渐渐学会在两者之间找到平衡，正好对传统教育的负面影响起到一定的纠偏作用。比如前两章对应于产品经理的工作，就是分析问题。在一个团队中，技术人员的思维侧重方法中心，业务人员的思维侧重问题中心，而产品人员则要融合这两种思维——需要先“问题中心”，尽快找到“用户需求”，回答Why和What；然后“方法中心”，最终设计出“产品功能”来回答How。

本章仔细聊一聊从问题到解决方案的转化过程。

5.2 Y 模型的基本概念

5.3 实战中如何深入浅出

向各种游戏学“引人入胜”

游戏的产品元素，有三点很值得学习。

► Badge ：勋章和等级，表示玩家过往的成就。

► Point：积分和经验值，代表你现在的状态。

► Leaderboard：排行榜，指引你未来努力的方向。

很多非游戏产品，也借鉴了上述元素。比如社区，就有很多勋章和积分的应用。对于用户的各种行为，如果是社区鼓励的，就加分，是社区不喜欢的，就减分。再将分数与勋章关联，然后明确告诉用户，现在拥有勋章的权限，可以进行什么操作，不可以进行什么操作。游戏化，是很多产品的高级玩法，对这个话题感兴趣的，可以去看一本叫《游戏改变世界》的书。

除此之外，还可以向传销发展下线的手段学激励机制；向一些社交类应用学美好的交互细节；向含线下部分的产品学如何设计标准的用户服务流程；向各种针对VIP用户的产品学如何营造尊贵感，等等。所以，作为产品经理就得不停地看和用各种产品。只有这样，最终才能把已有的东西重新组合在一起，加上自己的一点点灵感，形成一个全新的产品。至于最终成果是创新，还是四不像，留给用户来检阅就可以了。

5.4 一些综合案例

5.5 Y 模型的更多理解

5.6 延伸阅读与练习

第06章 功能：细化与打包

6.1 一个功能的DNA

俗话说，产品经理推动工程师实现功能有三宝：竞品已搞，老板想要，开发量小。如果不行，再上杀招，求求你了好不好。

实际工作中，当然不能这么玩。第05章中用Y模型做完了需求分析，从一堆用户需求中推导出很多产品功能，接下来，要回答Which（做哪个）和How many（这次做多少）这两个问题。

在本章中，主要展开说三点：价值评估（表中的“商业价值”）、成本评估（表中的“开发量”）和功能分类（表中的“分类”）。

更进一步可以总结出以下两点：

►价值由产品功能背后的用户需求（问题）决定。

►成本由产品功能（解决方案）决定。

实现成本低，或者对应需求的价值高，这两个条件中的任一个，都不能单独作为决定去实现一个功能的理由。必须结合这两个条件，综合考量功能的性价比。理论上，性价比高的功能优先级也就高，应该先做。

性价比 = 价值/成本

不过在实际操作中，还需要考虑功能的分类，在本章的功能分类部分，会仔细分析不同种类功能各自的应对策略。

6.1.1 　功能的价值判断

接下来介绍图6-1中三个功能价值评判的基础原则。

广度：潜在用户数 *单用户价值

简单来讲，广度对应着潜在用户数，即一个产品将来可能覆盖的用户群体有多大。不同产品、不同功能的定位，直接决定其可能覆盖的潜在用户数会有差异，有时甚至相差一个或多个量级。

同样是面向出行这一需求，如果是打车应用，覆盖的潜在用户数可能是几个亿，如果是代驾应用，因为要求用户有车且没法开，可能覆盖的潜在用户数最多只有几百万，二者相差两个量级。同样是餐饮服务，日常快餐和只接婚宴，潜在用户数的差距也很大。

同等条件下，我们肯定愿意做潜在用户数多的产品功能。但是，潜在用户数不是唯一的因素。有一些产品虽然潜在用户人数很少，但是也可以做，因为它覆盖的这些用户，“单用户价值”非常高。典型的例子就是银行的VIP业务，从普卡、银卡、金卡、白金卡到钻石卡，以及再高级一点的私人银行，用户数越来越少，但一个高级用户的资产少则几千万，多则几个亿，可以抵上几千几万个初级用户。

单用户价值这个词，在不同行业能找到不同的说法。比如，电商行业的“客单价”，是指用户平均每次消费花多少钱；游戏行业和运营商的“ARPU值”（average revenue per user），是指平均每个用户在单位时间内给公司带来的收入；而对于社交应用，对应的说法也许是活跃度。

从广度的角度，“潜在用户数*单用户价值”可以用来判断产品对应的市场容量，也就是第03章提到的“产品概念筛选”里的“天花板”。当然，具体操作时，经常先从某些细分用户切入，再逐步扩大到所有潜在用户。比如，2016年下半年火爆的ofo共享单车，就是先攻高校内部，再扩张到校园外。

频度：需求频次*单次复杂度

频度是指需求频次的高低，不同的需求，频次差异会非常大。

有些需求每天都会出现一次甚至多次，比如叫外卖；有的需求每周最多出现一次，比如看电影；有的需求也许每个月只出现一次，比如交水电费、还信用卡；有的需求每年出现一、两次，比如车险，出境游等；有的需求甚至有可能一辈子只出现一次，比如结婚。

同等条件下，我们当然更喜欢做频次高的产品功能。我曾负责过天猫积分系统，当时有很多积分相关的消息要开发。在产品的早期版本里，我做了一些简化：买家每次购物产生的积分变动消息，需要先做；而用户每年年底积分过期的提醒，可以缓缓，如果碰到可以先手动解决。

但是，有些需求的频次不是那么高，我们也愿意做。这是因为这些单次需求的复杂度高，而且单价也高，有很大的价值空间可供挖掘。

虽说外卖需求的频次比较高，但每单通常只有20块左右。而婚礼，虽然一辈子只有一次，但背后的需求包含了很多点——拍婚纱照要几万，办酒席要几十万，蜜月旅行要几万；还需要买一些周边产品，小到喜糖，大到车和房，后者又至少有几百万的潜在市场价值。

通常，频次很高的需求不太可能有太高的单次价值。理由很简单，类似每天一次、每次一万块这种需求，只能存在于极端小众的土豪市场，大众普遍没有这么强的消费能力。

通过图6-2很容易就能得出结论，高频高单价的需求极少，低频低单价的需求不值得做。对于另外两个象限的需求，常见的策略是：先利用高频低单价的需求抓用户，因为高频场景和用户互动的机会多，而低单价的轻决策场景可以降低用户进入门槛，容易引流；再用低频高单价的需求做利润，因为单价高了，可以切分的蛋糕才大。之所以采取这样的先后次序，是因为必须有海量用户做基础，低频需求的总量才足够大。比如汽车后市场（指买车以后产生的各种消费）就很典型，用高频低单价的洗车增加客流量，甚至通过补贴来抓牢用户，然后用低频高单价的保险、保养、修车来赚取利润。

“需求频次*单次复杂度”，让我们在广度之余，可以从频度的视角再一次对市场容量进行验证。

强度：不可替代、紧急、持久

强度背后说的就是真实刚需。

一个需求是不是真的，是不是刚性，有一个简单的判断原则，就是问自己这样一个问题：“当你没有做这个产品功能时，用户是不是在设法解决，甚至已经在用某种低效的方式来解决这个问题？”如果答案是肯定的，那么说明需求真的很强烈。接下来再给大家讲几个判断的角度。

可替代性

可替代性用来说明一个功能是不是很容易被其他功能替代。打个比方，假设你开了家早餐店，一开始技术不太熟练，所以每天早上只能供应包子这一款单品。做了几个礼拜之后，技术水平提高了，发现早上时间还有富余，可以再做第二款单品。这时有两个选择，一个是馒头，一个是豆浆，应该怎么选呢？我相信大家都会选择豆浆。因为馒头和包子是可以互相替代的，豆浆是不可替代的。你会发现，买了包子的人经常会四处张望，看看旁边有没有卖牛奶、豆浆或其他饮料的，因为包子太干，容易噎着。

紧急程度

需求紧急程度也可以作为衡量需求强度的判断原则。科学的时间管理建议我们应该更有计划性，尽量避免紧急的事情发生，但现实中的确有这样的需求，真的是受各种客观情况所限，必须马上动手实施或调整计划。比如，极个别用户的负面评价，引起了广泛的舆论风波，必须要在产品上做出响应；营销方案已经开始推广，忽然发现支撑后台还有部分功能没有实现；竞争对手突然提高了补贴力度，必须马上决定是否应战。

持续时间

持续时间是指一个功能做好之后，用户有效使用的周期是多久。有一些需求上线后用户可能只用几天，另外一些需求上线后用户可以用几年，产品经理当然愿意做后者。举个例子，中秋节的促销活动一般只持续3天。如果要开发一个特定的系统，那么产品经理通常会采取两种对策，或是和营销人员沟通，询问能否借用已有功能来实现这一需求，或是争取把这个功能做成通用模块，以后可以经常复用。

不同阶段的产品看重什么

在产品的不同阶段，对上面提到的广度、频度、强度，会有不同的侧重点。

产品早期的验证阶段，更重视“强度”。通常在产品上线前后，要设法验证用户是否认可产品，愿意用且愿意反复用，即测验留存率高低。只有留存率够高，产品在将来才会有好的发展，而留存率高就要求产品背后的需求足够强。所以，刚上线的产品就像大家在小学应用题里经常见到的那个游泳池，有一个进水口在进水（获取新用户），有一个出水口在出水（失去老用户）。如果产品经理在现实生活中遇到这样的事情，当然会先去堵上出水口，而不是急于灌水。这个阶段的产品，常见的版本号是0.8，0.9和1.0，还在不断试错，寻找最能打动用户的切入点。

验证完毕，产品进入大面积拉新（指获取新用户）的阶段，这时更重视“广度”。这个阶段的产品需要快速增长，希望通过各种推广来占领更多市场份额，以尽快与对手拉开差距。所以，拉新是否顺利，依赖的就是需求和功能覆盖的广度是否够大，当然也离不开足够的资源和资本支持。对于产品本身，此阶段常见的版本号是1.1，1.2，工作重心依然是围绕核心功能做优化，同时可以获取大量的用户反馈。

当用户增长出现瓶颈，就需要开始对产品的用户进行激活，这时更重视“频度”。拉新阶段，通常的策略是先攻“单用户获取成本”低的场景，比如你要主攻白领人群，那么上下班时间的写字楼电梯口，就是一个好场景，在这里单位时间内能获取的新用户数肯定高于你在路边随机拉人。但是，当这类场景都做得差不多了，拉新成本就会越来越高，也就意味着用户数没法一直保持高速增长。这时再想扩大产品的价值，怎么办？在每个用户身上挖掘更大的潜力是个好办法，所以这个阶段适合做频度，让已有用户更加活跃，使用产品的频次提高，贡献更大的价值。这时候产品一般会出现大幅度的版本跳跃，比如从2.X升级到3.0。

当然，上述对产品阶段的划分过于理想化，真实情况是各个环节互相渗透，交替出现。

6.1.2 　几个价值判断的案例

对于功能的价值判断，可以借助回答下面这两个问题来得到结论：

谁的痛，有多少这样的人？（这些人是核心用户吗，人群足够大吗？）

痛有多深？何时会痛？何地会痛？多久一次？一次多久？（具体场景典型吗？需求刚性吗？）

完成判断后，再来验证一下被判断为价值最大的那些功能，是不是正好满足第03章提出的产品概念切入点——核心用户、刚性需求、典型场景，借由二者的吻合情况可再次验证整个产品功能价值判断的逻辑。

6.1.3 　成本评估与性价比

成本评估

判断完了功能的价值，就要评估另外一个同等重要的因素——成本。

判断一个产品功能的成本，有很多方面的考量，比如人力、时间、金钱等，甚至也可以把风险看作广义的成本。日常评估时，没法面面俱到，所以通常会先判断成本的瓶颈在哪里，然后用对成本瓶颈的评估来简化完整评估。互联网、IT行业的功能成本瓶颈一般在开发工程师的工作量上，所以常常把“开发量”的高低视为成本的高低。

那么，具体谁来评估？我认为有技术背景的产品经理，这时候自己上就可以了。因为这个阶段的评估是相对粗略的，可以称作成本的“初评”，虽然常用的计量单位还是“人天”（指一个人一天可以做的工作量）、“人周”、“人月”，但目的不是为了精确知道工作量，而是为了了解不同功能实现难度的排序。

这个时候只做初评的原因，一方面是因为评估准确也需要很多投入资源，而这个功能做不做还不知道，所以没有必要精确评估；另一方面是因为做不到，毕竟还没有确定功能细节，也不知道由谁来做这个功能。

……

往往，越想让用户简单，系统就要设计得越复杂。

所以，针对成本的初评来细化功能，细化到什么粒度是很讲究的事情。粒度太粗则没法评估准确，而太细又会浪费时间。这里面有个有趣的悖论：开发说你不细化我就无法评估，产品说你不评估我就不知道是否值得细化，双方各执一词，形成死循环。

要想正确看待这一悖论，需要双方心里都清楚，功能细化有可能给成本带来很多方面的影响，最终减少影响也离不开大家的共同努力。

而要在没细化时就能评估得相对准确，要靠团队默契。想象一下，如果产品和技术团队都很成熟，对彼此的人员情况很熟悉，对现有产品、技术架构也很熟悉，具体表现为产品经理知道技术人员的能力，了解功能实现的基本可行性；技术人员理解产品业务，能预测将来会扩展的地方，那么早期的评估一定会更加准确。

如果细化之后工作量确实比预想的大了很多，我们还可以灵活分割，把一个大功能切分成更细的模块，按照性价比分期实现，从而在保证产品迭代节奏的前提下，逐步完成工作。

确定性价比

评估完价值与成本后，就可以得到一张功能列表，具体的呈现可能是一张Excel表格，或者是某个IT系统里的需求管理表。

……

经常有人问我产品经理要不要懂技术？我的观点是，产品经理懂技术肯定是优势，只要不滥用。比如，在初步评估成本时，自己能搞定就可以大大提升效率。那如果不懂技术怎么办？你就必须和技术人员配合。提供两个常见的方法，Team Estimation Game和Planning Poker，都是敏捷开发过程中供团队一起评估成本的方法，非常简单也非常好用，有需要可以自行查找资料加以学习。

要牢记此时评估的目的：确定功能的相对成本高低，从而确定性价比。功能A与功能B相比，哪个相对成本较大一点，哪个较小一点，只需要知道对比关系就可以，比如“高中低”的评价或者“5.3.1　”的不同分值。然后，用半定量的价值和半定量的成本，就可以计算出半定量的性价比。

这个半定量的公式是：性价比 = 价值/成本

按理说应该先做那些性价比高的功能，但这太理想化了，实际操作中，还需要考虑功能的分类和其他的实际情况。

6.1.4 　功能分类：KANO模型

表面上看，只要从功能列表中找到性价比最高的功能先做，就不会有问题。但事实上并非如此。你会发现，有一些非常基础的功能，比如一个电商网站的交易、支付等功能，是非做不可的。如果这些功能需要投入较大工作量，则性价比不会很高。这与之前性价比高者优先的结论有些矛盾，要想正确看待和理解这一矛盾，需要引入KANO模型 。不过，由于KANO模型并不是专门针对产品经理而设计的，此处对其说法进行了一些相应的转化，用它来对功能进行分类。

先来解释一下图6-5。图中横轴指的是产品功能的实现度，用来表征一个功能有没有做完。最左侧的一点代表功能实现尚未开始，最右侧的一点则代表功能实现已经很完善。纵轴指的是用户满意度，越靠近下端表示用户越不满意，越靠近上端表示用户越满意。

……

第一类，基础功能

第一类功能对应的是如图6-6这样的一条曲线。

由图6-6可知，当这类功能没有实现时，用户对产品是“极其不满”的。但是，这个功能做得再好，用户也认为“理所应当”。于是，把这种功能叫作基础功能，英文中的说法是Must Have。基础功能是必须要实现的功能点，但无法带来满意，只会消除不满。

……

第二类，亮点功能

第二类功能的曲线与基础功能的曲线看上去正好相反，如图6-7所示。

这个功能没有做时，用户并不会不满意或觉得有问题，因为已经“习以为常”。但是一旦有了这个功能，用户就会大为惊喜，甚至“赞不绝口”。为什么会这样？主要因为这些功能通常是新的，用户事先想不到产品居然还能有此妙用。比如，若干年前，有谁会想到，手机能当手电筒用，浏览器能通过记忆和联想自动补全你刚开始输入的网址，已发送出去的电子邮件还可以因内容不妥在几秒内撤回……这类功能有一个名字，叫作“亮点”，对应的英文说法是Excited To Have。

亮点是忠诚度、口碑传播的基础。如今，一个没有亮点的产品，用户也许偶尔会用，但不会与产品建立正向情感连接，更不会主动帮我们传播。想要低成本引流，让老用户带来新用户，产品必须找到自己的亮点。

那么应该做什么样的亮点呢？常见的亮点特性有“用户没见过”、“未经市场检验”和“如果被认可就能获得巨大回报”这几种。由其可知，选择亮点不能一概而论，大公司和小公司，已经很厉害的产品和新生的产品，都会做出截然不同的判断。

小公司和早期产品，应该优选成本低的亮点，仅将其作为锦上添花。比如很多网站有趣的404页面、很多App里用心的交互小细节。因为一个潜在的亮点在投放市场之前，并不知道它会不会真的变成亮点。如果投入太大成本去做这样的亮点，对小公司来说往往等于孤注一掷，一旦用户不买账，公司基本就完蛋了。当然，如果就是信奉大赌大赢，则另当别论。

对于大公司或很厉害的产品来说，情况完全不同。由于市场竞争领先、资源充足，完全可以不用那么在乎成本，做一些可以让自己保持领先地位的亮点，以寻求更大突破。还可以通过大量市场调研和技术预研，在功能推向市场之前就基本确定它是一个亮点，然后再投入大量资源重点研发，把这个亮点打造成领跑市场的杀手锏。

比如苹果手机，从iPhone 5S开始推出指纹识别，就是一个比较典型的例子。起初，安全和麻烦似乎相伴而生，想要安全就不能怕麻烦。要学会用多个密码、大小写字母+数字的强密码、短信验证、安装证书、硬件USB KEY、动态密码卡等方式严防死守，因为怕麻烦就意味着不安全。最终，指纹识别的出现一举解决了这一矛盾，完美兼顾了“方便”和“安全”这对曾经矛盾的需求。指纹识别这种级别的功能，一定需要投入大量市场、研发的资源，但因为能事先确定必会成为大趋势，先做出来就能引领潮流，而且苹果公司和产品的状态也足以支撑这样的突破，自然不会放过这样的亮点。

怎么做出亮点？主要靠对用户人性的理解，因为亮点是用户想不到、说不出的，必须领先一步，深刻洞察，这方面内容在第05章已经聊了很多。

第三类，期望功能

第三类功能的曲线如图6-8所示，看上去比较平缓。这类功能叫作期望功能，对应的英文说法是Nice To Have。这类功能，对产品而言往往是“多多益善”，选择起来也比较简单：先做性价比高的。

之所以取“期望功能”这个名字，是因为这类功能都是用户的期望。比如，你要做一款创新的智能手环，去问用户有什么需求，用户的答案可能是“最好操作简单一些”、“要能自动记录我的运动情况”、“充电不用太频繁，希望充一次至少用一个礼拜”、“样子要酷一点”……这种大多数用户能说得出来的，就是期望功能。

产品具备了期望功能，用户当然会继续使用，但因为缺乏惊喜而不大可能主动传播。如果只是通过简单地和用户交流来采集需求，最终实现的大多只能是期望功能，这再一次印证了第05章反复提到的Y模型中的一个原则：“用心听，但不要照着做”。让我们用图6-9来进一步阐释。

第四类，无差别功能

接下来，再说第四类功能。在图6-10中，它和横轴重叠，用波浪线表示。这类功能叫作无差别功能，做不做用户对产品的感受是没有变化的。

这样的功能怎么应对？当然是不要做。那么问题来了，如果不做，怎么知道它是无差别功能？所以，这里需要提一下低成本验证的概念，就是采取一些小投入的方案，来验证用户需求、验证市场，进而决定要不要做这个功能。对任何准备做的功能做取舍时，我都极力推荐低成本验证的方法。

美国有一个鞋类电商网站，叫Zappos，后来被Amazon收购了。它早在十几年前就在做网上卖鞋这件事情。最开始的时候，要回答的第一个问题就是“有没有人愿意在网上买鞋？”。当时没人知道这件事，毕竟对于买鞋，传统的想法还是要试穿的。如果先把电商的整个系统，包括网站、后台、供应链，等等都搭好，万一没有人愿意在网上买鞋，那损失的成本就太高了。

Zappos的创始人谢家华是这样做的：他先搭了几个简单的页面，当有人下单之后，他就去商场把这双鞋买过来，然后给对方寄过去。通过这样的方式把业务流程给跑通，然后才逐步做各种电商系统。

谢家华写过一本书，叫《三双鞋》，讲的是在用户每次购买一双鞋的时候，Zappos会给用户寄三双，挑中那双外的其他两双可以无条件退回。Zappos通过这样的方式，把用户不敢在网上买鞋的顾虑打消了。

IT系统作为狭义的产品，本来就是用于提高效率的。所以，先通过人肉跑流程来验证模式，使用量上来后再用IT系统来提升效率、实现规模化效益，是常见的操作方式。一个流程在效率可接受时，不一定非要做一个产品出来。千万不要因为我们是产品经理，为了刷存在感，就要把各种东西都做成IT系统。产品只是一种解决方案，人工服务也是，这里面的核心考量是投入产出比。

第五类，反向功能

如图6-11所示，第五类功能的线条呈现为一条反向的斜线，代表的含义是做得越多用户越讨厌，听起来是不是很奇怪？这类功能叫作反向功能。

既然用户讨厌，是不是不要做这种功能就好了？问题没这么简单。

比如百度的广告，对普通搜索用户来说，搜索结果页里广告越多，满意度就越差，但对投放广告的用户，肯定希望搜索结果中也里有自己的广告。

这是因为，KANO模型里的纵轴叫用户满意度，而一个产品的用户是多种多样的，不同用户的目标也各不相同，所以这里的“满意”，针对某一种用户可能是反向的，而针对另外一种用户却可能是正向的。

一个KANO模型，往往只针对一种用户，通常是核心用户。实际上，也可以针对不同的用户画出多个KANO模型。一般情况下，因为必要性不大，实操中很少有人这么做。

在评估反向功能时，要注意以下两种常见的用户属性。

第一种是用户的多边性，指多边型的平台产品里有完全不同类型的用户，他们之间可能存在的利益矛盾。比如同时有卖家、买家双方的交易类平台，往往卖家很喜欢的功能，对买家利益可能有损害，反之亦然。比如出行应用里，司机希望能够主动挑乘客，不希望被平台派单，而乘客也希望能主动挑司机，不希望被动接受，这里面就有冲突。而广义的多边，是外部用户和公司，他们之间的利益，也经常是有冲突的。

第二种是用户的多样性。同一类用户中，有一些人喜欢这个功能，有一些人不喜欢这个功能。举个例子，豆瓣每次改版后总有一些用户会不满意，然后产品经理被骂得受不了了，只好改回去。马上，另外一些刚才没说话的用户站出来说，你怎么又改回去了，我们挺喜欢新版的。这体现的就是用户的多样性。

反向功能很考验产品经理，我们需要在多种用户利益之间寻找平衡，而如何判断不同用户孰重孰轻，则又要回到“价值判断”的章节寻求答案。

6.2 功能打包，确定MVP

到这里，基本完成了功能细化的工作。接下来，就要回答How many这个问题，决定下一个版本到底要做到什么程度。这一节标题里的“功能打包”，就是从整个功能列表里，把下个版本打算做的功能点挑选出来，理清逻辑，安排实施的意思。

6.2.1 　尽可能多地放弃

产品界的主流价值观是“少做就是多做”、“完美不是无一分可增，而是无一分可减”。所以，这一步要确定“最小可行产品”，即MVP（Minimum Viable Product）。

MVP是指的是满足“用户愿意用、最好愿意付费”、“用户易于使用”、“团队有能力实现”的最小功能集合，有些可以直接作为最终产品使用，有些甚至只能用来演示。它的重点就是制作的成本要极低，但是却能展示最终产品的主要特色。当然，对MVP的解释也有争议，比如“可以人工跑通流程的业务模型”算不算MVP？但比起理解MVP的目的，这并不重要。

MVP 的功用就是让你拿着它接触客户，尽早根据客户的回馈来改进你的产品。用户需要的东西有时候并不难实现，但很容易被忽略。如果你不是一开始就跟用户接触，就很难知道这些内幕。典型的错误就是窝在家里做没人要的东西，却自以为很有成就。

和需求采集阶段“尽可能多地采集”不同，这一步要“尽可能多地放弃”。看似矛盾的理念，其实目的都是为了提供尽可能多的用户价值。可以通过表6-2以及图6-12来理解这个观点。

6.3 把需求和功能管起来

该做哪些、做多少都想清楚了，MVP和产品架构图也确定了，接下来要扫个尾，把已经做了的、正在做的、还没做的需求和功能都管理起来。可以从以下两个维度进行管理。

6.3.1 　空间维度：功能列表

空间维度的管理工具是“功能列表”，它表达了在某个时间切片，所有功能的状态。类似图6-18，每行是一个功能点，每列是功能的一种属性。读者如想进一步了解相关知识，请参阅拙作《人人都是产品经理（纪念版）》，书中有详细讲解。

6.3.2 　时间维度：需求流程

时间维度的管理工具是“需求流程”，它其实是从需求到功能的状态流转图。图6-19反映的就是从最初需求采集回来的待讨论状态开始，之后需求发生转化，流向开发环节，最后过渡到已发布状态的全流程。“需求流程”实际上是在管理某个需求到功能的完整生命周期。读者如想进一步了解，同样可以参阅《人人都是产品经理（纪念版）》一书。

值得一提的是，图6-19里的“暂缓”，在实际工作中已化身为“这个需求放二期”，成为产品经理拒绝需求的金句。用这招，不知道砍掉了多少功能，因为很多项目根本就没有二期。还有一些砍需求的金句，分享出来博读者一乐[6] 。

6.4 延伸阅读与练习

第07章 执行：立项组队与研发生产

7.1 从“想清楚”到“做出来”

7.2 立项：搞定各种资源

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

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

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

……

How：项目计划及风险对策等

这一部分，要说清楚项目计划、需要多少资源做保障，让老板们知道要花多少时间、多少资金，以及要用多少各种岗位的人。如果你做过竞品分析，可以把可能碰到的风险及其对策等也放在这里。还可以针对具体业务，说说打算如何获取用户、上线后怎么运营、做什么市场动作、如何评估这些动作的效果等。

如果是创业公司融资，在这部分还可以加上核心团队的背景介绍、当前股权结构和融资预期等信息。

MRD写得好，意味着各种准备工作做得到位，最终能获得各种支持就是自然而然的事。本节的最后，再分享一些创业公司融资的注意点。

首先，有些情况下的钱不能拿：一是只出钱却想控股的，会使得团队陷入打工心态；二是不懂行的暴发户，没法提供资源支持，还喜欢指手画脚；三是给了钱却附加各种条件的（相信我，你肯定玩不过投资人）。建议有融资计划前，尽量多和有过融资经历的创业者交流。

其次，投资人给钱时，不同轮次的关注点不同。基本上，种子轮只看团队，只要团队靠谱，就算还没确定方向，拿个几十万到一两百万人民币是没问题的。天使轮，就要看产品了，产品做出来且通过了早期的用户验证，就能拿到大几百万到一两千万人民币，可以用于继续发展。投资业内有个说法，大公司里出来的，或者已经有过靠谱创业经历的明星创业者，刷脸就能拿两轮，说的就是种子轮和天使轮。再往后，产品进入市场运营、销售及品牌积累阶段，就要看数据增长、能否找到商业模式、收入、赢利、市场份额等这些指标和因素，这时候再拿钱就是ABC轮等。所以，作为一个创业者，在早期最需要关注的是团队和产品。

接下来就谈谈初创团队相关的话题。

7.3 组队：聊聊初创团队

理想的初创团队，当然是熟识多年，底层价值观相同，方法论、能力、性格互补的一群人，但这群人通常不会一开始就凑齐，往往需要经历“借事修人”到“因人成事”的转化。“借事修人”的阶段相当于练兵、演习，就算事情没成，如果锻炼了团队，也算差强人意，接下来就说说这个阶段可能出现的问题以及应对方法。

7.3.1 　如何快速知己知彼

以下故事，皆为亲历，如有雷同，真是巧合。

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

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

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

在非工作时间、非工作地点 ，沟通更容易敞开。这时候可以一起聊这样几个方面的话题，每个人都要发言。

► 为什么要来这个团队？

讨论可以从每个人的理想，若干年后希望自己在做什么，到更具体的三年后的个人目标。然后，设法找到个人目标与团队目标的结合点。

► 对一年后收获的底线预期。

有人希望能找到一份工资翻倍的新工作，有人希望提升某方面的技能，有人希望锻炼出一支能成事的团队……但任何人都不能一无所获。

► 个人对团队的帮助。

在“守住底线，奔向理想”的基础上，每个人有必要让其他人知道自己是有价值的，而每个人也需要知道其他人的具体价值。

► 自己能做什么？

这个话题主要总结过往积累的能力。

通过一个人过去做过的事情，比如App的渠道运营、做过SEO等，可以看出哪些事情他可以较快上手。团队Leader对每个人比较了解，但团队核心成员很有可能互相并不清楚对方能做什么。

► 自己想做什么？

这个问题用来探求将来的意愿。

每个人都有希望提升的方面。比如，有人想在线上线下的活动策划上有提升，以便对运营岗位有个更全面的把握，这时其他团队成员可以一起帮着分析、判断一下，其想提升的方向和个人的长远目标是否契合。知道对方想要什么，配合起来才更顺畅。

► 项目失败最可能的原因是什么？比如，没能及时引入合适的人，或者团队成长不够快，因整体实力不够，项目难以突破，僵死在一个不好不坏的程度。甚至，初始的股权结构不合理，到某个阶段可能会让团队散掉……

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

聊的时候，可以抽离出来，以第三方的视角来看待问题。最终会发现，绝大多数问题还是出在人的身上，团队成员能有共识至关重要。

最终，可以结合以上问题，由团队共同提出非业务层面的改进方案，但方案的核心要点最好不要超过三条。比如，其中一条有可能类似——将决策机制从原来的核心团队共同讨论，直到达成一致，改为核心团队共同讨论，最终由老大拍板后执行，或是核心团队每周必须聚餐之类很具体的举措。

上面这些话题看上去有些虚，但对提升早期核心团队的战斗力非常关键，问题的具体答案是什么其实不重要，重要的是共同参与。

7.3.2 　小团队的沟通协作

虚的讲完了，再讲一个实的。这也是我带过的一个真实小团队的故事。这个团队一共有5人，其中2个全职、3个兼职，每个人的专业能力都不错，做的是互联网/移动互联网领域的产品。因为不在同一个城市办公，挑一个好用的协作工具来同步信息，成为关键点。

本着“工欲善其事，必先利其器”的理念，团队组建前就研究过很多协作工具。但并没有一个工具被坚持采用下来，因为随着一个个队友的加入，前一个工具总是很快被与团队规模更加匹配的新工具所取代。我们始终遵循“奥卡姆剃刀”原理 ，每时每刻都在考虑用最低成本的方式来满足需求。

7.3.3 　小团队与大公司的区别

7.3.4 　借助第三方力量做产品

7.4 研发生产时，我们做什么

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

►立项环节： 即本章前半部分探讨的话题。在这个环节，产品经理要组建团队、设法获取各种资源，以及确定项目计划。在正式开干之前，一般还会开个Kick Off会议，鼓舞一下士气。

►需求环节： 这个环节主要做的是功能细化，也可以叫需求开发。产品经理要写PRD产品需求文档和UC用例，并和设计师配合做Demo原型。在这个过程中，可能会经历多次评审会议，还要和技术人员一起确定功能细节。以写产品需求文档为例，产品经理一般都不会遗漏主干流程的描述，但是否能把分支流程、异常处理、边界条件都写完整就不一定了。比如，一个搜索结果为空或少结果时怎么处理，会员管理列表中如果一个会员都没有，是否应该全空着，微博用户关注人数达到上限时该怎么提示，等等，都是产品经理需要掌握的基本功。

►开发环节： 这一环节的主角是开发工程师，他们要做代码方案的设计和评审，然后完成编码和单元测试[6] 。与此同时，产品经理已经开始下一个迭代版本的项目前期准备，这是第08章的话题。

►测试环节： 开发推进的同时，测试工程师要编写TC测试用例，通过TC评审，并且在系统可用的第一时间做冒烟测试[7] 。此环节中，产品经理要组织功能评审，在第一时间把新产品展示给所有的项目干系人，以确保做出来的东西是大家想要的。

►发布环节： 测试工作完成后，运维人员要组织发布评审，执行预发布、发布的动作，并且在发布完成后让产品经理到真实的线上环境去验证，以确保产品符合预期。

为了保证整个过程的顺利进行，产品经理还要把控三件事。一是文档管理： 每个环节的输入/输出文档是什么，用什么模板、工具编写，以及如何保证同步更新等。二是流程管理： 每个环节的各种评审会议，是否可以结合团队实际情况做出删减，突发需求和需求变更如何处理等。三是敏捷方法： 团队日常沟通采取什么方法，如何监控进度，以及如何改进配合模式等。

上述这些细化需求和跟进研发的工作，产品经理在入行的头两年会经常遇到。我在《人人都是产品经理（纪念版）》的第3章有更加详细的讲述，这里就不再展开。研发生产环节的主角是技术人员，下面主要聊聊产品经理和他们配合过程中的各种注意点。

7.4.1 　产品经理要不要懂技术

产品经理到底要不要懂技术？这是一个经久不衰的问题，因为在研发生产过程中，产品经理要经常和技术人员讨论细节，如果完全不懂技术，似乎很难沟通。所以，这本质上是一个沟通的问题，标题中的“技术”换成“设计”、“运营”、“市场”等也是适用的。下面，说一下我的理解。

第一， 底线是可以和技术人员无障碍沟通，并不要求你会写代码。具体点说，技术人员可以直接用平时和同伴说话的方式与你交流，而不用刻意翻译。如果对话过程中经常出现听不懂甚至解释了还是不明白这类情况，很容易让彼此间失去信任，直至没法沟通。当然，和高水准的技术人员配合，会轻松很多，他们更会换位思考，尽量用通俗一点的语言进行沟通。此外，良好的沟通能力和理解能力，也可以弥补专业知识的不足。

第二， 多向技术伙伴请教，自学一些技术知识。如果你懂一些术语或者会说一些“黑话”，让技术人员觉得“你即使不会写代码，但也是懂的”，会拉近彼此的距离，建立一种自己人的信赖感，这在沟通、协作过程中会有很大的帮助。所以，对于技术出身的产品经理，这点确实是天生的优势，但他们要注意的是不要滥用技术，越俎代庖。一方面自身应该把更多的时间精力用在思考产品层面的事情；另一方面也不应挫伤技术人员对产品的“责任感”与“参与感”。

第三， 根据所负责的产品，决定要懂哪些技术，懂到什么程度。做技术驱动型的产品，比如Baidu搜索，那必须是特定方向的技术出身，否则很难胜任，而如果你要做一个导购类的App，就相对容易一些。所以，要补哪方面的“技术常识”，最好能先明确将来你要做什么产品，可能碰到哪些技术。

第四， 要特别关注技术方案与业务场景的关联。有些技术方案的选择会反过来影响业务，这种情况下产品经理最好能给技术人员提出建议。举几个例子：你要知道iOS的开发分客户端和服务器端，能根据业务需要建议数据更新的方案；你要能想到把一些静态素材做成配置文件以方便修改；你要能给出建议，将经常需要改动的那几个页面做成H5页面。

如果你现在还做不到上面说的几点，也不用担心，我见过很多文科出身的人，经过几个月的痛苦折磨之后，也上路了。文科生做产品，在研发生产阶段确实有劣势，需要有更多的加分项来弥补。推荐关注“给产品经理讲技术”（微信号：pm_teacher）这个公众号，里面的文章用浅显的语言讲解了很多产品经理最需要掌握的技术知识。

接下来，分别看一点开发、测试、设计、运维等方面的专业知识，用极短的篇幅帮助大家快速摆脱一窍不通的状态。

开发的 Secret Toolbox

如果你不被技术人员认可，或者把他们逼得太紧，就容易逼出一系列可怕的大招——开发的Secret Toolbox，下面给大家分享一下。

► Copy&Paste： 不假思索地“复用”，满足当前需求就好，不考虑逻辑的可扩展。比如，A和B现在1对1，不考虑将来有可能1对N，即使是业务上已经做出提示。

► Hardcode： 写死代码，不用配置文件和变量。当你发现某个参数不妥，想要多改几次试试时，会发现工作量超乎想象，而且怎么改都改不干净。

► Less Testing： 减少测试，或者不重视测试。听到一个很搞笑的故事，某位技术同学写完代码做单元测试，第一次没过，百思不得其解，于是再测一次看看，结果过了，再测，又过了。于是，就认为第一次是幻觉。

► Skip Error Handling： 不考虑异常情况，直接假设用户都是正常使用（当然，在业务方认可时确实可以这样做）。举一个最简单的例子，输入框没有做安全上限的长度控制，用户可以通过输入过长的内容来直接使网站挂掉。

► Descope： 偷摸减需求，只做主流程，不做分支流程。不用举例，真的会有，验收时产品经理发现了还好，但只验收主要场景是发现不了的。

► Less Review： 减少设计评审、代码Review等。强技术的确可以少评审，但会动用Secret Toolbox的同学往往并不是很厉害的人。

► No Autotest： 不提供测试自动化。工欲善其事，必先利其器，一直不磨刀，整体效率就一直上不去。

如果对技术缺少敬畏，就会在不知不觉中背上沉重的技术债务。一次交付最终完成，当你看到需求都已满足，心里甚至还会暗爽：就是要逼吧，你看，逼一逼都做出来了，下次继续……但这种理想状况不会持续太久，总有一天你会发现，整个技术团队越来越不愿意承诺，即使承诺也越来越难履行，效率好像越来越低。要么任务经常延期，要么出活越来越少。这些现象表明，用来填坑的时间越来越多。

直到有一天，技术Leader面露难色地找到你，说：

“兄弟，业务发展太快了，技术架构跟不上，要重构了。”

“啊，要多久？”

“两个月，一大半的兄弟都要参与。”

“不可能，因为……”

“必须重构了，不然说不准什么时候就挂了。”

以上就是技术负债前后生动的一幕。

测试是个专业活

测试工程师也是技术人员的一种，他们与产品经理做事的思路有明显差异。产品是把握大方向，而测试是专盯细节。有一次我在知乎上看到一个很有趣的问题，通过这个问题，正好能把一些常见的测试概念科普一遍。

问： 为什么互联网公司开除测试，转而让大众来测，找到一个Bug给100元？

答： 大家的讨论很有意思，不少都是围绕100块够不够、给不给、怎么给来说的。我的角度是，测试是产品团队里一个重要的角色（团队早期可能由产品经理来兼任这个角色），没了他们还真的不行。

0. 默认前提是，开发已经做了单元测试 和冒烟测试 （原则上冒烟测试应该测试来做，但人家都被你们开除了啊，只好让开发来做了，至少要保证交给大众的是一个能跑起来的产品），这两项总不至于期望大众来帮忙做吧。

1. 很多Bug其实并不是非黑即白，也许产品就是这么设计的。这些内部的测试知道，但外部的大众不知道，他们用起来觉得不爽，当Bug提了，这钱是给还是不给？哪怕公司内部，当测试发现此类问题（比如为了安全考虑，第二次输入密码的确认框不允许复制粘贴），开发说这是一个需求/特性 ，还得再把产品经理叫过来一起讨论，外部可做不到。

2. 专业的测试需要测试用例 （Test Case），但常见的测试用例（临界值相关、内存会不会泄漏、特殊字符……专业测试人员玩起来一套一套的，分分钟把开发认为没问题的程序挂掉）在大众那里可做不到，更不要说TC评审 了。或者说，大众永远是知其然不知其所以然，所以只能做黑盒测试 ，没有办法做白盒测试 。

3. 专业测试提的Bug是分级 的（成熟的产品应该有Bug分级标准和规范）。研发流程里应该有相应规定，几级以上的Bug必须全部close才能发布；开发也会按照级别来确定修复顺序，并不是所有的Bug都需要马上修复。而大众提交上来的Bug，还得额外安排人去做分级Review。

4. 专业测试会把Bug指定给特定的开发或产品经理，背后的逻辑是这些特定人员知道技术角度的模块划分，以及对应的负责人，只有这样才能方便流程向下执行。而大众提交上来的Bug，还得安排人去做assign to这个动作。

5. 专业测试懂得用开发明白的语言描述Bug，能说清楚是什么机器、什么系统、什么版本，特别是能说清楚“如何重现”。而大众提上来的Bug，出错环境不明确，Bug重现 不了，急死你。

6. 内部经常有针对Bug的讨论，部分Bug可以defer或reject。那么问题来了，谁来牵头组织讨论，以确定Bug状态 的流转与控制？可不要指望大众会“跟进”自己提交的Bug。

7. 如果开发比较牛，能理解大众提的Bug，但改完后谁来确认是否修复，谁来close这个Bug，整体的回归测试 [8] 谁来做？

8. 以上还只说了狭义的功能测试 ，性能测试 、压力测试 怎么办？大众没法帮你模拟10万人同时做某个操作。还有，自动化测试谁来做？

9. QA ——质量控制相关的事情还没说呢。

10. 其实，这个做法接近于UAT （用户接受度测试），也有人叫验收测试 。经常由产品经理代表用户做（当然，有资源最好让用户亲自来），不是找Bug，而是看产品是否满足用户需求、设计是否符合用户认知，等等。

11. 这事儿很好，有条件都做吧。但更多的目的是找个理由和用户互动，而不是找Bug。

看了这一段，相信大家对测试工程师也心生敬仰了吧。

设计与运维环节

研发生产的主干环节是开发、测试。在其前后，还有设计和发布这两个环节。下面讲一下这两个环节对应的两种主要角色。

设计

先说说设计师的分工，主要有以下四种。

►交互设计： 关注的是产品与用户互动的过程，具体的输出为产品线框图、低保真原型等。

►视觉设计： 更加注重用户界面看上去的美观、好用，具体的输出为视觉稿、高保真原型等。

►工业设计： 主要对应产品里的硬件、实物、包装等的设计。

►服务设计： 更加关注线上、线下的服务流程，以及如何提升用户体验等。

在需求细化的环节中，产品经理和设计师要并行作业，所以两者任务的界限也有点模糊。如果用一句话来区分他们，就是产品经理负责结构化思维，设计师负责形象化表达。

接下来以著名的“尼尔森十大可用性原则”其中两条为例，进一步感受一下设计师到底在做什么。

原则一：所有动作都可视

所有动作都是可以及时获得反馈的。比如在PC互联网时代，你的鼠标悬停在一个超链接上或单击一个超链接都会看到实时的视觉反馈。

原则二：对用户操作容错

帮助用户从错误中恢复，容许用户在操作后反悔。例如，在你误删除邮件后还可以做undo操作。

发布

发布相关的概念属于运维的范畴。因为有了丰富的云服务，现在互联网业务的运维工作轻松很多。在团队不大时，甚至可以交给开发工程师代劳，而等到产品发展壮大后，运维工作就非常关键了。运维工作要负责维护并确保整个服务的高可用性，还要不断优化系统架构、提升部署效率、优化资源利用率以提高整体的ROI（Return on Investment，投资回报率）。目前大规模集群已司空见惯，如何管理好成千上万台服务器上的服务，成为运维工程师面临的最大挑战。

移动互联网时代，发布的工作还包括“发包”。发包是把安装包提交给各种应用市场。俗话说，iOS怕审核，Android烦渠道。具体地说，iOS程序提交到苹果App Store审核之后，总会碰到奇奇怪怪的拒绝理由，关键是每次拒绝审核人员只提出一个问题，改好后再次审核时才提下一个，时间就这样一天天过去，效率非常低下。而Android程序，有太多各式各样的应用商店，发包工作不胜其烦。

以上提到的都是把产品“做出来”的岗位，但只列出一些线索。研发生产的过程中，还会有些其他岗位的人员也介入进来，比如客服要熟悉新产品、准备帮助文档，市场运营要准备商业上的发布方案等，这属于广义运营的内容，到第09章再说。

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

本章的最后，继续聊聊在研发生产过程中与他人沟通和配合时的注意事项。下面以与技术人员沟通为例，分享一些简单易学、通俗易懂，能让产品经理在各种配合方眼中迅速变得很讨厌的做法。

开始实施之前

►不说清需求价值。 技术问“为什么要做”时支支吾吾，或者说这是老板（运营）要的，假装自己是个传话筒，或者说“我接的是二手需求，什么都不知道”，而不是去追溯这个需求的初衷。相反，面对老板时，则一定不要有理有据地顶撞，那会让大家喜欢上你。

►不去想功能细节。 技术问细节（当然，是涉及业务的细节，不是技术实现细节）时，装作自己之前完全没想过，需要现想：“那就这样做”、“可能那样做也可以”“要不你来定吧”……这时你能看到的是技术同学的白眼，听不到的是他们心里的三字经。

►帮技术评估工作量。 特别是技术出身的产品经理，最容易这么干。他们的潜台词就是“希望加活”：“我评估过了，这些都能做掉的”、“不要偷懒，不要忽悠我，我都懂”。

►逼着技术团队承诺。 任何时候只知道公事公办，技术承诺了却做不到，自己就没责任了。很多事情不像接力跑的交棒，更像踢足球的传球，一开始没人知道下一步该干什么，如果对方基于此对你说：“大家在一条船上，应该同舟共济”时，你只要回：“我不管，我不管，我不管”就好了。

我认为，“承诺”更适合传统的瀑布模型，开发任务明确，技术也成熟，可以提前计算好工作量。但在互联网的敏捷模式下，很多时候会做着做着发现坑，或做着做着需求不得已发生变化，所以产品经理应该和技术人员一起做“预测”，心里想着目标，一起面对变化。最核心的区别是：承诺是技术对产品的责任，预测是两边一起承担责任。

实施过程之中

►做了一半改需求。 经常在某个迭代周期内做“非受迫的需求变更”，这招太狠了，技术同学肯定很难忍受，俗话说“没有变更就没有伤害”。如果是因为产品经理没想清楚而导致无谓劳动，碰到性子烈的技术就要直接干架了，这时候要注意保证自己的人身安全。

►开发过程中消失。 你可以多安排点出差、多开开会，注意手机尽量关机，不要响应技术的问题，要不然，责任就回来了。让技术同学为了赶进度，按照他们自己的想法做下去，关键是要在验收的时候跳出来说“这不是我要的”，再次提醒注意人身安全。

►过度关注实现细节。 帮技术决定技术方案，技术出身的产品经理最爱干的事儿就是变着法儿地越俎代庖。一定要把技术从积极主动的小伙子，打击成一个个纯打工心态的“资源”（这个词听起来就有杀伤力）。

产品发布之后

►发布后没有反馈。 技术人员也需要从市场、用户那里获得反馈，从而对自己做的事情产生价值感和成就感。我们要做的就是，功能发布之后，好像石沉大海，不告诉大家任何结果，甚至庆功会都不叫他们，紧接着继续安排他们干活。

►任务无节奏感。 让技术人员忙一阵闲一阵，发布之后再开始研究接下来做什么。一会儿让技术人员有着天天通宵的高强度，给deadline，下死命令，做完之后突然不知道做什么：“你们也一起来讨论一下业务”或者“出去培训培训（做做团建）吧”。

全程适用

►优柔寡断无决断。 表现出这个品质很具杀伤力。比如，在事情讨论完毕后，大家说：“你定吧，你说往哪儿走我们就照办。”在所有人都等着你拍板的时候，你说：“啊……那个……方案各有利弊，我也不知道怎么办，你们有什么好想法……”

►报喜不报忧。 藏着、掖着一些坏信息，比如“老板在考虑干掉这个项目”这类信息，从不主动公开，但通过其他小道消息让大家知道，这样很容易就把互信完全打破，这时候他们一定很讨厌你。

►不要把他们当人。 这是必杀技——不关注人的成长，只关注事的结果，永远把合作伙伴当“资源”。

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

做完本章说的事情，就已经拥有了一个成型的产品。但任何产品的1.0版本一定非常粗糙，需要不断地优化，这就是第08章的话题“规划与迭代”。

7.5 延伸阅读与练习

第08章 成长：规划与迭代

8.1 好产品步步为营

8.2 规划：只看最短和最长

一个产品经理在做产品三五年之后，不可避免地要碰到写规划这件事儿。在快速变化的互联网行业里，规划到底该怎么做才有实际意义呢？

我的建议是，只做最短和最长的规划。短的规划是指最近1到3个月，最多6个月的时间段里，要做什么，其实更像一个项目计划。长的规划是要预判产业终局，比如3到5年，甚至10年以后会是什么样子，要思考那个时候我们能处于产业链的什么位置。有不少人，其中不乏大牛，持“规划无用论”的观点。如果将他们说的无用，理解为中等时长规划的无用，则并无不妥。对于1到3年这样尺度上的规划，在一个快速变化的行业中，多想无益，只能选择放弃思考。

规划通常会有业务规划和产品规划两种。字面意思看，产品规划只需要讲清楚产品要做什么，而业务规划更完整，要涉及不少商业上的话题，因此业务规划要大于产品规划。一份业务规划，与第07章提到的MRD类似，分为三大块：Why、What、How。

业务规划可以包含MRD里的所有内容，但它更加强调“未来几步怎么走”，就像一名优秀的棋手，会多算几步，更通俗的说法是：吃着嘴里的，看着碗里的，想着锅里的。它和MRD相比还应该说清楚以下三点。

► 一句话的业务定位： 如果一句话说不清，那就说明定位还不够准，还需要反复想清楚。这句话通常也会表现为产品的Slogan，比如小红书的“全世界的好东西”、微信的“一个生活方式”，以及陌陌的“总有新奇在身边”。

►一个业务模型： 包括这个业务内部分为哪些模块，彼此之间有什么关系，与产业链中的各个角色怎么配合，如何平衡各方的利益，自己如何赚钱等。为了更加清晰，可以画几张图来表达。

8.3 迭代：再理解敏捷

说完规划再说迭代。

提到“迭代”一定绕不开“敏捷”这个词。敏捷是一个偏技术的概念，是指以用户的需求变化为核心，采用循序渐进的方法进行软件开发。敏捷最重要的不是那些具体方法论，反而是底层的价值观、宣言和原则。对此先说说自己的理解，然后再分享一些实践。

8.3.1 　 价值观、宣言与原则

首先结合敏捷的五个价值观，谈一谈我自己的体会。

沟通

团队中绝大多数的问题，问五次为什么之后，都会归结于人的问题，或沟通的问题。团队配合过程中，开始就约定好明确的“沟通计划”和“沟通原则”是很有必要的，比如“工作日每天18点开站立会议”“最新信息及时同步给相关人，不要藏着、掖着”等具体约定背后的目的，是要实现团队成员之间真正的互相信任、互相认可。

简单

简单强调一切按需，遵循的是Less is more（少做就是多做）原则。随着技术发展，各种基础设施越来越完善，有很多任务都可以由更小的团队来完成。小团队在做产品时，要努力做一个爆一个，不要堆砌功能。在团队管理、文档、流程等方面也要力求简单，切忌为了显得“正规”而增加一些不必要的规范。

反馈

及时获取反馈，用反馈来拥抱变化。阿里的价值观里面有一条“拥抱变化”，让所有人印象深刻。因为我们所在的这个行业实在变化太快，只有适应变化才能够生存下去。及时变化的前提是不断地收到各种反馈，所以信息透明、共享是整个团队必须做到的。Teambition公司的前台有一块很大的屏幕，实时展示整个公司的各种运营数据，供全公司同事甚至外部参观者随时了解，这种信息公开的力度可不是每个企业都能做到的。

勇气

不怕犯错，勇于尝试。在一个新兴行业里，怕犯错就什么都做不了。支付宝在2010年左右被财富通、快钱挤占了很多市场份额，能在2012年后得到好转，就是因为价值观上的一个重要转变，由原来沿袭自金融业务的求稳、不许触犯红线、不能冒险，改为——可以冒险，只要对用户有价值。马云对支付宝员工说，你们尽管去冒险，要坐牢我第一个去。之后，支付宝的策略开始稍显激进，比如说推出余额宝。有一句比较极端的话，“所有的创新都是从犯规开始”，很多公司发展之初都是先打擦边球。当然，我们要有道德底线。各种出行服务的公司，先用创新让政府、社会看到价值，然后让他们自觉做出响应、修改规则，这才是真正的互联网创新，这就叫勇气。

谦逊

承认自己的无知，也是互联网行业很重要的一个特点，它来自“求援”思维。我们经常向专家求援，甚至向用户求援，力争把对方的智慧、能力榨取出来，为产品做贡献。就像经常听到的一个词UGC——用户生产内容，就是很典型的向用户求援的一个例子。事实上，很多内容属性强的产品，里面绝大多数精彩的内容都是用户贡献的。团队配合时也需要每个人能保持谦逊，大家都是各自领域的专家，通力合作才能达成目标。

再来复习一下敏捷宣言：

一、人与人的交互，重于过程和工具。

二、可用的软件，重于详细的文档。

三、与客户协作，重于合同谈判。

四、随时应对变化，重于循规蹈矩。

敏捷的整体思想非常目标导向、结果导向，也非常接地气，以上四条也都很容易理解。我想多说两句的是第三条，它告诉我们要用敏捷的方式做项目，客户方与实施方之间千万不要搞成“甲方”和“乙方”的关系，而要像一个团队一样彼此协作。因为市场变化很快，采取甲方派任务、乙方实施的接力棒模式，响应速度一定跟不上。

最后看看更具体的敏捷十二条原则：

一、对于我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。

二、拥抱变化，欢迎需求的变化，即使在开发后期。

三、敏捷过程能够驾驭变化，保持客户的竞争优势。

四、经常交付可以工作的软件，从几个星期到几个月，时间尺度越短越好。

五、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

六、围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

先聊聊对前六条的想法。

敏捷对团队的要求非常高，它要求团队里每一个人都是独当一面的高手，在能力上非常专业，在态度上非常职业。这样的团队，人均产出很高，因而能保持团队规模足够小，员工福利足够高。我们经常对硅谷某些公司的免费餐饮羡慕不已，但团队整体效能上的差距，才是更显而易见的。

能力不足、新手太多的团队没有办法照搬敏捷的各种做法。比如，没法让新人“认领任务”，只能自上而下地指派任务，因为新人对工作量的评估常常不准；再比如，过于木讷的工程师无法和客户顺畅沟通，只能通过产品经理来传递信息。

职业精神不强会造成更大的问题。典型例子是，绝大多数国内运动员能理解“第二天要比赛，前一天晚上不应该去泡吧”的合理性和科学性，但有的运动员则必须真有这么一个规定来约束自己。我也碰到过一些职业素养不高的互联网企业开发人员，承诺交付日期后屡屡拖延。

所以，敏捷在具体操作层面上，要根据团队情况做一些调整，接着看后六条敏捷原则。

七、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

八、可以工作的软件是进度的主要度量标准 。

九、敏捷过程提倡可持续开发。

十、对卓越技术与良好设计的不断追求将有助于提高敏捷性。

十一、简单——尽可能减少工作量的艺术至关重要，最好的架构、需求和设计都源自自我组织的团队。

十二、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

在具体操作中，敏捷思想认为我们应该和利益相关方、核心团队共同维持一个稳定的节奏，以对抗敏捷造成的随时可变、心里没底的状况。通过一个月左右的时间，让大家形成一种习惯，每一个迭代周期里，第一天做什么、哪几天开发、哪几天测试、什么时候Review……这样建立起来的确定性能够大大增加每个人的心理舒适感。

8.3.2 　 敏捷项目管理的实践

说完了对敏捷方法的理解，再聊聊实践。我经历过的团队，最常采用的是以Scrum方法为原型，再根据实际情况略做调整。下子。事实上，很多内容属性强的产品，里面绝大多数精彩的内容都是用户贡献的。团队配合时也需要每个人能保持谦逊，大家都是各自领域的专家，通力合作才能达成目标。

再来复习一下敏捷宣言：

一、人与人的交互，重于过程和工具。

二、可用的软件，重于详细的文档。

三、与客户协作，重于合同谈判。

四、随时应对变化，重于循规蹈矩。

敏捷的整体思想非常目标导向、结果导向，也非常接地气，以上四条也都很容易理解。我想多说两句的是第三条，它告诉我们要用敏捷的方式做项目，客户方与实施方之间千万不要搞成“甲方”和“乙方”的关系，而要像一个团队一样彼此协作。因为市场变化很快，采取甲方派任务、乙方实施的接力棒模式，响应速度一定跟不上。

最后看看更具体的敏捷十二条原则：

一、对于我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。

二、拥抱变化，欢迎需求的变化，即使在开发后期。

三、敏捷过程能够驾驭变化，保持客户的竞争优势。

四、经常交付可以工作的软件，从几个星期到几个月，时间尺度越短越好。

五、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

六、围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

先聊聊对前六条的想法。

敏捷对团队的要求非常高，它要求团队里每一个人都是独当一面的高手，在能力上非常专业，在态度上非常职业。这样的团队，人均产出很高，因而能保持团队规模足够小，员工福利足够高。我们经常对硅谷某些公司的免费餐饮羡慕不已，但团队整体效能上的差距，才是更显而易见的。

能力不足、新手太多的团队没有办法照搬敏捷的各种做法。比如，没法让新人“认领任务”，只能自上而下地指派任务，因为新人对工作量的评估常常不准；再比如，过于木讷的工程师无法和客户顺畅沟通，只能通过产品经理来传递信息。

职业精神不强会造成更大的问题。典型例子是，绝大多数国内运动员能理解“第二天要比赛，前一天晚上不应该去泡吧”的合理性和科学性，但有的运动员则必须真有这么一个规定来约束自己。我也碰到过一些职业素养不高的互联网企业开发人员，承诺交付日期后屡屡拖延。

所以，敏捷在具体操作层面上，要根据团队情况做一些调整，接着看后六条敏捷原则。

七、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

八、可以工作的软件是进度的主要度量标准[4] 。

九、敏捷过程提倡可持续开发。

十、对卓越技术与良好设计的不断追求将有助于提高敏捷性。

十一、简单——尽可能减少工作量的艺术至关重要，最好的架构、需求和设计都源自自我组织的团队。

十二、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

在具体操作中，敏捷思想认为我们应该和利益相关方、核心团队共同维持一个稳定的节奏，以对抗敏捷造成的随时可变、心里没底的状况。通过一个月左右的时间，让大家形成一种习惯，每一个迭代周期里，第一天做什么、哪几天开发、哪几天测试、什么时候Review……这样建立起来的确定性能够大大增加每个人的心理舒适感。

8.3.2 　 敏捷项目管理的实践

说完了对敏捷方法的理解，再聊聊实践。我经历过的团队，最常采用的是以Scrum方法为原型，再根据实际情况略做调整。下面，先说一下对几个Scrum关键概念的理解。

►团队角色

PO（Product Owner）通常是产品经理，要对各种利益相关方负责。

SM（Scrum Master）充当教练的角色，一般由对流程、方法论比较熟悉的人来担任，不建议这个角色和PO重叠。

Team由核心成员组成，其中的某一个人是可以担任SM的。

►关键产出物

Product Backlog指比较长期的产品任务表，即第06章提到的功能列表。

Sprint Backlog在Scrum里指当前这个迭代里面的任务点。

Burndown Chart是燃尽图，用来监控任务是不是在按期推进。

►重要的会议

首先是每个迭代的计划会 ，经常和需求评审会 合并，主要目的是明确任务，以及评审这个迭代里需要做的功能。

每天的站立会议 ，是重要的信息同步手段。

功能评审会 用来评估做出来的东西是不是想要的。

回顾会 的目的是为了过程改进，因为Scrum和敏捷最核心的思想就是不断优化，以优化出一个最适合当前团队的方法论。

►日常管理工具

看板 是一个非常重要的实用工具，很多公司的办公区里都会有，在硅谷创新公司里也被广泛应用。比如，有一块写着当前迭代关键信息的白板，或者有一面用来粘贴任务卡片和便利贴的玻璃墙，如图8-2所示。

接着，再说一些Scrum实际应用的具体做法。

……

角色的简化

首先，根据业务和团队的现状，对项目进行了合理的角色简化。这还是挺考验经验的，必须见过分工很细的团队，且能理解其中每个角色是怎么一步步分化出来，以及不同角色各自的设置目的，才能做好。当时这个项目的做法是：不区分交互和视觉，用全民测试代替专职测试，运维、DBA等全部由开发承担，前端职能单列出来，最终一共设置四个角色：产品、设计、前端、开发。

流程的简化

同样，需要见过更复杂的流程，知道每一个环节是为了防止出什么状况，才能合理地简化。最后，设置了四个关键节点。这些节点是除了产品、技术、运营之外的其他关键团队成员也要一起参与的，已经没法再减了。

►立项会议： 确定项目目的——为什么、做什么（时间控制在半小时以内）。

►需求评审： 确定项目怎么做（对相对较小的项目，可以和立项会议合并，总体时间控制在2小时以内）。

►功能评审： 简单地讲，就是在测试环境下演示一下产品，以确定做出来的是不是团队要的（1小时左右搞定）。

►发布上线： 确定产品是不是用户想要的，以及用户还要什么。通过获取用户反馈来让产品的优化形成一个螺旋上升的闭环。

以上说的是主流程，还有两个常见的分支流程也简单提一下。

►需求变更 ：这在项目过程中不可避免，一开始可以简化成某个人拍板，决定是否接受变更。

►日常需求： 即零散、随机出现的小需求。开始只掌握一点，即所有需求必须经过产品经理，运营等角色不能直接找开发，确保产品经理知道所有的需求信息，以便统筹安排。

文档的简化

在项目开始阶段，文档只保留PRD、设计稿、代码三件套，其他文档，都用看板、白纸加上拍照留存来解决。既然看板可以代替很多文档的职能，接下来就看看其在项目中的实际应用。

看板实践

看板这种看起来很原始的线下手段，事实上在研发项目过程中特别好用。与在线软件相比，它最大的好处是，所有不时路过看板的人，只要抬头就能看到所有关键信息。

任务卡片

看板里经常用到的基本元素是任务卡片，它其实就是一张如图8-4所示的便签，上面一般会呈现几个关键信息。

►任务描述： 一般是一个词加一句话（如果一个词可以讲清楚，也可以不用一句话）。比如，前端可以写一张叫“Detail页面制作”的任务卡片，产品可以写一张叫“后台订单管理需求细化”的任务卡片。

►工时评估： 对于2～4周的项目，评估精确到1～4小时的粒度比较合理。如果一张任务卡片上的工作量超过8小时，则需要分拆。对工时的评估，一开始不准确很正常，通过每天的站立会议回顾和改进，很快就会越来越准。

► deadline： 写明日期即可，因为人人都信奉deadline是第一生产力。

►优先级： 任务越多就越需要重视和完善这个信息。

图8-4任务卡片的角部，还能看到三个很明显的小标志，这是我们团队的实用小创新。在一张任务卡片相应角部位置做出标记，就表示这一任务具有如下的特定属性，可用来提醒团队注意。

►左上角标： 表示此卡片的任务延期。少量的任务延期是正常的，也是允许的，但要进行监控。如果发现项目里有很多人出现大幅延期，则说明计划制订不合理，需要及时调整；如果只是个别人出现大幅延期，则更可能是个人问题，需要延期人自己加班赶上进度。团队要达成共识，让别人等、浪费别人时间是可耻的。

►右上角标： 表示突发任务。少量的突发任务也是正常且允许的，但如果有大量突发任务，则说明缺乏经验、计划不足，或者有“外力”经常干扰项目进程。

►左下角标： 表示持续任务，可以一直贴在看板的Doing（正在做的）任务列表里。比如，对产品经理来说，“处理用户反馈”就算一个持续任务。而非持续任务都应该从看板的Doing列表及早转移到Done（已完成的）任务列表。

►右下角标： 未定义的备用标记。团队在做项目的同时会不断优化项目流程，如有需要可以临时定义这个新的角标。

还可以灵活运用卡片的不同颜色。比如，我们团队有4种角色，正好对应4种颜色的卡片，这样可以让看板更加清晰。

看板应用

在日常工作中，一个完整的看板应该怎么应用呢？看一下如图8-5所示的看板，其横坐标是Todo（未开始的任务列表）、Doing和Done，纵坐标是各种团队角色。当时，团队每天下班前，也就是18:00开站立会议，大约持续15分钟，会上每个人只说三句话。第一句“今天做了什么”，说某个任务的同时指着看板上对应的任务卡片，如果任务完成，则把卡片从Doing一列拿到Done一列，如果延期了就涂上左上角标；第二句“明天打算做什么”，同时指着Todo一列的相应任务卡片，并把它拿到Doing一列；第三句“碰到什么困难、需要什么帮助”，与大家一起讨论，但不展开，具体的细节可以约着会后私聊。

而Todo里的便签，是平时每个人分解完任务后，随时贴进看板的。

实践中还根据需要确立了一些规则，比如团队里每个人都要轮值汇总周报，以及担任周会召集者。

通过以上项目流程的执行和看板的运用，一个10人左右团队、2～4周一次迭代的研发项目基本可以得到妥善和有效的管理。

8.4 天下武功，唯快不破

8.4.3 　 省时间的低成本验证

单纯为了速度而横冲直撞，是不可取的，也是得不偿失的。那么，如何合理而科学地加快速度呢？答案就是低成本验证。低成本验证的理念，本质上和迭代的思路完全一致：在一个快速变化的环境下，不断地用最少的时间、成本去获取市场反馈，不断修正前进方向 。下面举几个例子。

假设你要做一个交易系统。

正常的交易流程一般叫作“正向交易”，要满足买卖双方之间下单、付款、发货、收货等常规需求，是交易系统必备的。但是，“退款/退货”这种“逆向交易”要不要做呢？做的话，系统复杂度会大幅增加，实际工作量不只翻倍，往往会超出3～5倍。

怎么办？可以这样低成本验证：先在线上做一个假的“退款/退货”按钮，用户点击以后，系统直接给客服人员发邮件，由客服人工完成处理。这样运行几周后看看效果。如果客服只收到几封邮件，那么就继续采用“人肉”处理；如果收到的邮件多到人工处理不过来，就可以理直气壮地上系统了。

除此之外，不轻易做系统还有一个现实意义：上线容易下线难。功能上线后，如果只有很少的人在用，就会陷入尴尬境地。如果下线，这些在用的人会跳起来说：“我用得好好的功能，你们为什么要下线。”而如果迫于这种压力，勉强继续维护着这一功能，一方面有成本，也很吃力；另一方面后续新功能也必须考虑和这个鸡肋功能的兼容、协作。

现在的很多创业项目，启动阶段先做微信公众号、H5页面，而不是App，一个主要的出发点也是低成本验证。这么做，开发人力的成本可以低一些，用户获取的成本可以低一些，功能调整的成本也可以低一些。用一个简单的产品雏形把业务逻辑先跑通，然后再考虑是否要做客户端，是很值得推荐的产品策略。

再来一个案例，假设你想做一个垂直领域的导航站。

这个站点可以告诉创业者，创业过程中都会碰到哪些问题，可以用哪些服务解决，可以去什么站点获取资讯。我的建议是，先不要做网站，而是把精心整理的各种资料，通过一篇高质量的文章来传播，收集阅读、收藏、转发的数据，或者挑一些目标用户来问问反馈，再决定下一步怎么做。

最后来说一种有趣的低成本验证方法——利用公关手段。

经常看到阿里PR稿件中出现“阿里又要推出×××”“阿里开始进军×××”“阿里正在秘密研发×××”这样的标题，而这很多时候都是有意为之的小动作，甚至产品、技术团队都毫不知情，更谈不上真正开始投入资源了。而很多对手会被带到沟里，开始研究对策、排兵布阵。

大机构想推出新政策的时候，先借助合适之人如专家的嘴，或其他渠道如非官方媒体、小道消息等来透露给社会大众，试探他们的反应，得到相应的结果后，或顺水推舟地证实，或矢口否认地辟谣。不用担心最终没做会辜负期待，用户总是很健忘。回顾一下以往的新闻，能想到很多这样的例子。

广义的公关之法，其本质就是先不做，却告诉受众我已经做了，从而收集反馈，其优势在于成本非常低，验证非常高效。

小结一下，低成本验证的核心，就是看谁能用更少的资源、时间等成本，拿到一些假设是否成立的结论，而更深层次的目的，还是为了更好地服务用户，更好地达成公司的商业目标。

8.5 与用户一起成长

8.6 延伸阅读与练习

第09章 运营：先验证再扩张

9.1 产品与运营的关系

前面几章介绍了如何把一个产品想清楚，然后一步步做出来。本章将进入下一大模块，谈谈如何将一个产品推出去。这个模块属于“大运营”的范畴，包括运营、销售、市场与品牌等话题。

本章先说狭义的运营岗位，它在互联网团队中往往是作为产品经理的冤家出现的。然后，再说说各种广义运营要做的事情。

如果有人问，产品与运营之间是什么关系？

我会这样回答：“自古以来，运营就是产品不可分割的一部分 。”

真正的产品经理要对产品的最终结果负责，所以必须要懂运营；而运营，却很少被要求负责“把产品做出来”。比如在阿里巴巴，当产品经理达到一定层级的时候，就必须要具备一定的运营知识。这两种角色的轮岗很常见，而在大公司里如果晋升到总监级别，这两个岗位的任务其实殊途同归。

如果一定要有所区分的话，那么产品经理的职责是将产品做出来，保证其“有用”，而运营的职责是将产品推出去，保证“有人用”。

经常会遇到这样一个衍生问题：在公司里，运营和产品谁说了算？有些公司运营一直压制着产品，有些公司则产品比较强势，而这种强弱对比关系背后是由公司的业务形态决定的。互联网界有“百度的技术”、“腾讯的产品”、“阿里的运营”这样的说法，就正好与BAT各自的业务特点一一对应。

“谁说了算”这个问题，在俞军给淘宝当产品顾问时，给出了我认为的终极答案：“谁懂用户谁说了算 ”。

实践中，可以通过对比以下两点来相对容易地识别出，在公司里究竟谁更懂用户。

►谁更资深：一个产品新人和一个工作5年的运营，那当然是运营说了算，反之亦然，这往往直观地体现在岗位级别上。

►谁对结果负责：只要高层是清醒、理性的，那么把产品的最终结果交给谁负责，权责利就要对等，负责的角色就要有决策权。

……

故事讲完了，好像一个简单的广告宣传片也设计好了。如果在产品的早期阶段就能对“用户需求场景”理解得很透彻，那么“卖点”的提炼往往可以水到渠成。由此也可以看出，产品和运营这两个角色的确应该紧密合作。

给用户讲故事的重要性同样适用于很多工作场景。对于在公司里工作的人来说，讲故事就是说服老板、打动同事；对于创业者来说，讲故事就是说服投资人给钱、给人、给时间，说服一票人跟着你累死累活，说服合作伙伴与你拴在一条绳上……

这种说服能力，不但对运营重要，对产品经理也一样重要。需要知道，产品经理的一项重要技能就是无授权领导，而想要一群人配合你一起做事，施加压力不如获得认同。从某种程度上讲，获得认同后的无授权领导比有授权的领导效果更好。第一，能说服很多人认同的事情，靠谱的概率总会高一些；第二，用权力压人是让别人“要做”，而无授权是让别人“想做”，真想做事情就好办了。

9.2 运营工作的分类

回到运营岗位本身，看一看这个岗位主要要做的几件事情。

从方法视角来分类，内容运营、活动运营、用户运营 是最常听到的几种运营岗位。

……

最后，聊聊第一批的种子用户如何获取，也就是冷启动的问题。产品的验证就是从种子用户开始，如果你的产品可以匹配上如下这几个人群，那不失为一个好的开局。

►学生党： 年轻有好奇心，愿意尝试各种新产品，有大把的时间，但没有钱，容易用小额利益撬动，而且人群密集，获客与社会化传播的成本都较低。比如当年的校内网，用免费的鸡腿，拉了很多学生用户。

►美女： 不管在何种产品里，美女用户都是焦点，满足她们的优越感、存在感之后，其他用户就会源源不断地被美女吸引过来。社交类的应用，通常更适合走这条路。这类用户的本质是那种可以以一带十、以一带百的焦点人物，比如自带流量的大V明星。

►羊毛党： 这个词从形容贪小便宜的说法“薅羊毛”而来。这群人是最容易用补贴撬动的，但风险也大，要好好思考他们到底是不是目标用户，有些理财产品选择了羊毛党作为种子用户，而这群人也正好是爱财的人。

►竞品用户： 竞争对手那里，产品的目标用户的密度自然也最高，而且竞争对手已经帮我们筛选过的，往往是真正的优质用户。比如小米最早的100个用户，就是从一些手机发烧论坛里找来的，这类论坛也可以算是广义的竞品，和小米手机是行业上下游的关系。

有了种子用户，服务好他们非常重要，小米在产品早期的做法是很好的榜样：

每年的发布会，更多是为了“米粉”而不是媒体而办，最终成为用户的狂欢。不完美的产品，通过“内测”直接送给粉丝，一方面成为福利，另一方面又能更早获取到市场反馈。小米社区的运营理念是，让用户帮助产品优化，决定一些功能的优先级。种子用户选取“发烧友”人群，因为他们是意见领袖，能影响很多身边的人。

爆发，脱离种子阶段

经过验证期，对产品优化效果满意后，运营就要开始发力，迅速扩散产品信息。市场留给产品的时间窗口往往不大，容不得慢慢打磨。

爆发期的主要运营工作是拉新。经常听到的打广告、烧钱、借力用户、做事件等，都属于拉新行为，目的是尽快把目标用户吸引过来。在这个阶段竞争的是谁能在时间相同、资源相同的情况下获取更多的用户，因此需要研究各种推广渠道，包括搜索广告、线上线下媒体广告、户外广告、社会化广告，以及各种论坛、社群，或是借力名人，等等，还需要思考什么策略和产品最匹配。这是一个很大的话题，本书不再展开。

回忆一下本书前文提过的四级用户：种子用户→核心用户→目标用户→潜在用户。

在这个阶段，要迅速把产品从（第一级的）种子用户手里至少推到（第三级的）目标用户手里。看看滴滴公司的例子。

9.3 大运营的其他职责

本章的最后，提一下大运营的其他职责——销售、服务、市场、品牌、公关等。由于已超出本书主题范围，只能点到为止，作为更多延伸阅读的引子。

9.3.3 　市场的几种分类维度

市场工作和狭义的运营有点像，不过市场需要更加高举高打，才能为产品的大环境造势。如果说销售是陆军、运营是空军，那市场就是导弹部队。

产品面对的市场，有几种常见的分类，各自对应不同的产品策略。

一种分类是将市场分为全新市场、旧有市场、细分市场。

►旧有市场，也叫存量市场。 要有突出的产品优势，比如更便宜、质量更好、获取更便捷等。这是种子用户和主流用户区别最小的市场，跨越鸿沟最简单，但竞争激烈，后进者营销成本巨大。旧有市场里，产品和用户都很成熟，用户对产品非常熟悉，因此要“尊重用户习惯”。

►细分市场，也叫小众市场。 介于现有与全新之间，要突出小众特色，找到差异化定位。如果你能做出与众不同的产品特色，就可以在现有市场里打开一个细分市场。

►全新市场，也叫增量市场。 要突出产品能解决的问题，此时做品牌推广意义不大，而是要有一个较长的客户培养期。可以通过小众市场切入，寻找巧妙的“引爆点”。做全新市场最担心的问题是帮别人教育用户。比如，线下商铺在支付宝的教育之下，普遍意识到手机支付的便利性，微信支付再来推广就容易多了。

另一种分类的维度：这个市场到底是供不应求还是供过于求，据此可将市场分为买方市场 与卖方市场 。如果我们想做“卖家”，那显然要挑选一个供不应求的市场；如果我们想做“平台”，那就应该努力维持市场里的供需平衡。

9.3.4 　品牌到底是什么

品牌是一个更加抽象的概念，是一个公司所有经营活动的最终沉淀，需要很多年的积累。所以，它也是产品发展到相对成熟的后期，才需要投入重兵做的事情。公司发展到最后，沉淀下来的不会是资金、产品、运营这些东西，甚至不是人才，而是品牌。

品牌建设的工作，表面看起来和市场运营差不多，不外乎投放广告、写文案、营销策略，甚至玩心理。但其本质是一种心智的占领，是要让用户对这个品牌有一种死忠的信仰。品牌做到极致，就会出现这样的粉丝，“为信仰充值”这么空洞的理由，就足以驱使他们毫不犹豫买下钟爱品牌的新款产品。

当然，品牌效应能达到这个境界的产品，实在凤毛麟角。

9.3.5 　公关是企业的戾气与利器

公关也是隶属于大运营的概念，又叫PR（Public Relationship，公共关系）。说公关是企业的戾气，是指他们会表现出杀气很重一面，会做出控制言论、操纵认知的事情；而说公关是企业的利器，是指他们又有可能成为厉害的制胜武器。2005.20.0　年间，业内有云，业界PR看阿里，阿里PR看淘宝，下面就简要回顾一下当年淘宝公关负责人指导我的一些要点。

►要点1：（他认为）对CEO来说，真正的上层建筑是CFO、HR、PR，下面才是市场、运营、销售，以及产品、技术、设计，等等，越大的公司越是这样。

►要点2：公关的实践方法就是断言、重复、传染，也可称之为洗脑。先断言让大众产生某一种想法，再利用各种渠道不断重发，然后再持续地传播。

►要点3：公关执行的四要素包括：对谁说——选择一个对象；说什么——具体要传达的观点；谁来说——哪怕同样的话，不同的人来说效果也会差异极大；怎么说——选择什么渠道、用什么技巧来说。

►要点4：分工使然，PR少不了要为企业做很多打打杀杀的事情，个人也会因此显得杀气腾腾。举个例子，2015年Uber和滴滴正在打仗。当你打Uber总是打不到，与司机的互动体验也极差，会把一气之下截的图和录的音发给Uber还是滴滴？产品人基于产品改进的思维惯性，更倾向发给Uber，而公关人习惯一刀毙命，可能会发给滴滴。

最后，这位高人还送我一句需要琢磨很久的话：组织要成大事，通常是一面佛一面魔，一个高手，也常常一念成佛一念成魔。

9.4 产品的生命周期

至此，已经讲完了一个产品的各个方面，最后再从产品生命周期的不同视角来做个总的回顾。

从验证期到衰退期

产品在“验证期→爆发期→平台期→衰退期”这个完整生命周期的每个阶段，都需要面对和实现不同的运营目标。

从定位、需求到品牌

从企业发展层面来看，依次要经历定位、需求、产品、流量、用户、收入、盈利、品牌这些阶段。对应要做的事情有：给产品定位→采集需求回来分析→做产品功能→产品上市以后要获取流量→把流量转化成有价值的用户→从用户身上获取收入→实现盈利→沉淀为品牌。

真正产生商业价值，往往需要等到盈利这一步，因为前面几步的所谓商业价值，是有可能通过作假来体现出来的。有一个投资人受骗的故事，它有意思的地方在于，行骗的创业者并未在流量和用户规模等数据上做文章，而是直接针对“持续付费用户”这个指标作假，方法很简单粗暴：推出第一单9.9元、第二单0.1元的洗车优惠活动，轻松拿到一个漂亮的持续付费（定义为至少付过两次钱）用户数。

想清楚、做出来、推出去

一个产品从无到有的全过程，从团队的主要工作内容角度，可以划分为以下四个阶段。

►创意设计： 问题正确，解决方案靠谱——用户还没用上产品。

►研发生产： 做得出来，不断优化——极少量种子用户用上了内测版本。

►运营销售： 卖得出去，赚得到钱——尝鲜者、早期采纳者使用产品。

►市场品牌： 铺得开，叫得响——主流用户使用产品。

第一个阶段要“想清楚”，第二个阶段要“做出来”，第三、四个阶段要“推出去”，而在最后两个阶段之间，就会碰到图9-7中的鸿沟问题，这在本章前面的小结中已经有过阐述。

9.5 延伸阅读与练习

第10章 案例：商业模式、创新与行业

10.1 聊聊商业模式

下面，用产品视角来重新解读一下这些要素。

►客户细分：我们的目标用户是谁，其中最重要的又是谁。

►价值主张：我们可以帮用户创造什么额外的价值。这里所说的价值必须是现有产品服务没有的，比如更高的性能、更低的价格、更小的风险。

►客户关系：用户与我们、用户与用户之间的互动模式是什么，比如专人一对一服务、用户自助使用、用户彼此共建社区，等等。

►渠道通路：如何与用户建立起高效联系，拉近现实与心理的距离。

►关键业务：我们需要做什么产品来解决用户问题，创造价值。

►核心资源：我们做这件事，和别人相比，有什么特别的优势因素。

►重要合作：我们需要和哪些上下游、周边伙伴协作，以及如何协作。

►收入来源：如何从用户那里获得收入，以维持业务可持续发展。

►成本结构：做这件事，都在哪些环节需要花钱。

如果想了解更多，推荐大家看《商业模式新生代》以及《商业模式新生代·个人篇》。

10.2 创新那点事儿

10.2.2 　创业公司的创新坑

若干年前，我可以很确定地说，我是个产品经理，而现在的身份却有点复杂——自己在创业，是团队里的产品经理、创业项目的目标用户，又是创业者与产品经理。每天在各种角色之间切换，让我有机会从多个视角看到和体会到创业者在做新产品时经常犯的错。其实，在大公司里做新产品也大同小异。

“这个idea不能跟别人说”

不要怕泄密，如果仅仅听了你的idea就能超越你，那只能说明你的优势确实很有限。

见过的产品越多就越觉得，自己能想到的每一个idea，一定已经被无数人想到过，甚至试着做过。从概率上来讲，真的发现一个“秘密”的可能性微乎其微，绝大多数情况下只是我们孤陋寡闻。所以，与其藏着掖着自己嗨，不如找到一些合适的人一起来探讨idea，以减少冒进的风险。当然，也不用拿着大喇叭到处广播，那叫立flag 。

idea与成事，好比捡到一个鼠标垫与组装出一台电脑。事情是做出来的，“想到”毫无意义，做的过程中发现的“秘密”更有价值。同理，这句话也毫无意义：“你看，他们和我想的一样，我们还是慢了”。

“我们就差个程序员了”

当然，我们说的创业是有创新成分的创业，而不是开个店做生意。前面已经说过，创新成功必须要克服两个风险，市场风险（真的有用户需求）和技术风险（能做得出来）。

但很多创业者总认为自己的想法没问题，而且经常越想越兴奋，但苦于没法实现，只好把问题归结为“就差一个程序员来做了”。但当你真的组建了一个不大不小的团队，包括程序员和设计师、测试、运维等，结果也只是在创造了一个没人需要的产品之后不了了之。其实，比程序员更缺的，是产品经理，没找到真的用户需求之前要谨记——不要开始，不要开始，不要开始，重要的事情说三遍。

“别急，我们要憋个大招”

有的创业者，前期确实做了很多功课，在某时某刻也确实想清楚了。但问题在于，他们接下来的做法是开始憋大招，准备封闭开发三个月，一举成名天下知。他们这个做法很像“发射火箭”，做好各种准备并按下发射键后，就只能等着结果，什么都做不了了。但创业之所以难，就是因为过程中市场和用户都在不停变化，会不断碰到新的问题，获得新的信息。如《精益创业》所说，创业更像是“开汽车”，你并不知道在前面那个路口会碰到红灯还是绿灯，也不知道什么时候会出现一辆不守规矩的车要强行超车，或者出现一辆车变道不打灯，同样不知道接下来的一段路会不会堵车……

憋大招的结果，往往是在出关之时发现天下已经改朝换代，自己的产品只能很被动地做出很多调整，才能适应新的用户需求和市场环境。

“我觉得用户一定喜欢”

有一种冷叫“我妈觉得我冷”，有一种用户需求叫“我觉得用户有需求”。做产品的过程中，最重要的事情就是不停地接触用户。多年的经验告诉我，每当自己对产品很满意，信心百倍地拿去给用户看时，还是会发现用户很困惑——不是不理解你要表达什么，就是找不到某个功能，于是满脸无辜地问你——我为啥要用这个玩意儿。

所以，有一句很重要的话——等到你敢拿着产品去见用户的时候，一定已经晚了。这个问题的解药，只能是摒除主观意愿，想方设法去体会用户真正的痛。

“给我盯着×××，先抄后超”

盯着“抄”，不管是盯一个还是盯多个，最终都很难“超”，最多只能跟在后面。这反映的是竞品分析的思路，我们不能仅仅盯着别人的产品功能来研究，而是要思考同类产品到底是在解决用户的什么需求，有没有更好的解决方案，或者还有什么新的产品形态没有出现。这个话题在第03章有详细的讲述——打败新浪微博的肯定不是腾讯微博，而可能是微信的朋友圈；打败C2C平台的可能是B2C平台，所以淘宝自己做了个天猫；对出租车司机这个用户群体而言，打败某个汽车电台的不是另一个电台，而是打车软件；打败实体书的，也许不是电子书，而是一些音频、视频节目。

“不怕，我们有资源”

这句话经常出自一些传统行业想转型互联网的创业者，没错，就是大热的“互联网+”催生的跃跃欲试者：有钱，有关系，有各种行业资源。

资源很重要，因为人类社会经历了上千年的短缺经济，供给驱动的模式是常态，只要能把产品做出来，不愁卖不掉。但最近几十年，互联网行业越来越走向丰饶经济，我们使用某类产品的选择都太多了，需求驱动变成了常态。

这样的时代，创业者必须有强烈的用户意识，认识到懂用户、了解需求才是我们取之不尽用之不竭的“资源”。当然，传统行业与互联网的融合，的确能够发挥更大的威力。

“找到风口，找对赛道”

站在投资人的立场上，肯定不认同这一条。因为投资人就是要追风口的，和创业者的目标、逻辑本来就不同。

每一次创业，其实都是过往经历的一次变现。值得认可的创业者，他做的事情要能够看到一条清晰的轨迹。这个轨迹可以表现初心，这种初心一般不能是为了赚钱，而应该是一种使命感。比如陈琪（前阿里人，现美丽联合集团CEO）前后的几个创业项目“琳琅国货”、“卷豆网”和“蘑菇街”，就有明显的关联性。既然选择创业这条折腾的路，就一定要为自己而创业。否则，从前为公司的老板打工，现在变成为投资人打工，并没有本质区别。创业就应该做一件自己非做不可、就算失败也心甘情愿的事情，这才是原动力。如果这件事情正好在风口上，就是锦上添花。

说完新产品创新的坑，再说说成熟业务的创新路上，会碰到什么问题。

10.2.3 　大型公司的创新坑

还在阿里时，我就拜访过不少投资人，他们挑选早期项目的普遍原则是——先看人，后看项目。因为项目做着做着就会变，而人的能力是实打实的。君不见，知名天使投资人投的项目，团队核心成员都是星光闪闪的人物——大公司高管、海龟、名校、有成功经历……而在内部，来赛马的多为基层员工，换言之都是那些手里没资源的人。但凡有点资源的，也不用通过赛马这样的通道来实现想法。这样的选手和团队，创业成功的概率更低。

后来，赛马也经历过几次调整，比如从“内部创业”到“微创新”，从淘宝走向集团，以及相比机制更加重视文化等。我负责的那一年，还有两个创新尝试值得分享给其他大公司。

一是承载“新型组织形态探索”的任务

其初衷，是我们坚信，每个员工在做自己喜欢的事情时，会比做公司分派的任务要高效。将来的公司组织形态，一定不是今天常见的科层制，也许会有美国大片里组队做任务一样的“任务制”作为补充。随着各种工具、技术的发展，专业人才重于管理人才，我们感到越来越多的事情可以这么做。赛马希望让这些组织，可以通过自下而上的方式形成，真正地做到“召之即来，来之即战，战完即散”。

二是“创新文化”的宣导

赛马虚实结合，将“虚事实做”作为组织文化来贯彻，这是阿里的强项。举个例子，我们从2013年开始，更多地和选手这样沟通：创新本身就是一件失败率很高的事情，公司在早期也不会对你的项目投入太多。虽然我们也说20%（早年Google允许工程师拿出20%的时间来研究自己喜欢的项目），但Google是100%时间里的20%，我们是120%时间里的20%，你必须先做好本职工作，再额外的创新。所以，你应该做一件自己真正感兴趣的事情，做那种不管结果如何，只要去做，过程就很开心的事情，而更重要的，是过程中的成长。

看过一本书，叫《创新者的窘境》[6] ，书里认为大公司很难内部创新。我对此基本认可，但随着“公司”定义的变化、内外界限的模糊，一切又变得难说起来。基业无法长青，公司总会被打败，但如果是新的自己打败旧的自己，那就并不是一个不好的结局。而这就需要鼓励创新、容忍犯错，允许奇怪的东西长出来……我们只要坚信，创新是人类的天性，是生命对抗宇宙“热寂”的方式，就够了。

10.2.4 　传统企业的创新坑

产业升级、传统转型、供应链改造、新零售、互联网+这些词从2016年开始越来越火。这一节主要说说那些想转型互联网、和互联网搭上边的企业，会碰到哪些坑。

10.2.5 　再谈创新者的窘境

为什么过去的成功反而会成为创新的阻力，这里的问题在《创新者的窘境》里说得比较透彻：

所谓的“窘境”，就是说管理良好的企业，由于它的管理良好，使得它对于一个特定的“价值网”（我更愿意叫它“生态系统”）很成功，也正是由于它的管理良好，或者说，是对于某生态系统的过度优化，使得它遇到另一个新的“生态系统”时，会遭遇失败。

这里不同生态系统的此消彼长，也就是《浪潮之巅》[7] 里说的“浪潮”。

具体来说，成功公司的常规管理方法是：

►听取消费者的意见，大力投资他们希望得到进一步改善的技术。

►争取更高的利润率，以更大的市场，而不是更小的市场为目标。

而在碰到新兴生态系统时，现在的成功企业无法进入的原因如下：

第一，企业的资源分布取决于固有的消费者、投资者与合作伙伴，而不只是内部员工，更不是几个高层管理者，整个产业链的既得利益阻碍企业对资源进行重新分配。

第二，新兴生态系统刚出现时，规模太小，无法满足成功大企业的增长需求。新兴生态系统利润率相对较低，这很容易理解，正因为利润率低，所以才会后出现，这是大企业不愿意进入的重要原因之一。所以，大企业总倾向于向利润率更高的高端市场发展，这样就给新兴生态系统留下了一个低端切入的口子，而新兴生态系统又会不断进化，直到足以挤占旧有生态系统的部分生存空间。

第三，技术的发展，通常会快于市场需求，所以新技术在不成熟时的“指标落后”，往往是暂时的，而当一个产品的“功能 ”基本完备，消费者的需求重点会逐步转移：从可靠性 到便捷性 ，再到价格 ，而越往后的需求，往往越是新技术擅长的。等到开始拼价格的时候，这个产品就彻底沦为一般商品。大公司在技术上不会落后，只是被旧有生态系统捆住了。

第四，新兴生态系统，也体现在“消费者”是新的，成功企业若执着于现有的客户，是找不到这个市场的。

第五，现有的市场分析方法，无法应对变幻莫测的新兴生态系统。新市场里，没办法提前规划、计划，试错是常态，这是大企业不擅长的。大企业面对的竞争，不是一家新公司，而是冲入新兴生态系统的海量小公司。从概率上讲，小公司必然有一家会成功。

我曾用下面这个攻山头的故事打过一个比方，而这也是10年前阿里在面对电子商务这个新兴生态系统时的做法。

一支看上去人很多的部队，实际上是十支集合在一起的游击队。进攻之前，领头的发现没时间探路，没时间研究，心想干脆不探路了，当年干游击队的时候拼的就是人品。于是召集所有兄弟开了个统一思想的会议，言明攻下这个山头的高尚动机与社会价值。然后，十个队长带着兄弟们高喊着“为了×××，冲啊”，从四面八方涌向山头，十支敢死队也许死了八、九支，但只要有一两支冲上去，就胜利了。

预测和规划的成本大到不如冲上去直接干的时候，故事里的做法变成了一个很好的选择，因为快才是最关键的。当然，这对公司里的个体未必有利，优秀的员工通常不愿意作炮灰。阿里调和这一矛盾的办法是提出“拥抱变化”的价值观，这也是哲学上化解局整矛盾的一个实例。如今的互联网创业环境，也有类似攻山头的局面，每个领域都有很多队伍去试错，如果你想看清楚路再出发，等你上山之后，总会发现已经有人误打误撞登顶了。

回到大公司视角，如何应对这种局面？《创新者的窘境》里也给出了方案，我融合自己的理解来阐述一下。

简单地说，无非是从大企业中独立出一个机构，让其试水新兴生态系统。这个机构可以去找新的消费者与市场，可以满足于较少收益，可以有独立的流程 和价值观 ，并且可以获得大企业源源不断的资源 支持。

这其中的流程与价值观，体现的是公司脱离于个人和其他资源而自有的机构能力。流程是公司在从输入到输出的过程中，人们所采取的互动、协调、沟通和决策的模式。价值观是在确定决策优先级时所遵循的标准。

但是，我还是对大公司不乐观。毕竟，一个大企业又能“生”出多少个这样的独立机构呢？潜在的新兴生态系统那么多，又怎么能找准呢？大公司唯一的优势就是可以输入资源，比如思科做得就不错（想了解更多的读者可以上网查找相关资料）。大势上，胜利者总是那些不怕死的，冲进各种潜在新兴生态系统的海量小公司，最终有极少数新兴生态系统存活下来，其中又有极少数小公司存活并成长为大公司，开始面对被新的小公司打败的危险，这就是整个商界生生不息的内在机制。

和生物体一样，产品是活的，公司是活的，生态系统是活的，都有自己的生老病死，而死亡，是宇宙最伟大的发明，这又让我很乐观。

10.3 行业案例分析

10.4 延伸阅读与练习

第11章 蜕变：从产品助理到CEO

11.1 在人力资源部做产品经理

11.2 产品经理的七层修炼

11.2.1　第一层，需求细化与研发跟进

如果你每天的工作都是写PRD、画原型、做Demo的话，那基本就是刚刚入门。你接到的是一个相对明确的任务，要能听懂，所以需要不少领域知识；要产出给技术人员看的需求文档，所以要懂点技术；要制作给设计人员看的原型，所以要懂点设计，这都是入门的基本功。

接下来，你会觉得自己有点像一个监工，在项目过程中负责盯需求对应的功能是否按时开发、测试、发布上线，这很考验“催功”。这个阶段，有三招是必须学会的，如果你已经在带新人，不妨学会后再传授给他。

这三招，一是做客服 ，二是写 TC（test case，测试用例，是测试人员编写的用来指导测试执行的文档），三是请吃饭 ，分别对应着熟悉用户 、熟悉产品 、熟悉团队 这三种目标能力。

做客服

做客服是为了真正了解目标用户是谁，他们的需求场景是什么。

原来阿里B2B的某个团队，只要是新招来的产品经理，必须先去客服部门轮岗三个月。这段时间做下来，每个新人都会很清楚现在产品的用户都是一些什么人，哪里让用户不爽，哪些改进点重要，哪些不重要……这种感同身受，是看再多的客服反馈报告也体会不到的。当然，轮岗三个月的做法，只有在公司资源很丰富的时候才可以施行。

如果做不到轮岗（哪怕一周），也有简单一点的做法，比如去听客服电话，浏览、回复客户反馈，只要每天下班旁听2、3个小时，多看看客服妹子的白眼，坚持几周，就会不一样。

我的孵化器里有一个做夜店社交的团队，我给他们的建议只有一句话：团队每个人，每周必须去泡一次夜店。

写TC

写TC是要真正了解产品的各种细节，以及每一条逻辑规则，顺带着了解技术。

TC可以理解成是从测试的视角写的产品描述。测试人员与产品经理的逻辑不同，产品要抓大放小，测试要想清楚各种边边角角。

如果团队正好没有TC文档，你可以来写一遍，很快就可以对产品的各种细节了如指掌，比如每一个模块背后用到了哪些技术，有什么之前为了某种妥协而埋下的坑。如果团队已有TC，你可以仔细阅读一遍，绝对比读产品文档更能了解细节，读的同时跟着做一遍测试，可以更快速地熟悉产品。

设想一个场景，某次需求评审会上，当讨论到某个细节时，大家都记不清了，只有你能脱口而出，绝对能让众人对你的信任度大大增加。

请吃饭

请吃饭是为了真正了解所有要合作的人都是什么性格，有什么喜好，甚至最近开心不开心。

产品经理的时间经常不够用，用来一个人吃饭太奢侈。一定要找人一起吃饭，技术、设计、市场、运营都可以，胆子大也可以拉老板一起，只要不是一个人就好。

我们算一下，一周工作5天，5顿午饭，5顿晚饭（基本上，干这行的很难不在公司吃晚饭），每顿和不同的人一起吃，一个月就可以认识30多人。这样吃下来，工作中经常有交集的同事，几乎都有了非工作场景下、非正式的沟通。

很多时候，你找技术提一个需求，他回答“做不了”、“没空做”，还是“我想想怎么办”，只取决于你和他熟不熟，这是真的。

类似地，如果你是烟民，可以约同事一起抽烟；如果你是运动爱好者，可以和同事一起打球、爬山……在良好的文化氛围下，做朋友与做事，可以相互促进。

最后，不要忘了问他一句：作为一个产品新人，现在没人带我，我应该怎么做才能快速上手？

以上三招，虽然又笨又花时间，但胜在简单有效，能帮你快速跨越第一层。悟性好的同学，三到六个月就能进入第二层，最慢的一两年总够了。

11.2.2　第二层，主动挖掘与项目管理

11.2.3　第三层，完整产品与大局观

11.2.4　第四层，产品线与带团队

11.2.5　第五层，成功案例与影响力

11.2.6　第六层，商业闭环与全职能管理

11.2.7　第七层，自己成功到助人成功

11.3 十年后，再无产品经理

11.4 归宿：无非广义创业

11.5 从生活态度到社会推动力

最后一节更感性一些，聊聊“产品经理”到底能给这个时代带来什么价值。不管你是在创业、做产品，还是从事某种职业，甚至失业在家，产品经理的思维方式和做事方法都很有帮助。“人人都是产品经理”，对个人来说是一种生活态度，对社会来说更可能成为进步的推动力。

11.5.1 　先说生活态度

2013年家里装修期间，我就屡屡体会到产品思维的价值。一开始你就会碰到一种叫“设计师”的人，在我眼中他们就是产品经理。和他们接触的第一件事，就是被采集需求。有以下两种采集方法，第一种更为常见。

1. 想装成什么风格。

你的书房是怎么规划的？是专门的书房，还是要兼客卧？要不要做榻榻米？

卫生间需要浴缸吗？

厨房要敞开式吗？

要不要吧台？

……

2. 有什么个人偏好。 你喜欢哪种文化？

喜欢哪些材质的东西？

您喜爱阅读吗？一般何时会阅读？家里什么场所是您有可能阅读的区域？家里藏书是否丰富，多为何种书籍？

一个阳光明媚的午后，您和家人在家会如何安排？请假想一个在新居中最理想的生活状态，描绘一个场景或故事。

工作日下班回家直到睡觉前，全家人都做些什么？

你之前住的房子，有什么装修上的遗憾？

……

不知你体会到没有，第一种用户调研犯了我们常见的典型错误——向用户要解决方案（问用户需要什么功能）。而第二种，是比较高级的做法——去了解目标用户面貌、生活工作场景，从中发现需求和问题；然后应用设计师的专业领域知识，给出更好的解决方案。很显然，第二种设计师更好，当然价格也更高。

在具体的装修过程中，作为一个做产品的，也会把各种方法和思维方式加以应用，说几个具体的细节。

客厅主灯： 做了三控，场景是进出大门的开关、离开客厅的开关、坐在沙发上不用起身的开关。

踢脚灯： 放在次卧门口，用光线感应，场景是老人起夜时次卧到卫生间之间自然有光。

浴室柜： 会考虑下柜高度75cm，加上台盆16cm是91cm，上台盆不能太浅，否则水容易撒出来。还要考虑加上龙头18cm有多高，站在那里，模拟每个家人的身高，感受上柜下沿应该多高，再考虑下沿和龙头上部距离是多少，能否增加用来放刷牙杯的隔板，以及杯口上沿与上面镜柜的距离，是否方便取放牙刷……而镜柜厚度，还要考虑与吊顶射灯的位置关系，如何让光线正好在镜面和人的站立面之间照射下来，并尽量靠近镜面，这样可以把脸凑近镜子使用。同时，因为吊顶盖板300.3.0　mm的尺寸问题，又要考虑工艺限制。

毛巾/浴巾架： 要考虑到洗澡前后和洗脸前后的多个场景，在什么地方最方便？洗澡前脱下的脏衣服放哪里？洗完后要穿的干净衣服又放哪里？

书桌： 如何摆放，取决于白天用得多还是晚上用得多，白天用得多要考虑光线的方向，如果看书比较多，最好用自然光以省得开灯，如果用电子屏幕多，又要避开强光。

厨房： 要考虑食材储备区域（柜子、冰箱）、备餐区域（水槽、切菜台面）、烧菜区域（灶台）、烧完区域（放装菜的盘子、锅什么的）、微波炉/烤箱/电饭煲等空间分布的合理性。甚至，我会因为左利手（我是左撇子）、右利手的问题，考虑一些柜门开关方向的设置。

……

很多想法，都是我闭上眼睛，想象着将来在家里的各种“用户”、各种生活场景以及各种可能碰到的问题 ，或是通过从这里走到那里、或站或坐、或走或停、拿这个放那个而提出的需求。很少有设计师会帮你想这么细，只有当你把其当作自己的产品 时，才有可能如此琢磨、如此用心。

生活中，处处皆产品，处处可用心。

11.5.2 　再说社会推动力

我相信，很多看这本书的人都会觉得，中国的民众素质还有很大的提升空间，比如经常能在网络或社会新闻里，看到很多不妥的言行。为什么这样？我仔细思考过这个问题，觉得主要源于两种思维模式。

第一种，只会照做

照着做，最大的问题是没有创新，一代不如一代，最后创新精神就彻底死掉了。

但比较可怕的是，“只会照做”似乎是一种被赞扬的传统美德，从古代的“君臣父子”、“三从四德”，到现代的“你要听话”。这样的思维模式，在社会变化缓慢的情况下也许有效，在只需要执行的岗位上也许有效，但对于如今剧变的社会，对于想求新求变的个人和组织，一定是一个巨大的负面影响。

而“不照做”、能创新，需要很强的综合能力，背后的动力来源于上一节提到的多样性——团队成员要兼容并蓄，个人也要有广阔的视野与知识面。1952年全国高校院系改革，把复合型人才的培养模式转为了专才的培养。这种模式使得有知识的没文化，有文化的没知识，造就了一堆有技术没想法的理科生和一堆有想法没法落地的文科生。我个人建议，大家应该更多地向通才的方向发展。

多样性的获取背后，又需要好奇心。有了好奇心，才会对各种新鲜事物感兴趣，才不会犯下面要说到的错误。

第二种，不用心听

网上有很多愤青，在国家制定一个政策后，马上就不分青红皂白地骂；看到名人做了一件事情，马上毫无理由地喷。很多时候，他们并不理解社会是怎么运转的，骂规则，不是觉得规则不合理，而是觉得规则没让自己占到便宜。

这一点，我觉得可以学一下阿里内网。 阿里内网有很好的开放、平等、透明的环境，多年前，阿里的CTO王坚就一直被骂，很多阿里的新产品出来，也被骂。公司觉得总这么骂也不太好，吐槽只会增加负能量，毫无意义。后来，公司加了一条规则：你可以骂，但你要提出更好的解决方案。于是，为了给出更好的方案，逼着想骂的人去了解各种信息，分析对策。很多时候，研究之后发现，其实对方也没有那么傻，于是戾气少了，理解多了。

可惜的是，社会没有办法让大家都遵循某条规则。能引起一些改变的，就是让大家多保持一点好奇心，对自己不了解的事物保持敬畏，再培养一点多样性，让自己可以听得懂更多不同的观点。

如果我们一起努力，让上述两种思维模式能得到一些纠正，就正好应了我反复说的那句话——用心听，但不要照着做。

用心听，是充分的接触广义用户，以了解问题及其背后的动机和人性。不照着做，要求拥有多种领域的专业知识，能做出一些新的东西。而这些，一定会成为社会发展的推动力。

不管你是产品经理还是非产品经理，即使你把这本书的内容全忘了，也希望你还是能记住这一句话，一句需要每天不断念叨的话：

用心听，但不要照着做。

11.6 延伸阅读与练习

第12章 结束：写在正文之后

12.1 国产产品图书盘点

12.2 重新定义“读书会”

12.3 七印部落翻译的书

12.4 其他资源

附录——生活中的好设计

1. 鼠标垫突起设计
2. 有点像易拉罐的拉环的啤酒瓶盖子
3. 内外分隔的鸳鸯锅