《产品管理的方法都在这了看完你也能进阶产品经理》由会员分享，可在线阅读，更多相关《产品管理的方法都在这了看完你也能进阶产品经理（11页珍藏版）》请在金锄头文库上搜索。
1、本文是基于我过去的从业经验，观察、以及犯下的许多错误中总结而来的。如果要高度凝练总结一下本文的观点，如下所示：我相信产品管理的未来建立在我们对人类复杂性的洞悉上，体现在开发产品的进程中以及借以了解客户的数据里。我相信产品管理是一项具有决定意义的支持性辅助性角色，而不是某种远见性角色。我相信如果在硬技能（专业性知识）与软技能（人际交往、组织协调等不容易被评估的能力）之间做出界限清楚的划分，这将给公司的生产力带来极大的阻碍作用。而最优秀的产品经理往往具有一种连接性的作用，能够将一个组织中的各个角色，各种立场衔接贯通。传统产品经理的角色定位，技能档案中范畴拟定的太窄，有些时候还会出现错误的方向。而对
2、于一个真正伟大的产品经理来说，他的角色应该超越于会设计的工程师和会编程的设计师之上。如果你对上面的结论感到疑惑、不解、甚至是强烈反对，请继续读下去。首先要先给大家分享一下在过去的 5 年时间里产品管理所出现的四大转变，这四大转变共同指向的尽头便是产品管理的未来。产品经理的必要性在开始描述这四个转变之前，我想要先指出另外的一个转变。当我刚开始以产品经理的身份工作的时候，这个问题经常出现在耳边：为什么我应该聘请一位产品经理呢？在一些状况中，我经常听到 CTO 和专注与技术的创始人吹嘘自己的丰功伟绩：在不需要产品经理的前提下就将软件开发出来。产品经理有些时候被视为一种必要之恶，一种对公司组织架构和损
3、益表的妥协。往往这样想法的背后都是认为产品经理无非是二级程序员，他们无法担当纯技术的角色。你需要一个程序员来真正把软件开发出来不是吗？产品经理说好听点锦上添花，说不好听点就是对编程和配置代码这些实质性工作的阻碍。就算在如今的很多公司，这样的想法仍然存在，但是我已经很少碰到了。相反，人们经常问的问题是：我该怎么去找来一位产品经理？为什么会出现这样的变化，我想部分原因是因为现在很多高调宣传的高科技产品往往无法达到开发人员的预期。将软件开发出来，我指的是任何一种类型的软件，把这个想法作为终极目标，比 5 年前要难太多。如今的风投们都越来越关心那些专注于提升收入，真正了解市场的公司， 所以难怪会出现从
4、开发出来软件到开发正确的软件出来的转变。但问题就恰好出在这里。为了达到这个目标，一个人或者一个团队所需要的技能组合空前的复杂。 招聘一个程序员本身就是一件很困难的事，但是招聘一个能够掌管人力组织以及系统就更难了。前者无非局限在技术层面精研深究，而后者考量的是更加综合的能力 。当越来越多的公司都承认产品管理的重要性，自然而然围绕着这个话题产生了无数的焦虑以及困惑， 比如到底怎样才能成为一名好的产品经理以及如何寻找到他们。第一个转变：从 Agile 向 agile 的转变我相信关于这些问题的答案是随着时间的变化而不断演变的。如今我愿意跟大家分享我所观察到，思考到的一些转变，尤其是在成为优秀产品管理
5、者的这个话题上。第一个转变是在开发方式上的，它从首字母大写的灵活（Agile）转变为首字母小写的灵活（agile）。这是什么意思呢？从最初的形式上来看，Agile这个词因为其首字母大写而具有了一定的宣言成分，它是某种价值观的确立，为了鼓励灵活开发，它下面应该有一套价值观做其支撑。从最纯粹的形式上来看，Agile意味着尊重每一个个体的复杂度，承认，接受无法避免的变数。从这样的理念延伸出来一整套方法论，比如越来越细化的开发流程和工具，每一个都有着自身文档以及一系列的规则。 感觉上，这一切似乎都让招聘产品经理不再变成一件难事。你只需要从这个宏大系统中选择其中一个流程，针对这个流程选择想对应的专家，工
6、作就完成了。但这样的方法论有着非常严重的局限性。很明显，这意味着你所雇佣的这个人必须对某一系列的知识内容有相当程度的掌握，同时还要有一些特定的经验， 招聘的诉求点并没有瞄准到那些精于适应，快速思考的人才身上。而这些人正是如今小写的agile所需要的人才。对于刚开始学习灵活开发的人来说，最有效的途径就是去遵循某些简单的，不考虑任何情境的规则了。只要发生了这样的情况，那就这么做。自然灵活开发给了人一套方法论之后，很多人很容易就入了门，然后就没有然后了，就卡在原地不动了。当别人问起你在干嘛的时候，你会说我在学习灵活开发啊，然后就钻到了一套没有什么实际用途的规则当中不可自拔，反正你也不会因为学习这个而
7、被解雇掉嘛。直到要把产品真正开发出来的时限将至，然后所有人都慌了。从 Agile 到 agile，这是产品管理领域所发生的一次重大转变，而且这种转变给每一个人都带来了不小的挑战。 公司正在意识到产品管理并不仅仅是选择正确的流程，它是因地制宜，在自己公司的内部打造出来一套工作办法！什么是工作办法呢？其实产品管理有点儿像做瑜伽或者灵修。你不可能通过读一本指导性规则的书来掌握它。目前通常会出现这样的状况，这也是大多数公司不知不觉中犯下的错误：公司采取了Agile的开发办法，又或者是招聘了一位新产品经理，当现状没有大的提升改善的时候，便宣称这些方法统统失败。有很多公司能够在产品管理流程上面转换 5 到
8、 6 次，最后才意识到了根本问题是出在了人和互动上，而非工具和流程。将工具和流程改变是相对容易的，但是要把人和交互方式进行扭转则需要一定的时间，其中肯定伴随着抵触对抗。将产品管理视为一种工作方法，我想来自 Kabat-Zinn 的这段话说的尤为精辟。人们出于想要经历某种特殊情境，想要成为一个更好的人，想要降低自身的压力和痛楚，想要打破旧习惯以及旧的行为模式，想要变得自由以及睿智，往往会采取一种办法：坐下来沉思冥想。所有这些非常具有说服力的理由都让人们采取沉思冥想。但往往人们所期待的某种特殊情境，或者是意味着事情发生好转的某些信号没有出现的时候，你就顿时陷入到了被动的境地，你开始觉得自己选择的路
9、是否出了差错，开始自我怀疑是否行动上错过了某些关键环节？第二个变化：以数据驱动的产品管理向以客户驱动的产品管理转变正因为在产品管理上存在着种种的焦虑，并且还容纳进来了一种名叫软技能的东西，人们就自然而然地去寻找数据来帮忙。在我做产品经理的时候，我知道想要让自己的话立刻充满无法辩驳的说服力，那么从数据上做量的判断吧。我的屏幕上充满了各种的面板，花了大量的时间去管理和评估各种分析工具的有效性。但是产品经理的职责并不是去理解分析工具，而是要去理解客户。往往以数据为驱动的思维模式会让人痴迷于数字，脱离了客户情境本身。我们生活在这样一个大数据时代，很容易陷入到对数字执迷不悟的误区中，我们看着那些数字和表
10、盘，自以为能非常了解客户，甚至比客户自身还要了解他们。这样的想法不仅偏离了数据本身的目的，而且也将人性看得太简单了。只需要靠数据坐在房间里就能洞悉人心，完全没有必要走出门跟客户聊一聊，这样的心态自大无知，狭隘且令人悲哀。当然，跟客户直接交谈肯定会带来某种程度上的不解，尴尬，甚至会泄气，但是如果你真的想要去了解客户， 那么你就不得不放下手中的数据，接受人的行为是无法预测以及量化的。这并不是说数据全无意义， 而是数据分析应该建立在有明确的诉求和目的基础之上的 。如果没有这些内容作为前提，那么数据驱动的产品开发只是忙来忙去一场空。第三个转变：从是什么到为什么现在想想，当我作为产品经理的时候，我为能彻
11、底拥有一份产品开发路线图而感到幸福，我可是那个做决策的人，组织的大脑，某个充满远见和洞察力的人，一个能够走进来改变公司，使之变好的关键性人物啊！简而言之，我是那个告诉每一个人该开发什么的那个人。这样的想法只要稍微往前挪一步，那么你的身份角色就类似于这个产品开发小组的迷你 CEO。当我开始以产品经理的角色工作时，我真的很喜欢这样的想法，它让我感到自己无比重要，充满权力。噢天哪，有时候我看镜子镜子里面竟然会浮现出上面这个男人的样子尤其这样的时刻最让我喜欢，我的团队中的某个成员跑过来问我：我是否应该在这个领域继续开发下去？这让我觉得我简直成为了产品的灵魂所在，路线图的拟定者以及守护者，产品未来的卫士
12、，只有我能了解公司最深层次的目标和诉求不过，那是我生平犯过的最大的错误。曾经人们普遍认为：程序员就是负责执行的，其他的事儿不用管，比如商业层面的决策。程序员可以一整天耳朵里塞着耳机，一动不动的坐在工位上写代码，如果你拉把椅子坐到他们跟前，想要跟他们聊聊商业目标，对用户的理解，你现在做的这些事背后的意义是什么，换句话说你为什么要去做这些工作，一旦你有了这样的尝试，你肯定会招来厌烦的目光，他们觉得你是在浪费他们的时间，并且也让他们那么纯粹的专业技能显得不再纯粹了。让程序员工程师就专注于手头上的编程工作，这不仅仅是错误的，而且也是对工程师职位的蔑视。我从来不相信一个人能够在不知道原因的前提下能把事情
13、给干好，这样的想法当然不值得鼓励。坦白来说，几乎每一次产品经理或者高层在为什么这个问题上遮遮掩掩，其真相就是他们本来就不知道答案！现在回想起来，如果我在刚开始当产品经理的时候有个人能给我提个醒该多好啊！不去做超级英雄，那种自视清高，觉得富有远见的产品经理绝对是有毒的。产品经理的职责从本质上来说就在承接各个板块、部门、角色之间桥梁作用，他要让每个人明白自己工作背后的原因是什么，而不是工作内容是什么，这是一个支持性的角色，而不是一个远见性的角色。当被问及我们接下来该干嘛的时候，我也许会暂时感觉到舒服暗爽，但是这往往意味着我在产品经理上面的失职。如果我的团队不清楚他们正在开发的产品背后是基于怎样一种
14、考虑，他们根本不可能拿出适合这个项目的最佳技术决策来的。最终，我不再尝试去当一名产品领导人，相反我正在想方设法的让公司的目标变得更加清楚，透明，这些目标要尽可能让所有人知道，这当然会让我显得无足轻重，但是它却极大地提升了整个团队的工作效率。现在我跟某些公司合作，对项目中各个工作的轻重缓急进行排序的时候，我经常问我自己的一个问题是：这家公司的目标是否足够清楚，在我不在这家公司的时候，产品团队是否有能力像我在的时候一样，高效地排列出所有事情的前后次序轻重缓急？第四个转变：从硬技能和软技能向连接式技能的转变最后，我想谈一下从硬技能和软技能向连接式技能的转变。在招聘一名产品经理的时候，人们往往在问这样
15、一个问题：如何在硬技能和软技能之间寻找到平衡点。我认为这种一分为二的方法让公司无法找到真正有价值的产品经理，也让产品经理在工作中无法感到充足的自信。Megan Kierstead 是在产品管理和用户调研领域非常优秀的专家以及作家，他就说这里面采取的语言，软和硬之分从潜意识里就让人们觉得这是某种程度上的零和游戏，你不是这一头的就是那一头的。那么招聘一名产品经理时描述的条件应该是什么样的呢？ 往往这里面会有对技术上的强调，比如足够的技术水平来树立产品经理的门槛。这会带来两种结果，好的结果是公司能够找到一名对技术充满好奇心的产品经理，他能够有效地将任务分配下去，并且也能提出好的问题。（其实这样的技术门槛即使在目前看来也是非常低的）；如果是最糟糕的结果，公司招来的应聘者只是看起来非常像工程师的一批人，这些人不可能成为优秀的产品经理。产品经理要和工程师的角色一致，这样的想法在工程师团队中尤其受欢迎，甚至公司人事招聘上也会这么觉得，谁愿意把一个毫无技术背景的人招进来，让他给一群懂技术的人发号施令呢？他们必须有着相同的从业背景，相同的技术兴趣，特长，这样才能有共同语言， 最怕的情况就是工程师团队抱团排挤这名应聘成功的菜鸟产品经理了。但不幸的是，就算是这个人符合了工程师团队的种种期待，这些产品经
