本文，我从一个新手的角度去记录我所理解的产品经理是什么。仅代表个人观点，仅从一个没有UED支撑的从业者所思所想出发，肯定会有错误，欢迎批评探讨。 前段时间千鸟写UCD概念在中国系列的时候，我跟他说你可以写个“产品经理在中国”，千鸟说这个事情太复杂没有经历去搞，等有时间的。于是，我一直期待到现在我想表达一下我自己理解的产品经理了…… 首先，产品经理是个舶来品，业界普遍同意的是这个东西源自宝洁公司。其英文说法是Product Manager，中文翻译为产品经理，简称PM。我试着从这2个缩写字母来理解一下目前的产品经理流派。 1、产品的经理。P：Professional，专注于做（Design）；M：Management，专注于管理。 2、产品和市场。P：Product，产品设计层面；M：Market，市场运营层面。 第一种流派是目前几个大公司的产品经理流派，每个产品经理最终的发展方向不一样，有专注于设计的有以管理为方向的，然后P1、…、P12，M1、…第二种是我自己杜撰的，基于我自己的理解，个人为人第二种缩写的解释会更适合我理解的产品经理。 产品经理是永远从需求出发的立足于产品的有良好运营思维并擅于团队作战的狼首领。 记得早前在微博上有一条关于产品经理的微博流传甚广，被转发很多次，我是这样回复的：“我们只是：开发里面最懂UI的；运营里更注重用户的；战略中比老板更知道从细微着眼的；销售中比运营更了解产品的；比谁的权利都低但比谁都会运用权利的；产品做好了最容易被遗忘的那个小人物”。这是我对我理解的产品经理的第一次概括。下面详细说下 1、产品经理首先必须要对所从事行业充分了解，先是行业专家。深度了解这个行业的用户行为、行业规则、行业特点，或者至少是资深用户，才能培养自己的同理心，才能把握住整个产品的发展方向，最终去做产品。 2、产品经理是个立足与产品有运营思维的人。之前我说，产品设计师都是自负的，他们思考问题的方式在于这个事情应该是什么样子而不是他现在是什么样子；工程师同学永远都会先考虑功能实现然后考虑是什么样子；而市场运营同学考虑问题在于老板给我的预算额度是一定，我怎么分配这些市场费用能够达到收益最大化。所以，产品经理同学就必须兼备以上的思维，在做某个决定的时候同时“人格分裂”的从这三个方面考虑一遍。 在产品团队中，产品经理必须时刻记得问自己这样几个问题：我的核心用户是谁？他们在什么情况下有这个需求？这个产品的目标与期望值是多少？并且，要让整个团队的人都有问这几个问题的意识。需求，永远都是最根本的，如果产品经理搞不清楚这个事情，那么交互设计、视觉设计、工程师都会跟着错！产品经理草率的告诉交互设计师说我们需要上一个某某功能，交互设计师有责任有义务询问产品经理，为什么要做这个，给谁做？然后才是开始去做设计！否则就只是个工具。 3、产品经理要在团队中扮演寻找满意解的角色，而不是最优解的角色。如上图所示，产品设计、市场运营、工程技术3个部门关注的产品的点是存在重叠的，而产品经理就是去发现这个重叠的部分并很好的利用这个重叠的人。 满意解的意思在于，产品经理是基于“权益”的标准来进行团队沟通的，而不是基于权利或者权力，这个解需要平衡团队所有成员的权益。所以，我一直认为，“马化腾、史玉柱等是中国最好的产品经理”的说法是有问题的，他们应该被叫做“拜用户教”教徒以及“UCD型Boss”，他们算不上产品经理。 4、产品经理的核心技能在于沟通与控制。团队以及合作的观念必须时刻具备，当团队里每个人都受到鼓励、赋予了权利并且被尊重与信任的时候，团队就会有最理想的表现。从另一个层面上看，以团队意识为核心的结果往往会是没有核心，平衡了各方的利益之后，往往把本来最有利的部分完全抹杀了，敢于拍板和为自己的决定负责对产品经理来讲很重要，也就是要讲究控制，或者按照百度的话说叫做“和多数人商量，听少数人意见，自己做决定”。记得之前有位前辈给我推荐过一本书《只有偏执狂才能生存》，受益颇多。 你可以有某个领域不会，但是，你要有能力指使会的人去做。当然，也有必须什么都去做的产品经理。我把国内目前的产品经理分为两个类别：有UED支撑的产品经理（雌雄异体）、全能型产品经理（雌雄同体）。在有UED支撑的情况下，产品经理不太需要去关注产品具体的设计细节，产品经理更加偏重于如何去沟通，去解决问题；而没有UED支撑的产品经理更多的在于学会如何最大限度的利用资源，由于从设想到实现几乎都是一个人来做，所以，偏颇在所难免，寂寞是产品经理最要命的敌人。 5、产品经理一定是最爱自己产品的那个人，并且，我觉得只有自己一个人爱是不够的，同时还需要让整个团队的成员都植入这个观念。这种爱不是溺爱，我觉得有2个方面：擅于且敢于主动的自我阉割，开放的心态接受一切批评意见；不断的向大家介绍你的产品，并推荐之。为了爱产品需要有狼性，如我在微博上所说，产品经理应该明白，资源是靠“打砸抢”得到的，别指望别人施舍；社区的运营与产品设计者也应该明白，要做好社区就必须要有铁血政策，特别是在一个充满刁民的社区，当然，对部分意见领袖的怀柔也是必须的！ 6、产品经理需要关注细节，但是不能纠结与细节。这点其实不用上纲上线，写出来只是警醒一下我自己。 没开始写之前我觉得我想的挺明白的，可是写着写着发现这些话好像是直接对我微博上说的过的话进行总结与摘抄，然后再读一遍发现好像都是废话…..不过，好吧，也许最难做到的就是那些正确的废话了，我还是记录下来了，我会不时回头看看我走过的路我思考过的痕迹的
基于Axure的PRD写作思考
本文想说的事情是，那个叫PRD文档的家伙只是个称呼而已，PRD的问题不在于如何写而在于如何被传递与执行。这里简单介绍一下我基于axure rp的一种新的PRD写法。（友情提醒：从来不用axure，认为他笨重无比的人请路过。） 从半只脚迈入产品经理这个大门的那天起我就被2个文档的名称深深的纠缠着，他们是市场需求文档（MRD）、产品需求文档（PRD）。先不论你是什么方向的PM，这2个玩意一定会一直伴随你的Title跟着你。这2个文档在不同的团队中有不同的叫法和写法，我也见过有团队的MRD其实就是PRD，不沾半点商业市场分析的边的，当然，这些不是本文探讨的内容。 长久以来，有个很有趣的现象：“有没有PRD模板，PRD该咋写”这个问题已经成为新手入门经典必问题目之一；如果1年以后这个家伙还在这行里混，他一定会抱怨，娘滴，我们的QA压根就不看我的文档、我们的交互（如果有这个职位的话）还是会问我一些我写的很明白的问题、我们的测试拿着文档问我该咋测试、…. Web页面之间的关系是网状的，而Word文档只能树状的表述，这无疑是矛盾的；PRD文档无法做到实时更新发布，我回顾了我第一年写的PRD文档，很多下面的修改栏都是空的，惭愧之至….；所谓一图胜千言，万言刚够文档标准，每个PRD都是臭长臭长的，这样的东西别说交互设计师了，很多PM自己写完了都不想看。所以，我武断的认为，撰写某些PRD文档实在是一个既耽误时间又费劲且不敏捷的事情（很多PRD都是一夜情，写完了就不会修改更不会有人乐意看100P以上的文档），是在让产品经理实现慢性自杀！ 个人认为，一个PRD文档需要包含以下的内容： 1、概述 1.1、名词说明：文档中涉及到的名词 1.2、产品概述及目标 1.3、产品风险预估 1.4、产品开发进度：产品开发阶段及责任人与时间节点 2、使用者需求 2.1、使用者需求描述：定义用户是谁 2.2、管理员需求描述：后台管理部分（很多人会忽略这个部分） 2.3、任务流程图：从业务逻辑流程到产品逻辑流程转化 3、功能需求 3.1、功能总览 3.2功能需求分解：界面分解及交互说明和用例 4、非功能需求：与该产品相关联的辅助产品等 5、上下线需求：产品的生命周期 6、运营计划：产品的上线后的反馈与改进 整个文档中，最大的部分其实是对功能需求的分解，但是最核心的部分是使用者需求与功能需求部分。使用Axure后，我发现Axure可以很好的承载我平常写的这个产品需求文档的全部内容，最主要的问题是，Axure是可以网状的展示的。下面是举个例子： 在Axure的站点导航中，默认的Home页面承担了PRD文档的第一部分内容；而使用者需求描述及任务流程图也可以由Axure自带的流程图功能完成；任务流页面的分解本来就是Axure中完成的；最后的非产品功能部分也可以由axure完成（文本块组件） 同时，Axure支持多种格式的输出，一般情况下我是发送给团队Html文件包，也可以是.chm格式的文件（团队协作目前还没有尝试）。该文件包打开后，左侧是整个系统的导航菜单，右侧是相应的说明。最主要在于，原型中的页面是可以相互跳转的（得益与axure的强大交互功能），同时页面有注释功能。所以，整个产品需求文档真正实现了基于产品的模拟，网状的传播，而不是Word式的树状阅读。 1）见过不少新手使用Axure生成的原型有页面是空白的，我问为什么，他说这个页面不知道放什么，但是又不能不命名，否则逻辑上有些不通。实际上，这个空白页面就可以用来放这个页面的流程图及整体的说明。 2）不建议做太复杂的Axure动作，比如使用多个层、动态面板等。因为在工程师等的眼里原型图是不可以点击的（基于viso等的惯性思维），所以，为了避免花很长时间去实现一个很炫的axure交互而最后被埋没，建议把任务分解来画。比如一个输入框，需要画：默认状态、获得焦点状态、输入字符判定状态、失去焦点状态等，按照逻辑分步来展示。（在我特别蛋疼的时候我会先分步展示，然后搞个比较炫的交互放在上面自己玩或者用于演示） 3）在每个页面的下方或者侧边（由页面大小来定）要放一个功能详解的文本块来对本页面的功能进行详细说明。也可以直接使用Axure自带的注释功能（组件注释、页面注释）为什么不推荐用Axure的组件注释功能？因为这个功能在生成的原型里是被隐藏的，有被人无视的可能。 4）使用axure的组件库功能（可自制）和模块功能既可以保证设计的统一性（设计规范），又可以提高原型制作的效率。图中我采用了注册模块。 下面，QA时间（这个QA是问答，文中的QA是技术，呃，注意区分） Q：为什么我看到有的书上说要写N多文档，带RD的有：BRD、MRD、PRD、…. A：是的，有这样的定义。BRD（商业需求文档）、MRD（市场需求文档）、PRD（产品需求文档）。每个公司的风格不一样，我个人倾向于把BRD与MRD整合，PRD单独做。但是MRD与PRD中会有内容重合，就是会同时提到用户是谁？为什么要做？产品目标是什么？等几个问题 Q：Axure有个功能是可以导成Word格式，把做的原型导入后是归类好的，包含了用例文档，为什么不这么玩呢？ A:没人说不可以这么玩。还是那句话，个人习惯。 Q：除了页面原型之外你塞了这么多东西到Axure里，会不会导致源文件以及生成的文件体积巨大？ A：实际上塞进去的东西都是文本，使用axure的文本组件完成的，体积并不会大。同时，请不要在用axure做原型的时候使用过多的图片，尽量是用组件和模块完成。我目前位置做的最大的一个原型是4.7M，这是一个完整的系统原型。 Q：按照你的写法Axure好像是万能的了？ A：没有不好用的工具，只有用的不顺手的人。人是活的，工具是死的，且Axure目前在mac平台下功能并非很强大，也有很多人觉得axure很笨重，更加喜欢轻量级的原型功能。不过，这些都不是核心问题，核心问题是要让你的团队能够以最高的效率进行合作。使用Axure的人不必鄙视Viso，用excel的人也不必羡慕OmniGraffle，拿Word的人也不必留恋firework。 既然提到了MRD也顺便说下我写这个文档的习惯。一般情况下这个文档是给老板看的，主要是对市场的分析、同类产品的竞品分析、我们产品的盈利预测等等。所以，一般由PPT来完成。你的文档越长老板越反感，你的文档文字越多老板越没兴趣，所以，PPT是最好的方式。 文档这个东西跟流程有类似的地方，大公司会相当重视这个事情，因为要规避风险。流程与文档的核心点在于如何高效传递如何快速执行而不是他如何写以什么形式写。相对于小团队而言，流程之殇大可避免。当然，如果大公司能够以小团队的心态去做大产品的话，定会事半功倍！我更相信小团队大产品的力量，而不是大团队大产品的说法。
基于权益的团队协作方式思考
本文主要说的是，产品设计过程中团队的分歧是不可避免的，如果控制在范围内的话是对团队协作有利的，而基于UCD的理念并由产品经理来推动可以完美的解决这个问题。 故事1，我要的是葫芦 小D：小Q，我需要一个没有籽的葫芦，能搞定吗？ 小Q：葫芦是可以搞定的，但是，没有籽的目前无法搞定，不过，搞定是可以的，但是需要很长的时间。 小D：都是男人，直接点，我在一周内需要，能不能搞定吧！ 小Q：这个很复杂，而且目前的工艺还不具备，所以，我实现不了。 小D：好吧，我早就听腻了，我要的是葫芦而已，你跟说其他的有什么用？ 故事2，放心大胆的去挑礼物吧 小Q：小D，去挑礼物吧，拣你最喜欢的拿，我付钱 小D：好啊，我喜欢那个2K的兔子 小Q：不行，我只能花20块，重新去挑吧 小D不依不饶又哭又闹，事情变得无法收场了…. 故事3，我们种苦瓜吧 小M：小D，小D，隔壁种了苦瓜耶，不少人去围观了，收效不错哦，我们也搞颗来玩玩吧 小D：呃，苦瓜不适合出现在我们的园子里，而且，来我们园子的家伙们不太适应苦瓜的味道哦 小M：为神马，为神马？为神马隔壁搞苦瓜就能火呢？再说了，等我们种了他们自然就能慢慢接受了，说不定能把隔壁的人拉过来呢 小D：…… 故事讲完，聪明的你一定也能看出来了，这里小D是个典型的设计师、小Q是典型的工程师、小M是典型的市场运营。是的，就是他们，上面三个故事讲的就是他们三个之间的世世代代都无法理清楚的剪不断的纠葛。 在 传统模式的团队里，市场运营人员从市场的角度来分析产品概念：谁需要某种产品，谁会购买这个产品，产品讲如何被供应和销售，其成本是多少；设计师根据产品 的卖相（视觉）和人机工程学等方面的知识进行测量，设计师更注重的是某个事物应该是什么样子而不是它现在是什么样子；工程师则只会专心的考虑产品技术创新 方面的概念问题，以及开发的技术成本。在这样的产品研发模式下，各自独立的专业分工，不可避免的就是出现三个中心。这也是上面三个故事出现的根源。 首 先，我们必须承认上述分歧是天然存在的；其次，这种分歧实际上对产品团队是有利的，当然，这种分歧是必须要控制在工作范围内的，工作范围外的分歧必然会危 害整个产品团队的发展；第三，控制这个分歧的理念应该是“以用户为中心的设计（UCD）”，而具体执行的家伙应该是产品经理。 一般而言，解决团队的分歧会动用三种手段，分别是：权力、权利、权益。 以权力为基准的协商过程，简单说就是动用等级制度强迫别人做他们不愿意做的事情。其结果必然是产品相互间的矛盾，在协商中输掉权益的一方在今后的工作中往往会需求反击的机会，最终损害整个团队的运转。 以权利为基准的协商手段是运用各种已有的标准、和观点等来解决纷争。这里往往会有输掉冲突的一方，或者必须选择一种折衷的方案。虽然协商各方的权利在设计过程中都有他的地位和作用，但是这种方法得到的结果往往都是常规的，缺乏新意的。 以权益为基准的协商反映了与项目相关的每一个人所关心、期待和需求的事情。我们了解每个人的喜好和工作重点，找到消除障碍的权益措施，从而使所有人所有专业的权益得到兼顾。而更重要的一点在于，用户的利益也被考虑到其中了！ 如果我们使用一种以权益做基准的协商手段为主、适当的时候结合权利基准、不得己时小心动用权力的团队协作方式应该可以得到团队效率的最大值。 所以，在一个团队里，我们应该鼓励任何人拿下面的问题去问任何人（注意，是任何人都可以这样问，特别是产品经理最需要被这样拷问！）：我们这个产品的核心用户是谁？我们是在什么情况下，满足他们的什么需求？这个产品模块的市场目标是多少？我们面临多大的技术难度？ 最后，四个问题的答案必须的是理性的（有数据支撑的），而不是以“XX这样说”、“我认为”、“以XX的经验来看”。正确答案的格式是：“根据我们拿到的数据进行分析…..”、“我们做的用户访谈说明….”、“根据市场预测并且基于我们产品的成长….”
产品经理，最是那自我阉割的惊艳
本文主要想表达的意思是，敢于且善于主动挥刀自宫是产品经理最难能可贵的地方，想明白不做什么往往比想明白做什么更重要。 记得很早的时候我在微博上说过这么一条：“每个产品设计者都必须是一个善于自我阉割的完美主义者！既要想到产品每个犄角旮旯中会出现的问题及预防措施，也要根据市场、技术等限制因素的限制对可能出 现的问题进行舍弃以保全大局。” 有的时候想想，很多事情之所以珍贵或者说弥足珍贵就在于那敢于自我阉割的惊艳。 比如，爱情为何让人觉得如此圣洁，堪比金坚的爱情为何万世传颂，其根源就在于，当你选定了一个你爱的人之后，你的心里就再无法放心任何人，TA就是你心里的唯一，从那一刻起你想的就只是为TA了。换句粗俗的话就是，你为TA放弃了整个世界，阉割掉了所有的关于“爱情”的情感，你会去主动拒绝任何异性对你的诱惑。这是一种难能可贵的品质与需要极度责任感的事情，如果怀着这样的思想去经营爱情，那必是让人艳羡的。 说回到产品上来，之前记得我写过的一系列读书笔记中讲到“产品的机会缺口来源于不断对社会趋势（S）、经济动力（E）、先进技术（T）三个方面因素（SET因素）进行综合分析研究”，由这3个因素相互作用会出现很多的缺口。那么，当我们发现这个缺口的时候该如何处理？ 个人感觉，想明白做什么不算什么，想明白不做什么才是真正考察一个产品设计者能力的地方。 按照我目前的操作手法一个产品从预感到机会的出现到最终上线会经过这样的步骤：间谍——（阉割）——演说家——（阉割或反阉割）——雕刻家——（阉割）——救火队员——（阉割）——打磨师。 简单说就是这样的： »当预感到这个市场存在的时候，先伪装成用户潜入到这个潜在市场的目标人群中，观察他们，明确他们的需求。在这个时候数据的作用只用在告诉我这个市场预计有多大，但并不能告诉我用户的真正需求在什么地方，不尽信数据。 »获取到用户的需求，根据这个需求想到能够做出A、B、C3个产品来完全的满足他们，并获得市场占有率。对这些需求进行排序，与现有资源与企业战略目标做匹配。阉割掉那些对目前战略目标没有促进意义的，目前不做死不了人的，目前团队没有精力做的功能，实现第一步阉割。 »拿着被第一次阉割的需求做需求研讨，先做团队内部讨论再到Boss那讨论。这个过程中其实就是个演说家的角色，力求团队的人首先要达成一致目标，然后去PK老板，当然，这个过程中会有第一次被阉割掉的需求再次被提上来，抗住！（如果实在扛不住，那好吧，你可以试着弱化它…） »根据团队明确的需求，进入产品设计与研发阶段。在这个过程中会有小部分的需求被阉割掉，源自技术的压力以及市场的变化。当在与技术部门周旋的时候，如果一个产品设计者在最开始的时候只做了一套方案，那就会永远被他们牵着走。善于与技术妥协是门艺术！善于妥协意味着原型必须是炮灰，而最终目标（核心需求）一定不能变化！这个阶段实际上就是个雕刻家的角色，小步慢跑，同时要调动资源，平衡利益。 »在产品进入测试阶段开始，需要准备与运营部门联姻了。告知产品的运作机制，产品的亮点与卖点以及怎么卖卖相比较好。同时，进入救火队员的角色，因为根据经验，每个新产品都会有个死角在测试的时候是不会被发现，每个产品都会有让用户痴迷而我们没注意到的地方，所以，如果产品上线不被用户骂，那只能说明产品足够差或者产品压根不被重视。这个时候，要顶住，如果他们骂，就努力让他们多骂一些出来，然后悄悄改掉。根据经验，往往骂声最高的用户也是最愿意为你做口碑宣传的用户。 »OK，现在上线了，但并不意味着结束，恰恰只是个开始，因为新的一个循环开始。这个循环我把他叫做养孩子，就像恋爱谈完了，婚也结了，孩子出来了….一个有生命力的产品是每天都会有变化的产品，当然，肯定不会是在前台，更多的是在后台的优化…. 所以，我最近常常感觉，做产品设计，其实就是个自我阉割的过程，越是优秀的产品设计越是善于阉割。 在我憋着一口真气一鼓作气的敲完上面的字之后，兔子跟我说，你这不是教人犯错吗？我想，肯定会有人没看完就直接说，你的意思就是让人一直砍一直砍，砍到最后就只剩下个小裤衩了呗…. 其实不然，这篇文章的核心不过一句话耳：审时度势，在正确的时间做正确的事情，顶得住诱惑。阉割掉的需求不等于全部抛弃，有的是需要扔进“需求池”去浸泡的，在适当的时候再返回来考虑。在产品设计阶段，其实还是之前说过的那篇：做最多的，展示最好的。如是而已….. P.S：最近思维比较混乱，所以说的很不明白。其实，我只是认为一个好的产品经理至少需要具备这样几点：有产品信仰，不惟钱；有理性思维，不惟心；知道变通，不惟己；有坚持，不惟他。
