如何做好一个产品经理
作者: 来源: 文字大小:[大][中][小]
一个网站是个产品，一个软件是个产品，一个频道、一个栏目、一个专题也是产品，应该是一篇对所有互联网从业者都有用的文章；依托互联网大大降低了产品实现的成本，而创意变得越来越重要。从需求框架、功能设计，到沟通开发、栏目调整，再到BUG修正、用户反馈，每一个环节都需要一个好的
产品经理来推进。研发——内容——市场，中间者更处核心，更重要一点。总结有这么几点：1、以为用户考虑的心态为开发同事考虑2、不要因为一个小功能绊住产品的进度3、跳出小组向你真正的用户群发起调查4、以战略眼光解决BUG而非战术级的治标5、不要尝试做通才需要专项领域的专家6、跨部门间的多种语言和多种思维沟通以下系转载——如何做好产品经理一：你们是傻的吗？如果你想做一个坏的产品经理,就把那些和你意见不同的人都当作傻子。是的，你重复了好几遍你的看法，但他们就是不懂，估计他们永远都不会懂。这些人在想什么，都是傻的吗？既然你无法让这些傻子理解你说的话，干脆就让他们一边凉快去，你该做什么还是做什么。如果你想做一个好的产品经理,你得尽力去了解别人在想什么。
产品开发总是伴随着这样那样的冲突。最终用户的需求可能和产品客户的需求矛盾。你的销售可能不喜欢你的市场团队做的事情。你好不容易搞出来的产品需求可能被开发组拒绝。界面设计师和产品构架师也为了几个要点吵个不停。成功的产品经理要能够解决这些冲突。你不可能避免冲突，你需要在冲突发生的时候有效率的化解它们。化解冲突最有效的方法之一是：设想你是错的而别人是对的（哪怕你百分百肯定自己是正确的），设身处地的去理解别人在想什么，你可能会看到一些不同的东西。作为产品经理，我们努力去理解我们的客户的需要，目标和行为，但是我们似乎很少给予我们的同事足够的尊重。一旦吵起来，指责的声音总是比理解的声音要大。我们可以全心的为我们的客户设想，为什么不能也为我们的
销售人员，市场人员和开发人员想想呢？《哈佛商学院实战新知》（HarvardBusinessSchoolWorkingKnowledge）最近刊登了DeepakMalhotra和MaxH.Bazerman一本新书的摘录，讨论如何和“不理智”的人谈判你谈生意的时候遇到“不理智”的人该怎么办？在你完全放弃之前，做个深呼吸然后问自己3个问题：是不是有什么信息是他们不知道的？是不是他们有什么考虑是你不知道的？是不是他们有什么潜藏的利益是你不知道的？这篇文章接下来简要的说明了你该怎么判断和处理这三种情况。大部分情况下面，这些“不理智”的人实际上都是理智的，仅仅因为你了解他们太少才会觉得他们奇怪。（这篇文章还谈到了如果你真的遇到了傻子该怎么办，当然，这种事情很少发生）如果一个产品经理尝试着像理解客户需求一样去理解自己公司上上下下的同事，他自然就容易处理冲突，也能建立不错的人际关系。所以，面对（并尝试理解）而不是逃避你工作中遇到的的“不理智”行为，会让你的工作更快更好。如何做好产品经理二：客户要的是价值，不是功能如果你想做一个坏的产品经理，那就给你的产品加上尽可能多的功能。产品的功能越多，就越可能满足用户们各种各样的需求。谁都希望产品越来越好，嗯，多加些功能就好了。加上一堆小功能要比加一个大功能要好，大家不就喜欢多吗？如果你想做一个好的产品经理，尽量用少而精的产品功能给客户带来价值。客户购买产品因为他们想要解决手上的问题。产品功能本身是没有意义的，只有当一个功能真正帮客户解决了问题，这个功能才真正有“功能”。但是，产品经理经常没有做对。他们搞出一个功能清单，然后让开发人员估算开发时间。他们倾向于要尽量多的功能，所以一些重要但是比较耗时的功能往往就不做了。这样开发出来的产品充斥着不太重要的小功能。不要再去算这个阶段你要发布几个功能了，产品经理应该算算要给客户带来多大的价值。
产品管理不意味着发布最多的功能，恰恰相反，你应该发布最少的功能。硅谷产品组（SiliconValleyProductgroup，一个多人博客）的MartyCagan在好产品靠的是设计一文中提到：产品经理的职责是：定义出一个尽可能简单的产品来满足用户需求。产品越是简单，用户越容易理解，开发的时间越短，产品的技术构架也越容易。产品经理还需要经常考虑产品现有的功能是不是真的有价值，有的时候还应该考虑移除某些功能。当一个产品经理设计出给客户带来价值且最简单的产品，这个产品会容易销售，容易支持，容易维护且为用户和公司带来更大的价值。如何做好产品经理三：倾听用户的声音，也要揣摩他们的心先解释一下后文中不断提到的定量研究（quantitativeresearch）和定性研究（qualitativeresearch），这里两者都是指做产品的市场/用户研究，其中：定量研究（quantitativeresearch），一般指会产生统计报告（各种数字）的调查，比如对产品感兴趣人的百分比，使用过竞争对手产品人的百分比，对产品的评分什么的。定量研究的手段有用户问卷调查，或是小组座谈会（focusgroup）等。定性研究（qualitativeresearch），一般不会产生数字报表，它有可能是产品经理和客户一对一的面谈，用来发现一些用户面对的问题或是潜藏的需求。这样的研究由于耗时大，所以不可能大规模开展。本文英文原标题即为“理解定量研究与定性研究”，译者担心略显枯燥，于是标题党的改换成现在的样子。$TCSPLIT$
--------------正文开始的分隔线$TCSPLIT$
-------------如果你想做一个坏的产品经理，只做定量研究就可以了。做生意就是和各种各样的数字打交道，要不然，为什么学校一定要给你开一门统计学呢？如果你搞不出什么看上去像是统计报表的东东来支持你的看法，你的看法多半不靠谱。想想看，一个上百万用户的产品，怎么能依靠几十个人的意见来做呢。问题不在于用户有什么看法，而在于总共多少用户有这种看法。如果你想做一个好的产品经理，你得定量研究和定性研究两手抓（两手都要...)。数字是好东东，但是只看数字会让你遗漏关键的信息。在产品开发过程中，通过定性研究得到的发现可以（或者说应该）通过定量研究来证明。比如说，你可能通过用户访问或是种族研究（译注：这个比较西方，中国没什么种族的问题）发现了一些潜藏的用户需求。所以，你接着搞了一次较大规模的问卷调查，希望从更多的用户那里了解这个需求是不是真的重要，以及用户愿意花多少钱为解决问题买单。很多才入行的产品经理几乎没有任何市场研究的经验。一旦有市场研究的需要，他们往往就那么两招：问卷调查和小组座谈会（focusgroup）。产品经理们甚至可能没有意识到还有其它的方法做市场研究，也不理解这些方法之间的区别。一语以概之：定性研究关注于发现需求，理解用户，探索未知（不仅你不知，你的用户也未必意识到了）。定量研究关注于验证和细化定性研究的发现。再说详细一点，如果你希望探索那些用户自己都不能明确表达的需求，递给他一张问卷让他打出1到10分对你没什么帮助。当然，这种卷子可以帮助你决定产品功能的优先级。同样的，当你想出一个新点子，希望看看人们是否愿意为了这个产品买单，你搞个6个人的小组座谈会也没有意义。但是这个座谈会可以帮助你理解潜藏的问题，用户偏好以及一些细节。产品经理没必要成为定量研究和定性研究的专家，但是有一些经验总是好的。重要是你得理解这些市场研究手段的用途和局限。有很多不错的定量研究和定性研究的书。下面推荐两本：ObservingtheUserExperience:APractitioner’sGuidetoUserResearch（关注用户体验，用户研究实践者指南，MikeKuniavsky著）。这本极其优秀的书介绍了大量的用户调查手段，特别关注在互联网，软件和高科技产品上。它非常详细的描述了种种技巧指导你学习，同时又不失参考手册一般的简洁。QualitativeMarketResearch:AComprehensiveGuide（定性市场研究完全指南，HyMariampolski著）.这本书针对各种定性市场研究方法提供了不错的概述以及实施指南。好的产品经理应该善用这些资源来理解不同的市场研究和用户研究手段，并且在工作中合理使用。如何做好产品经理四：产品经理们，遇到Bug请别十万火急如果你希望成为一个失败的产品经理，在遇到bug时，请立即动手修复它。如果bug可以立即被修复，为何要一拖再拖？PM应该是一位“执行者”，而非总是纸上谈兵的“思考者”。当问题出现后，必须在第一时间搞定它。当然，这样做可能浪费大量的时间，也可能分散精力，不过这是一位PM的最佳时间分配方式，不是吗？如果你希望成为一个成功的产品经理，在遇到bug时，请不要总是立即着急的修复它。不可否认，我们在遇到问题时，总是迫不及待的想改正。然而事实上，其实根本不用那么的十万火急，理由如下：如果迅速解决了问题，你可能会忽略问题的根本原因。在大多数时候，每个问题都有其根本诱因。在问题刚暴露的时候，诱因一般深藏不露，有很多的可能性。笔者认为，根本诱因最可能来自于需求确认阶段。多篇文章都探讨了这方面的问题，比如：StopGatheringRequirements,Followuponrequeststolearnmore,Findsolutionsthataddressmultipleproblems.同样，在产品管理的其他阶段，这个理论也适用。有些问题可以很容易就找到根本诱因，但产品开发的真正挑战来自各种不稳定的因素。例如，有时候一款漏洞百出的产品在上线之初，只暴露了冰山一角：一个很小的Bug，似乎十分容易解决。另一个例子，开发过程中，团队成员对各项功能的优先级有争议时，靠“民主投票”来做决策，而忘了引发争议的源头：对产品远景、战略及计划缺乏共识。医生治疗的是疾病，而不是治疗症状（译注：治疗感冒或支气管炎，而非咳嗽）。医生的任务不是治标，而是治本。对于PM而言，道理一模一样。让问题暴露一段时间，或许是让大家认识到其严重性的唯一方法。很多父母都会说，他们的小孩吃一堑才长一智——例如，不去摸滚烫的炭炉——若小孩自己被炭炉烫伤一次后，他们自然会明白那东西是摸不得的。在产品开发过程中，存在着同样的道理。当你试图请同事修改或改进某功能时，你需要解释这是为了什么。如果大家不明白改进的意义，自然会无动于衷。举个例子，假设你发现团队使用的需求管理软件存在着很大的问题，假如你希望马上修改它，或许得花大量精力去告诉大家修改的意义，还得制作demo进行说明。但如果让这个需求管理软件继续运转一段时间，让它自己暴露出弱点，可能是一种更好的办法。因为需求管理软件的问题，在新产品上线前，你会发现有些最初制定的需求并没有实现。此时，你可以告知大家这些遗漏的需求，但是不需要为之耽误了上线时间。如果你是正确的，要不了多久，大家就会意识到，因为使用了那个糟糕的需求管理软件，才导致产品出现一些无法挽救的Bug。提醒，本方法需十分小心的使用。作为PM，就算你本意是为了让同事们更透彻的看清问题，也不能忘了你是该产品最终成败的负责人。所以多数情况下，使用本方法时，最好选择小项目来作为案例。问题可能没有你想象中那么严重。每次问题出现的时候——产品暴露了Bug，用户发出抱怨，会议上的争论——看上去总是迫切得非解决不可。于是，PM不得不暂时暂停正在进行的真正关键工作——战略、计划、用户调研——而把精力用在四处“灭火”上。然而，必须立即解决的Bug其实很少。同时，与PM应该着重思考的产品方向等问题比起来，这些Bug的重要性实在很低。每个Bug都有看上去万分关键的时刻，但过段时间后，它们似乎都变得无关紧要了。事实上，真正严重的Bug会迅速暴露出来。牢记这一点，会让PM把时间用在刀刃上，而不是每天都在处理危机。花更多的时间可以找到更完美的解决方案。若在全面了解Bug之前，就急着去为Bug寻找答案，我们通常会选择脑海中冒出来的第一个解决方案。这可能也算是一个过得去的方案，不过若我们花更多时间来分析此Bug，找到其根本诱因，甚至来一场头脑风暴，或许我们能发现更完美的解决方案。当然了，花更多时间也不一定就找得到更棒的方案，但至少，花了时间之后，得到的不会是更少的备选方案或更差的解决方案。下一次遭遇Bug时，请别十万火急。PM需要有战略眼光（不是战术），请先分析Bug，找到根本诱因，并衡量全局重要性，再对Bug进行解决。若不是每一次都着急解决每一个Bug，PM可以花更少的时间四处“灭火”，从而拥有更多的时间去思考产品战略——如何给用户带去更多的价值。如何做好产品经理五：产品经理需知：领域专家的重要性我们已经讨论过产品小组内所有的常规职位。但在有些公司，另一非常规职位仍旧存在，这一职位有许多名字，比如专项问题专家（SME）、领域专家、商业分析师等等。这些名字背后的职位具有同一特征：他们都是某一领域的专家。举个例子，税务软件公司的员工中有税务专家；薪金服务公司员工中有深谙国家、州和当地薪金税率法规的专家；健康软件公司员工中有内科医生、护士和其他医务专家。通常产品经理必须具有适用领域的知识。但是对于某些特殊产品，公司（尤其是产品经理）必须邀请这个领域的真正专家用特定知识来解决问题。产品经理会在很多情况下用到专家。在产品发掘阶段(productdiscovery)，产品经理需要这些专家来深入了解市场、了解用户、了解这个领域、尤其是了解这个产品是不是符合商业逻辑。同理，对于市场调研公司（QAorganization），专家用来负责定义测试案例、了解预期行为，以及参与接受性测试（acceptancetesting）。不要以为有了专家，你就不需要直接和客户/用户进行对话了。总之，专家不能代表你的用户。如果你的用户能够直接接触到专家，他们就不需要你们的软件了。在某一领域，专家要比普通顾客懂得多得多，所以，他们自然会比顾客更关注你的公司。公司通常不知道如何“编制”专家。有时候他们是调研组的一员，有时候他们是产品经理组的一员，而其他时候他们发现自己在公司编制的边缘游荡。就我个人而言，我更希望专家被编制到产品管理小组，因为他们主要是产品经理的共享资源。产品经理应该趁早用这些专家，尤其在产品挖掘阶段，应该多加使用。对于大部分公司，专项问题专家并不是必须的。让产品经理为了某个产品而成为某个领域的专家通常被认为是合理的。但当某些特殊产品急需某领域的专业知识的时候，专家的角色就变得十分重要。甚至可以说，他们是公司里举足轻重的人力资源。如何做好产品经理六：精通多门语言的产品经理我在国外旅行的时候，总是被那些会说n国语言的人雷到。有一次我在布鲁塞尔机场，登机口的检票员至少可以说四国语言，而且她还可以在不同语言间流利的切换。她说着法语送走一位乘客，然后回头回答了一个德语问题。她用近乎完美的英语和我说了一句话，当我走开时候，我听到她用西班牙语（呃，或是葡萄牙语）和另一位乘客交谈。我真的沮丧了好一段时间-我的西班牙语都快发霉了，而且从来也不算流利。我希望我也能精通一门外语，能亲切的用别人的母语问候他们，而不是冷冰冰的希望所有人都会说英语。仔细想想，我对自己要求太严格了点。毕竟，我们产品经理也在自己的公司里面不也说着多种语言吗？也许我不会说法语德语中文弗兰德印度语，但是我真的会销售语，研发语，市场话和推广话。好的产品经理精通公司不同部门的方言，并且帮他们翻译。当销售说：“只要我们的下个版本有这个功能，这一单就拿下了。”他们实际上是说：“这单生意多半搞不定了，但不是我的责任。”产品经理应该让研发人员理解这个含义，然后继续做计划好的事情。要是销售直接去向研发抱怨，研发很有可能相信他的话，然后放下手头的事情满足这个销售的需要。产品经理应该帮助所有人客观清晰的看待市场。当研发说：“我们要发布一个抽象层，它可以动态的暴露所有的数据元素。”（译注：读者可以忽略这句话的具体含义，在现实中，研发总是会给出这种技术上的描述...）产品经理要及时的插进来，告诉推广人员忘记那些神奇的技术术语，并专注于这个技术给产品带来的进步。给你自己一点时间想想，谁说了这句话，还有谁需要理解这句话。比如上面研发说的那句，他们从技术上描述了这个改进，但是推广部门需要了解的是这个改进对于客户和用户的好处。我才开始工作的时候，总是很紧张的给他们翻译来翻译去。渐渐的，我发现大部分的翻译工作是可以预先完成的。你需要为每个部门着想，和他们多沟通，确保他们主要关心的问题都被其它部门了解了。对于推广人员，他们的专用词汇是产品定位，我们利用产品定位来关注市场上的用户需求和我们解决方案，技术细节几乎是无关紧要的。我们可以预先把这个词汇翻译给研发人员听，他们就不会用技术细节来烦推广部门，而是专注于介绍产品功能上的改进。我们在公司里天天做着翻译。当我们承认翻译的必要性，我们可以预先做一些工作，保证各个团队都了解足够的信息来做好自己的工作。然后我们可以继续专注在市场分析上面，为了将来的成功做准备。