Ev is PM

产品经理是一类人，他的做事思路与方法可以解决很多实际的生活问题。只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态去跟踪、维护这个产物，那么，你就是产品经理

当看到一个观点的时候，就有冲动去寻找与之矛盾的观点，然后通过对不同观点的分析找出背后的原因，从而更全面地理解某个事物。一个人成熟的标志之一就是心中可以容纳各种不同的思想而无碍行事。

Web的设计“不要让用户思考”，其实生活中更需要这样。

产品就是用来解决某个问题的东西。

“产品经理”这个概念，确实已经和旧有的产品经理概念不一样了。它更多地侧重产品本身“从无到有”、“从有到优”的过程，更多地涉及了“产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”等内容，而不是如传统的产品经理那样，去做已经有了产品之后需要做的诸如管理产品、推广和营销产品的事情。

互联网、软件行业是新兴行业，新兴市场，三天一小变，五天一大变，产品本身在不断取得突破，用户看什么都是新的，所以产品需要推陈出新，尽力先入为主，占领用户，主导用户习惯，这就导致了产品工作的重头戏在前期，从无到有，从有到优，偏重研发类创新。

因此，互联网、软件行业的产品经理更重视产品功能本身的规划，需要“对市场发展趋势有敏锐的洞察力和创新意识及良好的分析、研判能力”，要能不断改进产品，要“深入了解业务，挖掘用户的多种需求，不断推出有竞争力的产品”，“制定所负责产品线的发展蓝图和实施路线图”。

虚拟物品的复制成本极低，所以重点资源会投入在产品本身，较少考虑实体经济里供应链上下游的事情。于是，对产品经理来说，需求分析、设计的细节尤为重要，必须亲自把握，可能一个细节的改进就能增加上万的用户，杠杆效应也十分明显。

互联网、软件产品大多是为使用产品的终端用户所做，而且通常是面对海量的用户，用户数多了，自然就能赢利。所以，互联网、软件行业的产品经理会更重视用户研究、数据分析等工作，要“负责用户研究，把握用户需求，实现用户需求”，而赢利的事情反倒不用直接去管，会有另外的团队负责。

互联网、软件产品更重视用户体验，相应的，出现了很多产品经理会涉及的工作内容，如交互设计、视觉设计、文案设计等。举个例子，有时候为了确定两个按钮是上下分布好，还是左右分布好，我们有可能做大量的用户实验。在互联网、软件行业中，产品经理能真正体会到“用户是上帝”的感觉。

为了给用户极致的体验，我们需要做很多数据分析，而数据分析的基础在于互联网、软件产品的虚拟特性，可以大量地记录用户的各种行为数据，这是传统行业很难做到的。

管理并不是公司的管理层，如总裁、总监、经理们才需要掌握的技能，而是每个人必备的生存技能，只是每个人可以掌控的资源不同，所以需要管理的对象也不同。

管理的能力，其实就是“在资源不足的情况下把事情做成”的能力

要是我来做面试官，最在乎的是应聘者有没有激情，是否够机灵、好学，逻辑思维是否清晰，沟通表达是否顺畅。

可能会问应聘者这样一些问题，比如“谈谈我们生活中经常用的一个产品，它解决了什么问题，要是你来改进，打算怎么做？”“看电视/书/电影吗？举个例子分析一下它的目标用户。”“说说你是怎么准备这次面试的。”

重点体会某个产品功能是为了满足商业上的什么需求而做的。

关键还是要跳出以往的应试思维，做过的题不重要，上过的课不重要，学过的知识也不重要，重要的是练好思维方式，“学会”学习。

这个阶段，我是一只全新的菜鸟，没有任何能力，也不负责产品的任何模块，只是打杂。好在我还比较好学，会主动去熟悉工作中需要的基本知识和技能，主要是与需求分析相关的基本知识和技能；去了解产品的各个方面，包括功能、用户、技术等；去认识团队里的兄弟姐妹，熟悉将来要合作的兄弟部门的同事。

入行半年后，学习“怎么做”

入行一年，开始考虑“做多少”的问题，即做哪个功能不做哪个功能。

用户-用户研究-需求采集-需求分析-需求筛选-需求开发

入行两年，项目与团队，产品经理的工作不只是设计功能。产品功能的最终实现是靠一个又一个项目推进的，之前没担任过项目经理，现在总算体会到“操心”是一种什么感觉，最明显的变化是，我原来只需要接受别人的会议邀请，现在则整天给别人发送会议邀请

2008年，主导了多个项目的我已经比较熟悉这套做事方法，产品也有了相当稳定的团队，我开始试着把触角渗透到产品的各个方面，从原来的有事才去找人帮忙，转变为尽量去了解周边团队都在做什么，并施加影响，比如偏商业的市场团队、服务团队，偏技术的运维团队、架构团队，作为支撑的财务、法务团队等。随着产品越来越复杂，参与的人数越来越多，很快我就意识到一个人的精力和能力都极其有限，不可能做完所有的事情。

