作者：刘飞
出版社：文化发展出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
产品经理从入门到精通试读：
图书在版编目（CIP）数据
产品经理从入门到精通／刘飞著．—北京：文化发展出版社有限公司，2019.8
ISBN 978-7-5142-2738-3
Ⅰ．①产… Ⅱ．①刘… Ⅲ．①企业管理－产品管理 Ⅳ．①F273.2
中国版本图书馆CIP数据核字（2019）第146761号产品经理从入门到精通著 者：刘 飞责任编辑：岳智勇产品经理：闫丹丹监 制：魏 玲 潘 良 七 月出版发行：文化发展出版社有限公司（北京市翠微路2号）网 址：www.wenhuafazhan.com经 销：各地新华书店印 刷：三河市冀华印务有限公司开 本：700mm×980mm 1/16字 数：284千字印 张：18.75版 次：2019年10月第1版 2019年10月第1次印刷ISBN：978-7-5142-2738-3定 价：49.80元本书若有质量问题，请拨打电话：010-82069336第一章 产品经理通识
有许多关于产品经理的通识，在没有入行的朋友看来非常惊奇。让一个从没有做过互联网的人描述产品经理或者工程师的工作内容，在内行看来几乎是天方夜谭。
这些通识，有的非常简单，有的需要深入理解。如果遇到不熟悉的字眼或者描述，还要擅用互联网的搜索工具。相信读完第一部分，大家对产品经理这个职业会有相对直观的认识。产品经理有哪些类型？
你可能听说过许多产品经理的岗位，有人是产品助理，有人是产品专家，有人说自己是电商产品经理，有人说自己是产品负责人。这些名字的含义到底是什么呢？这堂课，咱们就来聊一聊产品经理都有哪些类别和层次。
产品经理的类别有许多维度的区分方法，我们可以从不同的角度来探讨。
最常见的，是按照工作内容区分，看工作的重心是什么。1．用户产品经理
用户产品经理是最常见的产品经理，负责的工作就是探索用户的需求，并且通过产品手段来满足他们。用户调研、需求分析、功能设计、迭代跟进等，都是用户产品经理必备的工作内容。2．后台产品经理
后台产品经理也是很常见的一类产品经理，这里的后台更多是指一些管理系统和数据系统等。这些系统涉及复杂的权限体系、流程体系和数据体系，因此对产品经理的逻辑要求更高。3．B端产品经理和C端产品经理
从名字上就能看得出，一个是服务B端用户的，包括合作方和内部的同事，比如美团的商家，以及京东的供应链厂商；另一个则是服务C端用户的，一般是公司真正的服务对象，比如美团和京东的消费者。
有时我们会简单地把用户产品经理叫作C端产品经理，把后台产品经理叫作B端产品经理。实际上后台产品经理未必都是B端产品经理，有的产品用户也是B端的用户，如美团外卖配送员，他们使用的配送端App，是用来接单和处理订单的，也有消息中心和各种活动页面，不完全属于后台系统，反而更像用户产品。4．数据产品经理
数据产品经理是近几年比较热门的新职位，不过本质上与用户产品经理或后台产品经理差别不是特别大，主要特点就是更多关注于数据层面，要多考虑如何从数据中抽象出有价值的信息，来帮助用户判断。单纯只关注数据的产品经理可以称为数据专员，并不是真正的产品经理。5．商业产品经理
商业产品经理也是比较热门的职位，本质是用户产品经理，只不过他们关注的是商业化的产品。例如，对于知乎来说，知乎的主站流程、怎么发问题写答案、怎么点赞关注、怎么查询信息等都是社区核心的用户产品模块。而知乎live和电子书，就属于知乎的商业产品模块，负责这个模块的产品经理就是商业产品经理，技能树会有一些不同，因为不仅仅要考虑用户体验，更要考虑商业价值。6．策略产品经理
策略产品经理本质也是用户产品经理或后台产品经理，只是实现产品功能的过程中有大量策略的部分要做，要跟算法工程师或者策略工程师共同探索满足用户需求的方法。如果完全是做策略分析的话，不能算真正的产品经理。
另外，还有一些工作内容跟产品经理很相关的岗位，实际上都不是产品经理岗位，如产品运营岗位，或者项目经理。这里就不展开讲了。
以上是按工作类别划分，那么按照职权范围划分，有哪些产品岗位呢？用我自己的分类方法，可以分为文档产品经理、需求产品经理、模块产品经理、产品线产品经理和产品负责人。1．文档产品经理
顾名思义，就是只负责写文档的产品经理。任务就是画出原型、写出文档。前面有比自己高阶的产品经理或者老板来提供需求，后面有设计师来完成后续的文档完善，也有项目经理去推进执行，决策权不大，属于完整产品环节当中的一小块。2．需求产品经理
与文档产品经理相比，区别在于可以对某一个需求或者功能负责，能够决定一个功能做成什么样子。比如负责相机的倒计时模式，那么倒计时如何触发、如何提示，都是需求产品经理要思考的问题。对这个需求中间出现的问题要做处理，未来的优化要做跟进。3．模块产品经理
模块产品经理管辖的范围更大了，涉及这个模块的所有需求。比如负责手机的相机模块，那么与相机相关的各种问题，都要不断花精力去做优化。对相机当前问题的优先顺序，也要做把控。4．产品线产品经理
工作内容跟前两者差不多，不过会管辖一个相对独立的产品线，相当于一个完整大模块的负责人。5．产品负责人
对于小公司来说，产品线产品经理就是产品负责人，所以初创公司和中小企业的产品经理都喜欢用这个头衔，即使在他们公司只有一两个产品经理。在大一些的公司里，产品负责人要关心整个产品，为产品拟定进化方向，建设团队，管理各条产品线的负责人，维持良好的协作氛围，等等。在比较大的公司里，产品负责人有许多层次，比如产品副总裁管理几个业务线的产品负责人，产品负责人再管理产品线的产品经理。
以上是按照职权划分，许多产品经理岗位也会按照行业类别划分，主要是为了在求职市场上容易做匹配，有类似工作经历的产品经理就可以找类似的岗位了。常见的有以下几种：1．电商产品经理
典型的有淘宝、天猫、京东的产品经理。电商的产品经理通常比较熟悉用户购买行为的生命周期，知道怎么使用户增长，以及如何做各种营销活动。2．社交产品经理
典型的有微信、陌陌的产品经理。社交产品经理比较关注用户的人性诉求，引导用户建立关系和产生连接。3．社区产品经理
典型的有知乎、豆瓣的产品经理。社区产品经理与社交产品经理有类似的地方，不过更多的是关注社区氛围的建设和内容的沉淀。4．金融产品经理
典型的有蚂蚁金服和各大巨头的金融部门的产品经理。5．O2O产品经理
典型的有美团、滴滴、饿了么、58同城等的产品经理。O2O关注的是双边平台的匹配效率以及服务质量，与以上几种产品经理有较多类似的地方，因此O2O产品经理通常可以把经验复用到其他产品上。
除此之外，还有很多产品经理，比如教育行业产品经理。细分下去甚至还有K12教育和成人教育等。行业不同，分类的方法也不同。
我们讲了按工作内容、职权范畴、行业划分，下面再来讲一种分类方法，也是比较简便的方法，即按产品载体划分。
按产品载体划分，目前比较常见的其实就是四类，移动端产品经理，分为做移动端App和移动端Web页面的两类；PC端产品经理，也分为做软件的和做Web页面的两类。
按产品载体划分，从表面上看就像程序员按语言划分，是不同的工种。但目前他们之间的差别远没有那么大。尤其是在产品设计时，做结构、做功能、分析逻辑、研究用户的时候，方法论都是相通的，只不过表现层要用不同的交互和视觉呈现而已。
最后简单讲下按照职级划分，不同的职级在名称上的差别。上节课咱们提到，产品经理的市场价值有大公司职级作为背书会比较有效。
从低到高，常见的职级有：1．产品专员／产品助理
工作范围大都是在文档产品经理和需求产品经理的阶段，一般很少自己发掘需求，要由别人来带。具体什么是专员、什么是助理，不同公司区别不太一样。可以认为就是初级产品经理。2．产品经理
合格的产品经理一般负责完整的模块，至少是一个完整的功能。对自己负责的产品部分有决策权。在这个职级上，大部分都是真正意义上的产品经理。3．高级产品经理
比较高级的产品经理，在不同公司差别也很大。但在同一个公司，高级产品经理一定会负责更大的范畴。比如产品经理负责的是功能，高级产品经理就会负责模块；如果产品经理负责的是模块，高级产品经理就会负责一条产品线。4．产品专家
相较高级产品经理而言更高级的一个职位，负责的范畴更大一些，具体到其他方面，比如带不带团队、是否负责产品线，并没有明确的标准。5．产品总监
产品总监一定会是某个产品线或者某几个产品线的总负责人，大公司会有很多产品总监。创业公司一般只有一个产品总监，而且从能力上来说，许多创业公司的产品总监实际上是“比较厉害的产品经理”。6．产品副总裁
到副总裁的级别，一定是所有产品都归他负责。
以上就是按照职级划分的产品经理的不同职位。有的公司还有资深产品经理、高级产品专家、资深产品专家等，也是依据管理产品的范围更细化的一种区分。
好了，总结一下。今天我们的课主要讲了所有产品经理的常见分类。按照工作内容划分，包括用户产品经理、后台产品经理、B端产品经理和C端产品经理、数据产品经理、商业产品经理、策略产品经理；按照职权范围划分，包括文档产品经理、需求产品经理、模块产品经理、产品线产品经理和产品负责人；按照行业类型划分，包括电商产品经理、社交产品经理、社区产品经理、金融产品经理、O2O产品经理；按照职级划分，包括产品专员／产品助理、产品经理、高级产品经理、产品专家、产品总监、产品副总裁。
有了这些区分，想必你就能够对种类繁多以致搞不太清楚的产品经理岗位有比较全面的认识啦。
今天的课程就到这里，这次的作业：到互联网招聘网站上，找到我今天没有提到的产品经理职位，并且区分这些职位都是按什么维度去命名的。产品经理在早期需要掌握什么能力？1．锻炼对自家产品的理解
初学者可能会被种类繁多的原型工具和一堆堆的案例“绑架”，满脑子都是别人的产品花哨的功能和眼花缭乱的方案，唯独对自家产品不了解。
这样的产品经理平时跟老板的对话一般是这样的：
A（老板）：你觉得这里放四个标签页合理不合理？
P（产品经理）：当然合理，美团啊、点评啊、微信啊都是这么做的。这是天下大势。
A：那我们的页面上功能排版这样靠谱不？
P：没问题。现在这样的排版方式是最常见的，交互方式也保证是最流行的。唯一色调设计手法是国际上流行的设计理念Minimal。
A：哦，那我们这几个功能是必需的吗？
P：这几个功能竞品都有了，我们没有的话不好吧？
A：……
对自家产品的理解又分为多个方面：
对公司定位的理解，与老板和投资方有关。
对用户定位的理解，与公司的定位和市场的状况有关。
对产品定位的理解，与用户的定位和推出产品的初衷有关。
对公司研发能力的理解，包括设计能力、开发能力和运营能力。
对其他部门状况的理解，包括各部门在做的事情、大家进行的状态。
……
总之，你做出的每个判断都必须基于对产品多方面的理解，而不是对竞品的理解、对市场的理解这些零散的因素。
只有这样，当设计师做出令你不满意的设计时你可以说“这个风格可能适合年轻人，但我们的目标用户是商务人士”，而不是说“这个不够大气，没有feel啊”；当你要求工程师改一个看起来不重要的Bug时可以说“后续运营部门有好几次大型活动，到时流量会瞬间暴涨，你这个Bug会放大10倍，所以很危险”，而不是说“重要不重要不是你工程师定的，而是产品经理定的，你改就行啦”；当你跟老板讨论要不要加一个功能时可以说“我觉得我们这样的功能是一个重要的补充，跟下个版本要做的事情不谋而合”，而不是说“竞品做了咱们不能落下啊，管它有没有用”。
具体怎么去锻炼，其实是件费力又费脑的事情，你要不断地跟老板沟通、跟同事们沟通，跟用户聊，做调研，同时还要做大量的思考和总结。你要有一本自己的词典，用来记录你名下产品相关的事无巨细的解释，每当需要查询时就能随时翻阅。
这本词典可以记在心里，也可以整理成笔记。在别人看来，它可能无关紧要，也不是那种张口“人机交互的趋势”、闭口“立体化设计语言”这些可以用来卖弄的术语。但没有这本词典，你每走一步都是一个坑，等走远了想回来填的时候，已经晚了。2．提高分析和判断能力
如果说对产品理解是第一步，那第二步就是怎样基于你的理解做出靠谱的判断。
很多产品经理除了参考别人的产品，就是做用户调研，或者唯老板是从。但很多事情非常简单，只要有生活常识、基础的推理能力，明明是可以更靠谱的。
举个例子——
当初MIUI做安卓本地化的时候，在日历里加入阴历是主打特色之一，也广受好评。在做T1的日历的时候，我们也在考虑这个问题：到底加不加阴历？
加的话，整个界面非常满，显得丑陋；不加的话，需要看阴历的用户又会不舒服。
重调研的产品经理就会做个调查问卷，规模越大越好，看哪边的用户多；用户定位是偏高端用户或者说发烧友的产品经理，可能就会做个开关选项，用的打开，不用的关了。
但实际上完全可以向前推理一步：用户到底为什么需要阴历？
大概场景有几个：春节前后用；阴历的节假日用；自己和亲友生日用。这些基本囊括了所有用户的需求。
这就简单了，我们能不能只在春节和节假日的时候显示阴历？对于生日的话，我们可以提供设置项，在用户和亲友每年生日那天显示阴历。
这样既化解了界面始终显示阴历的尴尬，又满足了大部分用户对阴历的需求。这种方案凭常识很快就能推断出来吧？既不用复杂的问卷调查，也不用复杂的产品设计吧？
你可能会说，这就是个抖机灵的需求分析，况且是个小功能。那我再举个例子。
我们之前在嘟嘟美甲讨论最基本的功能和界面时，并没有参考市面流行的O2O工具都有什么功能、都有哪几个标签页、都怎么排版的。我们先做了一次用户的分析。
用户的分析不是靠什么问卷来做的。你在问卷里问“你是哪类用户”“你平时做美甲会更看重什么”，他们很难回答清楚。如果你给的是具体的选项，又会有诱导回答的可能，最后的结论往往不能说明问题。
我们的分析方法是，先从常识判断美甲用户使用我们的产品有以下几种场景：
1．已经有想做的样式。
2．想来做美甲但不确定样式。
3．不确定做不做只是随便来看看。
每类用户来这里的需求肯定是不同的：
1．看你这有没有想做的那个样式或者类似的样式。
2．看你这有没有好看的样式。
3．看你这有没有什么足够吸引她做美甲的地方。
对于这三种需求，我们要提供的功能又是不同的：
1．根据用户的样式提供定制服务，搜索和筛选功能。
2．精品／热门推荐，搜索和筛选功能。
3．专题，精品／热门推荐。
所以，在用户第一次看到产品的时候，我们需要提供的功能就一目了然了。
我们起初的判断是，产品刚上线，第3种用户肯定最多，第2种用户会逐渐多起来，而第1种用户会是高端、深度的用户，出现得会更晚。这样对功能的主次也都分得清了。
最后初版的产品，我们就决定把主要精力放在推荐和专题上，搜索功能是第二版上线的功能，而定制则是更未来版本的功能。界面的布局和排版，功能主次分明，所以心里也有数了。
从最终结果来看，做出来的界面似乎大同小异。但因为每个功能从研发角度都会消耗精力、从用户角度都会影响体验，如果是拍脑袋想的，一点小差别、一些可有可无的功能都会成为南辕北辙的错误决定。
其实这些东西通过常识是完全可以判断的。你说“我不是女人哪懂美甲咋回事”，但你总逛过淘宝用过京东吧？购物时用户的思路还是可以想象得出来吧？当你有了初步判断之后，用户调研的意义就体现出来了——它是验证的手段。但它不能作为需求的来源。
总体来说，产品经理在做任何决定时，都要做到三个字：讲道理。
那怎样培养这种能力呢？也不难。就是在日常生活中多问为什么。
这个小区的停车场入口需要绕三个圈，为什么这么设计？优衣库进门一眼看到的全是内衣裤，这么摆放是什么道理？楼下咖啡店平时顾客也不多，但居然撑了五年还没关门，他们的收支能够平衡吗？
很多道理是相通的，每天都能想明白一些事情，当你遇到棘手的产品问题时，你肯定想得比别人远，也比别人靠谱。不断去看别人的产品，但不是学皮毛，而是从商业模式到交互细节，再到视觉风格，想想这么做都基于什么道理。3．确保良好的沟通和表达能力
对产品有充分的理解、对各种问题有清晰有据的判断之后，下一步就是把这些自己的理解和判断跟同事们做充分的交流和沟通。
其实说来也不难，就是注意沟通的技巧，一方面是要有我们常提到的“情商”，怎样让没有实权的你在推进大家完成任务、在协调大家的工作时不那么讨厌；另一方面是要让每次沟通都有效率，不耽误时间。
对于前者，我的建议有——
始终清楚自己是产品经理，但不是经理，不要盛气凌人。
用有理有据的事实来说服别人，而不是“老板的决定”“反正跟你没关系”这种说法。
别人遇到困难不要说“我不管，这是你的事儿”，而要主动去了解他的困难，并且尽力帮忙解决，解决不了的一起想备选方案。
产品项目组中的任何同事之间有了矛盾，都要主动去协调，别在旁边看热闹。
让每个产品线上的同事随时了解全局的进展，让大家产生主人翁意识。
用户的反馈整理后可以周知同事，让大家产生成就感，觉得自己做的事有价值。
对于后者，我的建议有——
每次讨论问题，不管是一对一聊，还是开会，都明确目的，有腹稿。
描述问题清晰，想好了再说，同时不要偏题。
每个问题都形成结论，不要讨论来讨论去觉得很充实就行了，没有结论都是浪费时间。
不要把任何事情都交给别人决定，自己时刻准备提出更多方案和建议。
每次讨论的过程和结论都有记录，可以随时查阅。
学习交际能力最快的方法其实不是从书本上背诵，而是找一个你觉得交往起来特别舒服又很优秀的人，学习他身上的优点。4．对产品的责任心
责任心似乎是最容易具有的，但却是我直到现在面对很多优秀的产品经理都觉得自愧不如的。
我特别喜欢一句话：产品经理最重要的能力就是让正确的事情相继发生。
你做到我说的要求了，但那只是做“正确的事情”，能不能让它们相继发生，考验的就是你的责任心。
当午夜工程师为项目上线加班时，你是在楼下电影院里吃爆米花，还是在旁边默默陪他？当设计师跟老板因为方案闹僵了的时候，你是等着他们握手言和，还是主动找老板或者设计师聊一聊以便把项目推进下去？当运营部门的同事为了某个紧急活动向你提出不太实际的功能需求时，你是一句“做不完”就把他打发走，还是认真跟他讨论有没有什么别的方法能应急？
是的，严格来说，你跟公司是劳动契约，你不能被强制加班；你的岗位是产品经理，不该去帮别人想解决方案；你也不是老板，公司的各种“坑”也不必由你来填。
但一个优秀的产品经理，是要对任何与产品相关的事务负责的。任何阻碍产品正常上线的问题都应该由你解决，任何能对产品提供帮助的事情都应该给予关心。
在这方面如何抉择，就决定了你作为产品经理是平庸还是优秀。5．关于工具的使用
工具放到最后说，是因为实际意义上的产品经理，并不必掌握太多原型工具、交互绘制工具甚至绘图工具。
不管是什么样的工具，都是为人和当前做的事情服务的。还是刚才那句话，你为什么要用它？它对你现在做的事情有帮助吗？
很多初创团队刚刚起步，就开始搭建各种大规模的Feature/Bug的记录和处理平台，在用特别复杂的需求文档描述规则时，把脑图、Axure作为必备的工具。这样做，不但没有提高效率，反而造成了很多问题。
就跟MBA不适合创业者一样，复杂的流程会严重拖累中小公司的运作。我平时就用Keynote、Sketch等工具，完全能覆盖90%的需求设计工作；产品研发的需求记录和处理就用Trello或者风车，操作简单、易用。
记住一条就可以了：只要觉得目前手头的工具好用、高效，那就没必要换成高大上的。除了卖弄，没有任何意义。6．尽量涉猎广泛
有一次，“在行”的一个朋友问我，他经常会与设计师有争议，他总觉得那样排版有问题，但却说不出哪有问题。我说，很简单，如果你直觉上觉得有问题，那可能真的犯了一些基本错误，只要你多学习些排版上的知识，多了解下常见的排版规则，那之后再遇到争议肯定就有底气了。
作为产品经理，懂一些其他岗位的基本知识是很有好处的。这样既能保证良好的沟通，也能让你在考虑需求、设计方案时做到心中有数。这是一个好的补充，当然没有也无所谓。
去看看别人都在看什么书，找些基础的看一下；也可以到知乎去看看快餐类的文章。这样别人就不会在背后说，这小子就会每天瞎想些点子、画点不靠谱的原型、做点不接地气的方案。有哪些产品经理的常识？
我是产品经理、创业者，下面讲一些互联网方面的小常识。1．很多因素都比点子重要
在创业时，大方向、团队、竞争环境、商业模式等，都比点子重要。
点子只是灵机一动的故事，就跟网上的鸡汤一样，没有细节只有情节，投资人不会相信只有点子的创始人，市场也不会承认做不好的点子。
还有一个真相：你能想到的点子，100%已经被别人想到了，无一例外。2．创业就是做生意，赚钱是本职
创业者不是理想主义者，应该是商人。
创业不是实现理想、造福人类或者改变世界的游戏。创业就是用资本、人力和策略实现真正有价值的生意。
很多企业家都说，情怀是他们创业成功的资本。那是他们故意让你以为是那样的而已。如果他们说想赚你钱，你就不想掏钱了。
知乎的周源也说过：“你得尊重商业，很多人是不尊重商业的，可能在产品上想得很多，但是你不能一点商业都不懂，天天想着到了某一天天上掉馅饼下来，就自然水到渠成了，这是不可能的。”3．在创业时，足够勤奋只是下限条件
热情和勤奋很重要，加班很重要，累得瘦了50斤很重要，带领大家喊口号打鸡血很重要。但是以上都只是基本的条件。
还需要什么呢？对商业逻辑的敏感，对业务能力的把控，对社交关系的掌握，对团队管理的熟悉。在某个专职的岗位上也许具备5种能力就能玩得飞起，但创业却要会50种。
有人觉得自己骨骼清奇、双腿健硕，走路够快，但也许没有判断能力，他压根就走错了方向；或者别人是骑摩托开汽车去的，他发现人家压根都没想过走路。创业时，“努力只能决定你的下限”，这是青山资本的张野说的，对此我深表认同。4．互联网创业不只是做个App
很多产品不适合做成App，明明用更简单的方法就能解决，为什么非要下载App？比如约人洗车，我打个电话不是更方便？关注微信号也可以啊。硬把需求塞到App里，谁会用呢？
很多产品即使做成App，也只是完成了一个小环节。做团购，把网站建好了，商家就会自己跑过来吗？不得有强有力的地面推广团队？商家来了，让用户知道不也得有强大的推广营销团队？5．产品经理不是经理
这个内行肯定是知道的，很多外行的朋友不了解。我记得申请信用卡的时候，做工程师的朋友比我的额度低，原因就是我的头衔是经理……
我觉得问题出在翻译上，把Product Manager翻译成“产品管理员”似乎更合适。在很多公司，产品经理做的其实是Product Designer的工作，也就是产品设计师，项目方面的协作推进由Project Manager（项目经理）来跟进。
产品经理一般对人没有管理权，但又要协调各部门工作，因此也被称为“无授权领导”。6．产品亮点也可能是Bug
你看到的产品缺陷可能是设计者故意为之，你看到的产品亮点也可能只是Bug。
有时候，产品设计者会故意做些引导，把不希望你经常用的功能隐藏掉或者把路径变长，把希望你经常用的功能放在显眼的位置。
比如像我这样的原创作者会特别关心抄袭的问题，今日头条和微信中的举报功能是这样的——
右边是微信，可以直接选择两种抄袭情况，还能继续填写抄袭细节。以微信的处理速度，一般是5分钟内受理，半天内处理。
左边是今日头条，你要很仔细找，才能看到最下方有一行，举报侵权请联系××@××.com，发邮件之后，一般几天才回，让你提供各种复杂的材料作为证据。
真以为是今日头条产品设计得傻吗？显然不是。他们平台上有大量的抄袭文章，一旦能让用户快速举报并迅速处理，对活跃度的影响可是很大的。
再举个相反的例子，大家都知道微信删除好友不是双向的，而是单向删除。之前有大量分析文章来说明这么做多有道理，但实际上呢？这只是个Bug。7．视觉和交互是用来讲故事的，很难成为核心竞争力
说实话，我目前见到的产品，除了游戏和一些本就是以视觉为主的产品，其他产品的视觉和交互都不构成核心竞争力。
你可能会问，那不对啊，我看到好的产品，都是交互很棒、视觉很好的啊。
道理很简单，正因为你看到的是已经做得很好的产品，所以他们才有能力请更贵的设计师。因果关系是存在的，不过是前后颠倒的。8．运营不low
运营不是大家理解中的销售，运营实际上分为很多具体岗位，包括用户运营、产品运营、内容运营、商务运营、市场推广、品牌营销……每种岗位的工作都不一样，而且很多岗位实际上门槛特别高。
Facebook最出名的一个部门叫作Growth Team，这个部门构架如下：
可以看到，有数据分析、基础设施、增长策略、国际市场和Messenger五大块。部门直接向扎克伯格汇报，而且拥有极大权限，几乎是Facebook的命根。而这个部门，显然是有严格的运营导向的。
淘宝起初也不是靠用户体验做得好，而是靠地面推广铁军搞起来的。即便是现在，对卖家买家的各种策略和基于策略的运营执行，也仍是淘宝的核心竞争力。什么是产品经理的思维？“只从用户思维出发”是很典型的对产品经理的误读。这是在许多招聘网站提到的，能够从用户角度看问题，以及能够随时切换小白用户的视角。而实际上对它们的完整解读应该是这样的——
不是只从一个用户（你自己）的角度看问题，而是要从所有用户（至少大部分用户）的角度看问题。
随时切换为用户，就意味着要能随时切换回产品设计者，这才是产品经理，否则就只是用户。
同理，许多人思考问题，说自己已经洞察了人性，但听他说完，你就知道他洞察的只是自己的人性而已。许多人说自己发掘了需求，讲出来也只是他自己的需求而已。
真正的产品经理也会对用户有判断、对人性有判断、对需求有判断，只是这些判断是基于对世界、社会的认知，而不是基于对自己的认知，这是完全不同的。
在有些人的概念里，产品经理就应该焚香沐浴，然后坐在空荡的院落里冥想，过了一段时间忽然就可以顿悟用户的痛点或者产品的迷思。事实当然不是这样的。
我认为，产品经理的思维并非来源于直觉和内心的感知，反而许多时候跟直觉和内心的感知相悖。
像宗教仪式里那种祈求自己的灵魂与大自然或者上帝产生某些联系的行为，正好与产品经理思维属于两个极端。产品经理是最不应该相信直觉，而应该相信事实的，是最不应该深入自己灵魂，而应该探索社会和大众的。
这种思维从两个层面上来说，都称得上是反人性的。1．第一个层面是，理工科思维
诺贝尔奖得主卡尼曼在畅销著作《思考，快与慢》里提到，人类在处理问题时，大脑会有两种系统。系统1是直觉型的，用来处理简单问题；而系统2是逻辑型的，用来做逻辑判断和复杂问题的处理。产品经理的绝大多数工作，被很多人认为是在系统1的思维方式中，实则都是处于系统2的思维方式中。
该书举的例子都非常经典，比如关于标签化，为什么我们会直觉上认为“希特勒喜欢小动物”不是真的，是因为大脑处理“坏人就应该具备坏人的特征”这样的问题时会经过系统1的简单化处理，这样成本最低。
产品经理是不同的，需要做出反直觉的判断。很多人会说：“我明明就有这个需求啊，为什么淘宝／微信／滴滴不做？”这就是典型的直觉判断，没有通过系统2的分析，去考虑整个需求在面向千万级、亿级用户时的情况，只是自己粗浅的认识而已。
这个思维还包括一切以事实为准、拿数据说话的部分。群体在许多事情上的表现通常都是非理性的，许多产品经理在做规模化产品时经常有“用户居然会这么用这个功能”的体会，要怎样发掘这些奇特的表现以及怎样解读它们，需要做很多事实分析而非主观判断。2．第二个层面是，移情思维
有的人斤斤计较、不考虑其他人的感受，这样的人难以具备基本的移情能力，通常很难做好产品经理。
从生物学角度来看，即便有协作精神，人毕竟还是利己的物种，要想完全置身事外，以第三方的视角去客观看待产品相关的事物，还是很难的。
有的产品经理并不在意用户，他们在意的是功能的酷炫、项目的完成、商业的成功，也不会考虑用户的感受，想象用户所处的环境，不会“先天下之忧而忧，后天下之乐而乐”，那么做出的产品就总会缺点什么，无法直击别人的痛点。
沟通能力、项目协作能力、向上管理能力，甚至面试能力，也都是移情思维的拓展——你如果不能体会到面前这个人的感受、目的、状态，只是关注自己的表达和诉求，那结果可想而知。
这两个思维是让我最近感触非常深的，它们是反人性、反直觉的，需要具备天赋，以及大量的后天训练才能习得。这是产品经理思维的基础。培养产品思维的四种方法
我总结出了四个方法，帮助大家培养产品思维。1．像哲学家一样思考本质
对同样的一件事情，不同阶段、不同层次的产品经理，看到的是完全不同的信息，做出的也是完全不同的判断。
看到某个App加入了一个新功能，普通用户可能会仅从自己视角觉得好或者不好，但产品经理应该能够推己及人、具备共情思维，想象出不同用户的看法，乃至对于高阶的产品，判断出这个功能背后的思考、对平台的价值和长远意义。
如果我碰到的产品经理每天都在夸夸其谈，说某个功能用得舒不舒服、哪个产品做得好不好看，那么我不会愿意跟他结交，因为他看问题的层次太浅。
相反，如果我碰到的产品经理对自己所负责的产品功能在平台中的价值十分了解，并且知道所有竞品之间的优劣势，知道大家每个动作背后的战略意义，那么我会觉得他看问题的视野够大、层次够高。
很多产品经理思考问题都是零散的点，追求细节，研究像素级别的体验，并没有连成线。这些体验背后都是怎样的信息结构、都是如何服务用户价值的、都是怎样体现商业意义的，是产品经理更应该关注的。
我们部门目前进行产品评审时，每个需求都要花一半时间在解释背景逻辑上，解释清楚“为什么做”，要比“怎么做”重要太多。
这是本质思考的方式而不是一点点优化的方式，是产品思维中的关键。2．像婴儿一样保持好奇心
产品思维应该是既有深度，也有广度的。不仅要想得足够完备、逻辑健全，还要保证思考范围足够宽泛。要想达到思考范围足够宽泛，有很多提升方式，但不会出现在哪本讲产品经理的书里，不会是一种通用的方法论。
思考的广度，通常来自生活体验和阅读。生活体验是自己对世界的认知，而阅读是获取别人对世界的认知。你要先知道“有这回事”，才能在思考产品的时候，知道用户会“遇到这回事”，知道这种场景下“会发生这回事”。
俞老师，包括我和身边很多产品经理的观察结论是，如果一个应届生，在校园生活中显现出对世界的好奇和思考（比如有很大的阅读量、活跃在社团中、会写许多有意思的文章、愿意尝试新鲜事物等），通常他思考的广度就比别人宽很多，或者简单说，他的思维很活跃。
丰富的生活经验，源于对生活的观察和思考。比如我偶尔会去想苹果的文案为什么有意思，会记录和思考有趣的突破思维的案例，会思考许多生活中设计的本质。这些内容读者都可以在本书的后半部分看到。
有人对信息和知识获取特别排斥：“你们男生才喜欢历史”“他们文科生才关注地理”“政治跟我没啥关系”“我数学不好看不懂经济学”“我就是不喜欢看书”……同样地，有人也对观察生活和体恤他人非常排斥，对其他人的生活和经验，自己生活范畴外的任何事情，从国际新闻到邻居家的八卦，一概充耳不闻。久而久之，这两种人就没有外部信息的输入，思维自然也就僵化了。这样的人不适合做产品经理。3．像运动员一样锻炼修行
可以说，这世上有两种能力：一种能力是学了立马就会的，不太需要长期锻炼，比如学会使用计算器，或者懂得怎么使用智能手机；另一种能力是需要长期锻炼的，即使懂得很多大道理，也没法当场就成为专家。大部分能力都属于后一个范畴，产品经理的思维能力也是这样。
许多在校生和还没做过产品经理的朋友，经常找到我，发来他们写的需求文档或者竞品分析报告，我的回复都是：太初级，没有什么价值。要想真的写好文档，要想真的写好报告，关键是有没有写过100个真正的文档，有没有做过100次真正的分析。
所谓真正的文档和真正的分析，是在具体项目里产生的，不是作为爱好者自己做的作业。
每个产品经理可能都有过写的第一篇文档被各种人挑战和吐槽的经历。做了十几个需求后，慢慢对如何写文档有了认知，不会再被技术人员责备。做了上百个需求，基本就可以是兵来将挡水来土掩了。
在这个维度看，产品思维就像肌肉纤维一样，要不断锻炼，持续成长。4．像小白一样虚心求教
这个就不多说了。许多初入行的朋友看过太多“乔布斯语录”和“张小龙圣经”，执念太深，不懂谦虚，心态封闭，当然就得不到成长。
没有人天生就是熟练的产品经理。我见过的优秀的产品经理，无不是在不断地否定自己、批判自己的过程中成长的。让他们回头看过去一年，肯定能讲出无数做得不够好的地方，能够找到可以变得更好的办法。
如果读者处于那种回望过去一年，觉得事事满意的状态，就要好好反思了。产品经理的心智模型
最近翻看万维钢的《智识分子》，里面有篇文章提到了《超越智商：为什么聪明人也会做蠢事》，快速阅读了一下，解答了我一些过往的疑惑。1．智力测试有其局限性
我小时候有个朋友，功课做得特别好，智力测试也都是极高的分数，小学初中的时候一直名列前茅，到了高中成绩却跌得厉害，高考更是没有考到特别好的高校，只在地方将就读了四年，如今就真的是“泯然众人矣”的感觉了。
要是说他现在变笨了、测验题做不好了，那也不对。他依然能很好地通过测验。不过回顾他的人生，他认为自己并没有特别聪明，在许多问题上也搞不太清楚，不如身边的很多人。严格来说，智力测验是测出来了一定的智力水平，但仍然比较片面，不能完全将这个智力测验的水平等同于聪明。
这本书里提到，智力水平尤其是智力测验得来的那种，局限性非常大。由于要快速检验一个人的智力，大多数题目会将背景设置得相对简单，消除了题目背后的专业性。因此我们看到的大多是图形数字之类的简单逻辑推理，不会出现金融行业的一个风投决策的问题或者汽车行业如何做流线型设计的问题，后者需要大量的背景补充和经验积累。
这是第一个层面，即智力测试不能代表是不是真的智商高、是不是真的聪明。2．智商高不代表有理性思考的能力
第二个层面，哪怕是真正的智商高，也不代表处理复杂问题的能力强。我在这两年接触了大量毕业生和新人产品经理后对这点有很大的共鸣。
许多名校毕业生，履历光鲜，谈吐中能感觉到其智商优越，但涉及一些深入的问题，答得都不尽如人意。许多问题带有背景和知识范畴的限制，不知道的就是不知道，多聪明都没用；更重要的是，有良好的抽象推理能力、创新能力和反省能力，才是处理复杂问题的关键。
其他的职业有许多现成的理论体系可以学习参考，学成了就成为熟练工，书中称之为陈述性知识，都是固定的。产品经理日常遭遇的问题特别抽象，比如用了一种常见的增长方法后效果很差，意识到这种方法不起作用是简单的，但要洞见背后问题并根据实际情况调整出更佳方案，就需要较强的抽象分析能力了。3．心智模型
作者提出的心智模型是这样的：完整版三重框架模型《思考快与慢》中提到了系统1和系统2，跟这个模型类似，图中虚线上的两个部分就相当于系统2，虚线下就是系统1。
虚线下的自主心智就是我们平时的快速反应，不做深入思考的。看到肌肉强壮的人就觉得比较暴力，看到阴天就觉得要下雨等，都是根据直觉做出的判断。
虚线上的则是需要思考的，消耗脑力（能量），成本比较高。算法心智是最核心的做各种推理演算的部分，自主心智在遭遇搞不清楚的事情时会求助算法心智（为什么这个肌肉强壮的人不暴力？为什么阴天后没有下雨？），而算法心智会在一定程度上压制自主心智，防止我们总是用直觉做判断。
那反省心智是什么？按我的理解，就是再抽象一个层面，要对心智作进一步反省和总结。从肌肉强壮的人不暴力来看，算法心智的总结可能是肌肉强壮的人的成长环境不同，也有好有坏，不能凭刻板印象，到了反省心智的一层，就要去耦合模拟（具体概念可以读一读原书，不太好解释），最后得到的总结就是单凭人种属性来判断个体的特征，是有误的、没逻辑的，这就是反省心智的价值了。
由此可以看出，在直觉之上更多用算法心智思考，在算法心智上再多考虑抽象模拟，从这个世界认知的各种表征里抽象出各种规律和方法论，是判断理性能力的核心标准。4．产品经理的心智
延伸一点讲，在产品经理的成长过程中，理性能力或者逻辑能力的成长，也是三段式的。第一层，能大概判断、从直觉上感知到问题；第二层，能全面、合理地分析问题以及给出逻辑上讲得通的解释；第三层，可以从经验里抽象出相对有效的方法论。这与书中心智模型的层次差不多是对应的。
这种三段式理论可以运用到不同的模块，比如我之前就提过，产品经理认知用户有几个境界：
第一层，不知道自己的用户是谁，不知道自己的用户在哪；
第二层，遇到需求，可以找到自己的用户，问出其感想；
第三层，对用户足够了解，看到问题或者需求，能立马准确判断出自己的用户会怎么想；
第四层，能抽象出对用户的认知，有一个画像说明或者指导手册（不一定是实体的），让其他人也能快速预判用户的想法。产品经理有哪些经常犯的错误？
我就只说一个错误，不过这个错误可以无限展开。
很多产品经理在做称不上有错但未必是正确的事情。
作为产品经理，有个大前提是大家经常聊的，就是产品经理的工作内容不是标准化的。这意味着什么呢？一样规模的团队，类似的产品，同样岗位的产品经理却有可能在做完全不同的事情。
你用Teambition来协作，他用Excel；你画高保真的原型，甚至在墨刀上做出来，他可能只是在本子上画画草稿；你更关注管理层的战略决策和方向，他则关注用户的体验和场景需求……最后都能做得出来产品。但哪个方法更好，常常没人去理会。
这就源于刚才说的前提，并没有严苛地规定产品经理要做什么，那大家往往就依着兴趣、依着团队氛围、依着习惯去做了。
我曾经意识到自己在做的未必是最应该做的事，于是整理自己过去几个月的工作内容时，发现有一些的确有用，但如果换作别的事情，可能会更有用。或者换句话说，实现一个目的有很多种方法，但我往往会选最容易想到的，而不是最好的。
这个错误会衍生出很多表现：1．事必躬亲
诸葛亮是劳模，凡事事必躬亲，但最后的结果是蜀国无大将。朱元璋废掉丞相，也是凡事自己处理，期望集中皇权，但后代都难有他的勤奋，最终还是设立了内阁。
产品经理要处理除了产品设计之外的很多杂事，但未必都要事必躬亲。无授权领导这个词用得很好，作为产品经理，要把团队资源调动起来，为自己负责的产品服务，但不要用下命令的方式。
在协作中遇到什么没人做的坑，先不要着急去填，想一想这种坑由谁来填会更得当、未来怎样填会更合理，然后想办法跟别人一起处理。如果你自己先去弄了，那以后这些活就会都是你的。看似让自己的工作更充实，还表现出了大无畏的填坑精神，但是最后结果就是做了很多不该做的事情、浪费了应该做更有意义的工作的时间。2．做重复劳动
产品经理应当对自己的工作内容有设计思维。在做的这些事情，是不是每次都花费很多重复劳动？有没有更高效的解决方案？
在产品设计上，有时设计的功能要考虑逻辑一致性，因此每次都要花大量时间观察和之前的功能会不会有冲突。如果有时间把整体逻辑的规则捋清楚，生成一份逻辑一致性的规范，那以后就可以对照着来做了。文案的一致性也是如此。
协作时，很多方案的修改通知是在微信群里发的，每次发送和确认过程都很烦琐。如果有时间让大家都用上某个协作工具，自动发送通知并记录已读回馈，所有人都能节省大量时间。3．只关心过程，不关心目的
有时对过程的过度关心，会导致很多形式主义。
比如听说有种文档格式非常好用，以后所有文档都这么写，觉得这样做足够专业，但其实未必真适合团队。比如听说用Axure可以画高保真原型，就不管当前产品的进展，硬是用最复杂的方式来做设计。
产品经理的任何工作都是有目的性的，文档是为了与开发人员协作并留作记录，只要保证在你们的项目里协作和记录都可以良好运转就行了。
或者再举个夸张点的例子，做用研访谈时，没必要完全按照之前的大纲来。如果发现每个访谈对象纠结的点都在提问范围外，那就扔掉大纲，把这个问题搞清楚。甚至如果发现问题已经确定搞清楚，那么剩下的访谈也都可以不做了。
产品经理尤其不要沉浸在每天八九个小时的工作充实感上，觉得自己忙了一天了。充实感应该来自真正产生的收效，如今天确定了几个需求，输出了几份文档，解决了几个问题。
产品经理要对自己正在做的和已经做的工作时刻保持警惕，最好有规律地复盘，看自己的工作内容是不是合理、做的事情是不是真的有用。作为有用的判断，通常就是让产品变得更好了。好的产品经理需要哪些素质？
差的产品经理多种多样，好的产品经理也不都是一个模子。大家提到的素质各不相同，的确都是判定是不是好的产品经理的条件，不过就我的观察和体会而言，有些是充分的、有些是必要的，但不全是充要的。
例如，对细节的偏执，是用户体验方向的产品经理第一重要的素质，但对高级产品经理或者产品负责人来说就不算太重要。做策略和规划的产品经理当然要区别于做执行的产品经理，马化腾、雷军会直接对产品团队提细节上的建议，只是反映了他们关注产品细节，而不是说他们的工作就是这个。因此对某些产品经理来说，从细节中抽身出来反而是他们所必需的。
我想用几个充分条件和几个必要条件来说明，好的产品经理应该具备哪些素质。1．出色的逻辑分析能力
有的产品经理确实不太在乎逻辑、不太在意推理，更关注感性上的顿悟和创意，但这并不妨碍他们成为优秀的产品经理。不过说实话，这跟时运有关——大多数产品经理遇到的状况是，他们的工作内容失去逻辑也就没了意义。
不夸张地说，我所见的大部分产品经理，都是偏重“落实”和“执行”这样的环节的。说不好听一点，就是需求经理或者文档经理。需求和文档要做好，必然都要逻辑完善、内容翔实，不能指望用精彩的创意打动开发团队，他们只在乎你考虑得周不周全。
拥有严密的思维方式和靠谱的分析能力，未必能让你成为大神，但成为一个好的产品经理绰绰有余了。2．对用户、市场和行业特别熟悉
有很多行业内的人，转行成为互联网产品经理，其实做的仍然是类似过去的事。他们都关注同样的用户、同样的问题，也就只能做出同样的决策。只要对用户和市场足够熟悉，不用做调研和访谈，就可以对任何需求和功能做出正确的判断。这样的产品经理也能称为优秀。
或者另外一种，对人性吃得非常透所以能做社交或者游戏，对媒体特别熟悉所以能做内容产品，对安全有深入的了解所以能做支付产品。他们的优势不在于会写好的文档、会做出好的设计，而在于他们的工作不可替代性强。3．出色的统筹资源的能力
有的人未必能自己写好文档、自己成为行业专家，但是他可以很好地统筹能写文档、能成为专家的人。他擅长的是利用外在的资源来达成目的，这样的能力在某些公司和团队中至关重要。
我们经常谈到产品经理应该有沟通能力，这句话并不清晰。如果仅仅是能让沟通的双方很开心或者油嘴滑舌并没有意义，好的沟通能力是要能真正调动资源、实现目的。通过沟通、维护协作、协调流程，让开发人员高效实现产品、让产品稳步合理地迭代、让团队成员各司其职，才是此类产品经理的价值。
要成为这样的角色很多时候要靠管理职能，不过此类产品经理有的没有真正的管理权限，但也能把无授权管理做得特别漂亮。4．自我管理能力
自我管理指的是能够安排好自己的任务、规划好自己的工作、利用好自己的时间。产品经理的工作内容不固定，实际的工作边界也不清晰。因此做好自我管理并不是简单的事。
缺乏自我管理的产品经理，只能成为最底层的执行者，因为他们没有办法去思考和优化自己的工作，只能听命于别人，最终也就只能在基层工作，写写文档、出出主意。5．学习能力
学习能力对产品经理尤其重要。一方面，由于产品经理面临的问题随时在发生变化，昨天是怎样解决用户的一个特殊需求，今天可能是怎样让产品上线延迟的风险降到最低，处理不同问题所需的知识显然不同，很多要从原本陌生的知识领域获取；另一方面，互联网和产品也是日新月异，旧的知识和经验难以支撑太长时间，需要随时更新。
这里说的不只是要学习，而是要掌握独立学习、解决当前问题的能力。许多产品经理习惯做伸手党，直接向别人要解决方案，或者期望通过哪本书、哪个培训就能让自己立刻变优秀，一蹴而就，这样并非具有学习能力，只是偷懒而已。6．责任心
具备比较强的责任心表现出来就是，要求产品经理随时在线，下班后或者假期中还要解决问题，用户的反馈要悉心回答，开发部门的同事们加班要一起陪，并不是自己的工作也要努力去完善……说白了，更强的责任心意味着要把更多的时间精力投入在工作上。许多人并不愿意这么做，因为看似收获和付出不成正比。
我认为不是不成正比，而是付出和收益会有时间差。有责任心的付出，在一定时间后会让你更了解用户、得到同事和领导更多的信任、更熟悉公司的工作流程，也就会成为更好的产品经理。7．对产品有一定追求
有一定追求的产品经理不会逞口舌之快，说自己的理想和远大志向。有一些产品经理则认为产品的工作无非就是按部就班实现功能、完成任务，并没有对产品的未来寄予多少期待。相比改变世界或者只是赚份工资，我觉得介于二者之间的把事情做成、让用户更满意、为社会创造价值是更好的心态。
由于所处环境不同、状况不同，大家所具备的素质也就不同，不过作为好的产品经理，我觉得一般都具备充分条件（1~3）里的某一项或多项与必要条件（4~7）里的大部分项。做产品经理，别做页面经理1．整合能力
最近在工作中，我们遇到一个不大不小的问题。
按照业务需求划分的产品经理，逐渐不再负责一整个产品或者整个平台了，而是更加专注自己负责的部分。这样原本没有问题，但在整体的体验上，却产生了很多糟糕的产品设计漏洞。
比如，同样一个内容，在这个功能里名称是A，在另一个功能里名称却成了B，名称不一致，让用户摸不着头脑。再如，用户在某个地方看到了一个功能的说明，却不知道该去哪里使用这个功能。
这些看似很幼稚的错误，就在产品经理互相协作中不断出现。究其原因，是不同的产品经理负责的模块，整合在一起才是完整的功能。比如调度、计费和时效考核，跟订单相关的三大模块，整合在一起才能对订单进行描述和操作；又如积分、商城和任务，则是对骑手来说相关联的又各成体系的部分。2．不要执着于某个单独的功能
我见过的很多新人，都有一个特点，就是对表面文章和单独的某个功能有特别的执念。
我面试过一个同学，她对网易云音乐的某个界面非常有研究，能在这个界面上做几十处改造，并且也能说出做出这些改造的原因，能讲出各种论据来作为支撑。
我说，我认可你的这些说法。但是你改造之后，对用户其他地方的操作，是不是也会有影响？跟其他功能的配合，是不是变得糟糕了？3．工匠精神
产品经理经常跟工匠精神挂钩。大家都知道，做产品要对产品有足够的热爱、要能够理解业务、懂得用户。于是，抠细节、琢磨每个功能的局部，就成了产品经理的美德。
不过我越来越担心，我们变成了页面经理，而不是产品经理。
对于一个页面，我们得心应手，做得无可挑剔。但是这个世界上不存在只用一个页面的“页面用户”，对于每个用户来说，他是来用你的产品的，他的体验都是连贯的。4．页面无法打动用户
之前创业做O2O的时候，我就明白了一个道理。美甲用户在你的平台上预约美甲，从查看样式、预约上门、接受服务到售后服务，每个环节都是用户体验。一旦某个环节出现问题，那整体体验也就废了。
只靠App上几个流畅的页面，是无法打动用户的。5．用户体验的连贯性
我跟蚂蚁金服的产品经理朋友聊天时，得知他的工作范畴后，惊异于他负责的模块之小、事务之具体。在大公司，每个一线产品经理做的事情有多细小，对创业团队产品经理来说是不可想象的。他们真的可能是一个人负责一个页面。
也许这就是支付宝的用户体验难以连贯的根源。用户每次切换页面，其实都是换了一个设计者，就像去一个商店，每走一步就换了一个售货员一样。
我跟朋友讨论说，微信大概就好在有一个人能够把控用户体验的连贯性。6．产品经理不是页面经理
要始终记住，我们是产品经理，而不是页面经理。
做电商的时候，我们要知道用户从下单到付款完成，再到收货和售后的连贯体验。
做社区的时候，我们要知道用户从看帖、点赞到发帖、评论的连贯体验。
在用户进行每一步的时候，不要让用户感到迷茫，不要让每个页面都需要用户去重新认知和理解，要让用户能自然地完成每一步操作、找到每一个可能需要用的入口。
让用户真正能用产品顺畅地满足需求，而不是在每个页面驻足惊叹设计的美妙。
这才是做好了产品。产品经理最容易忽略的是什么事？
按我的理解，以下几点是产品经理或者产品负责人会经常忽略的。1．任何事情要考虑全面，逻辑链条清晰
对产品经理来说，想出好的点子只是副业，怎么把产品流程的设计顺利圆满没有遗漏地完成才是天职。
比如，作为电商产品经理，除了正常购买流程，每个环节的错误页面补全了吗？每种问题的处理情况想到了吗？遇到网络信号不好时界面会是如何的？用户没登录、没绑定支付、没支付成功的时候交互如何？用户登录失败、绑定失败、支付失败的交互又是如何的？
所以，这可能是你初步想象到的正常页面逻辑：
这可能是实际的页面逻辑：
这其实是做产品时最容易忽略的事。2．满足需求的功能大于优质用户体验
产品经理如果看到一些很炫的App，尤其是一些很炫又相对比较成功的App，会误把它们的成功完全归功于用户体验。
我可以负责任地告诉大家，包含交互、视觉在内的用户体验，在用户需求尚未满足前，都是废物。满足用户需求是1，而用户体验是可以在1后面添加的0。
我见过3D效果做得像科幻片里的特效的App，同事用手机给大家演示，所有人都赶过来围观。这个App有用吗？有用，但只有一个用途，就是拿出来让大家围观。
当然，档次高了，感觉用户视觉上舒服了。但你作为用户的时候，会发现特别难用，无从下手。作为大而全的电商网站，更多信息展示显然比界面简洁更重要。
所以永远记得，先满足需求，再考虑加特效。3．理解需求背后的原理和原因
产品经理很多时候是需求承接方，有时需求来自老板，有时需求来自同事，有时需求来自用户。这时候，一定要明白一件事情，就是他们给你的是明确无误的需求还是实际的方案！
比如，老板的要求可能是这样的：给我做个客户端实时记录美甲师的所在位置。
作为忠贞不贰的员工你可能就去落实了。但实际上，你需要搞明白老板为什么要这么做。在再三的追问下，老板可能就告诉你原因是：美甲师经常会为了奖励刷单，也就是不出门让朋友来下单。做个客户端记录所在位置用来帮助判断这个。
你理解了老板的需求，下一步做的时候就知道，要查美甲师是不是刷单，没有必要实时做记录，这样做不仅会增加美甲师端的流量消耗，也会增加服务器的负担。正常的接单时间都会大于半小时，因此完全可以将功能改成：每半小时记录一次美甲师的所在位置。
任何人（包括用户，严格说尤其是用户）给你提需求时，有时候只是根据自己的需求想了一个方案建议你做，但作为产品经理，要做的是理解其背后真正的原因或者原理，选择更合适的产品方案。4．有写文档或者做记录的好习惯
大公司会有详尽的文档撰写要求，但初创团队和小公司考虑到效率问题很少有写文档的习惯。
许多人觉得口头表述和口头确认是初创时期自然而然的工作方式，实则不然。即使最粗糙的产品功能说明文档、交互文档和需求文档，都比任何事情全靠口头解决要好。文档和记录是规范产品研发过程的重要参考，是当大家有了争执可供确认的凭证，以及最后产品版本验收的查验标准。以免半个月后，出现没人记得现在做的这个功能当初为什么决定要做的尴尬问题。
我平时用的记录工具都很常见，供大家参考——
印象笔记：会议／讨论的记录；零散想法／点子；脑图。
Keynote（PowerPoint）：交互；用户体验的想法。
Sketch：交互。
Numbers（Excel）：数据／信息的结构。5．考虑将来可能的变化
除了要考虑空间维度上的更多情况，在产品方面，还要考虑时间维度上的状况。
包括但不限于：
版本的命名和意义（不要让用户困惑）；
版本的更新周期（不要让用户觉得烦）；
强制改版的情况（旧的功能无法使用，强制改版显然不宜太频繁）；
将开发功能的预备（与技术人员沟通将开发的功能，提早在代码层面有所准备，以防经常做太多改版）；
提前考虑埋点的情况（用来做用户行为分析）；
要上App Store的应用，在做以上这些考虑时，一定要把审核时间算上。
试读结束[说明：试读内容隐藏了图片]