产品经理不可能对某个产品从一而终，总有一天要离开它。当我慢慢意识到这一点的时候，就发现不能让产品少了自己就不行，于是我总是在产品渐渐成熟的时候，开始主动定规范、定流程，把自己手上的工作一点点分出去，使得自己可以安心地去做其他事情。

入行三年小结：战略与修养

越来越觉得对于一款产品，早期的决策无比重要，所以很想参与产品初期的战略规划，早在2007年，我就参与过两次“物流平台”的可行性研究，通过产品的早期研究，我知道了公司其实想做的东西很多，而真正开始实施的只是其中的一小部分，面对那么多极具诱惑的产品，果断地放弃变得很重要，而放弃的原则与依据，就是价值观、战略这些内容。参与了一段时间的战略规划工作后，我开始意识到：找到产品的“灵魂”很重要。我也开始思考什么是产品经理的灵魂，到底哪些技能之外的基本修养对一个出色的产品经理最重要？现阶段我对此给出了四个关键短语：爱生活，有理想，会思考，能沟通。

与用户接触的过程就是需求采集的过程，我们来看看几种常用的需求采集方法，如“数据分析”、“调查问卷”、“用户访谈”等。

产品经理要通过“给需求做一次DNA检测”，来“确定需求的基本属性”、“分析需求的商业价值”、“初评需求的实现难度”，从而计算出需求的“性价比”。

资源总是有限的，所以我们只能做那些性价比高的事情，通过残酷的需求筛选，“活下来的永远是少数”。

对于产品经理来说更重要的是“发现一个问题，然后设法将其转化为一个任务来解决”。

用户是User，有时也叫做终端用户，End User，是使用产品的人；而客户是Customer，是购买产品的人、为产品付钱的人。

某天你在路边的超市买了一瓶娃哈哈矿泉水，这时你是娃哈哈的终端用户，是超市的客户，同时超市是娃哈哈的客户。

拥有“以用户为中心的思想”和“以老板为中心的行动”（或者说“以实际情况考虑如何行动”）。

不要试图满足所有用户

试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪，谁都不满意的四不像。

腾讯的产品已经充分占据了市场，拥有霸主地位，所以用户数不可能再有爆发式增长，于是只能考虑从已有的用户身上深挖用户价值，而最有价值的一批用户无疑是核心用户；而我做的那款产品刚起步，没什么用户，急需把池子做大，所以我们会先做一些大众功能，满足一般用户的需求，让用户数先爆炸起来。

所以说，优先满足哪些用户需要和产品的商业目标要结合起来考虑

试着描述一下自己在用各种互联网应用的时候，是个什么样的用户。用户的使用习惯，我先描述一下自己。创建人物角色（Persona）

E-mail：2000年的时候申请了第一个，Sina的，是私人E-mail，但是在学生时代利用率不高，没什么邮件，到2007年的时候用Gmail代收，之后就不再对外留这个地址了。现在私事用Gmail，强大的搜索功能让邮件整理的工作变得不那么重要，节省了很多时间，很喜欢它把同主题邮件合并的处理方式，适合群聊，有些文件备份也放在里面，空间够大，而且防垃圾功能做得很不错。公事用公司的邮箱，没什么好说的。

只了解做是没办法知道背后原因的，而不知道问题的原因也就意味着没法从根本上解决问题。所以我们既要看用户怎么做，也要听用户怎么说，虽然他说的不一定是真话。

定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。两者都很重要，缺一不可，只定量会“以标代本”，看到问题但不知道原因，只定性会“以偏概全”。

明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。

“说”和“做”不一致的问题：意区分用户说的事实与观点，一般来说，诸如“我做了什么，步骤如何，碰到了什么问题”这类事实的可信度更高一些。

选择样本的时候需要多加注意，尽量做到随机，

用户访谈与调查问卷之间也有联系，我们经常通过前者的开放式问题，为后者收集具体的封闭式问题。

调查问卷的样本选择，就有几个注意点：尽可能覆盖目标群体中各种类型的用户，比如性别、年龄段、行业、收入等，要保证各种类型用户的样本比例接近全体的比例，比如目标用户中男女比例为7：3，那么我们的样本也应该保持这个比例。

对于重要的问卷，为了避免问题太直接，还有个通用的办法就是先进行小范围的试答，根据反馈修改后，再大面积投放，这和互联网产品的灰度发布有着同样的理念。

可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题。

不同阶段不同的可用性测试，从中发现相应的问题。

可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户想先做什么，后做什么，为什么要做某个动作等。

做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。

对于改版，除了“可用性测试”要在足够早的时候做以外，发布后也是有一些方法改进的。

比如先从部分次级页面改起，像“我的淘宝”历时多年的改版。

在对产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。

听用户的但不要照着做

用户需求VS.产品需求

用户需求：用户自以为的需求，并且经常表达为用户的解决方案。

产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。

需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程

技术分析是“树干——树枝——树叶”的任务分解过程

需求分析是“首先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程，所以说完整的需求分析是一个“分-总-分”的过程。

伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西。

需求来源于理想与现实的差距，那么减小这个差距就有三种方式：

改变现状

降低理想

转移需求

一般来说，根据人类记忆的特点，产品有5±2个模块比较合理，如果超过7个，你就要考虑重新划分，甚至增加一个基本属性叫“二级模块”。如果你是做网站产品，这些模块的划分就很可能影响到网站的导航结构，这属于信息架构领域的知识。“产品需求+市场需求+开发需求+测试需求+服务需求+…… = 产品包需求”，对这些概念感兴趣的同学可以去查阅“需求管理”相关的资料。

层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，理论依据参见KANO模型

重要的商业价值评估，我们的做法是在需求讨论会上由产品团队集体讨论，再叫上有必要的干系人，比如销售、服务等。对于某个需求，需求提交人是对它最熟悉的，提交人先基于自己对商业目标的理解，做一番陈述，主观定个级别，比如高中低。然后大家讨论，所以在这个讨论会之前，每个人都应该做好功课

性价比 = 商业价值÷实现难度（简化为开发量）

做项目，终极目标就是：多快好省，即范围大、时间短、品质高、资源省。

需求列表里出现的任意一行，工作量最好不要超过“5人天”。

某个产品团队开始登场亮相的时候，一般要先回顾上一次产品会议通过的项目，现在进展如何，是否需要调整时间进度、是否需要追加资源、是否有重大需求变更，已经发布的项目有什么问题等。这样一方面是为了让大老板们更新对各个项目的信息，更重要的是为了积累经验，让今后产品会议上的决策越来越合理。

回顾之后，就是最关键的部分了，我们会拿出准备好的商业需求文档，每个产品都会拿出三五个，占满2～3倍的潜在资源。这里说的潜在资源，是指相对固定的开发、测试人员，因为技术人员有对产品的熟悉问题，所以在短时间内，不可能太多的人同时转去做其他产品，这也就意味着潜在的人力资源数量是在一个值附近做微小浮动的，所以我们也可以认为，在一定程度上，资源的争夺是以产品间的争夺为辅，产品内多个项目的争夺为主。

BRD怎么写，都包含哪些内容。

项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。

商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。

功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。

非功能需求描述：提一下重要的非功能需求，如果有的话。

资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。

风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。

情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。

我们用不着觉得只有“吃苦耐劳”，做了很多事情才是贡献，而应该直接从目的出发。有一句话说得好：内部（指偏技术）的大改动往往是外部（指偏商业）的小改动，反之亦然，所以我们应该在动手前先找找有没有成本低，收效大的解决方案！

尽可能多地放弃，“少做就是多做”，阿里巴巴的马云也说过。

心急吃不了热豆腐

没有产品是生下来就完美的，一天又一天，一月又一月，我们的产品反复地经历着需求采集、需求分析、需求筛选的过程，不断进化。

我们要做的事情是，在资源限制下找到最有价值的需求，然后把它做好。那么，新的问题产生了，我们得找个办法把越来越多的需求管理起来。

每个需求的去留，去的怎么去，留的怎么留，一定是需要管理的。于是我们在产品需求列表上再加几个属性项，试着管理需求的生命周期。

对于产品需求列表，也就有必须每隔一段时间、或是新需求积累到一定数量、或是由特别事件触发，拿出来大家一起讨论，这次讨论也就是更早谈到的“分析需求的商业价值”。但是，需求那么多，不可能每次都把所有的需求拿出来讨论，所以我们必须有所选择，这也就意味着需要标明需求的状态。需求的状态随时改变，但每个阶段都是谁来负责？所以我们还需要知道需求在各个阶段的负责人，以及其他一些需求跟踪的信息。

需求状态。通常有“待讨论”、“拒绝”、“暂缓”、“需求中”、“开发中”、“已完成”几个状态，

可按照实际情况有所增减，比如管理的粒度细一点，还可以增加“测试中”。

负责PD。在需求状态变为“需求中”时指定，最可能是此需求的提交人，在需求的整个生命周期中，此人要从头到尾跟进，是这个需求的主人。

除了可用 Excel 来管理需求之外，还有更专业的需求管理方法和工具，如 Mantis系统、Mercury Interactive公司的Quality Center、IBM的Rational RequisitePro等，可以根据自己的产品与团队的情况选用。

在高层决定公司战略的前提下，好的产品对我们的帮助会远远大于我们对产品的帮助。所以，产品经理的前若干年，好的公司、好的产品、好的老板，很重要。