如何构建产品经理的技能树(一)

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

我一直在这几年里思考产品经理应当具备的能力,到最近总结了很多。我把它们都放到产品经理的技能树里。大家知道,RPG 游戏技能树的各项并不一定都需要点亮的,每个人要根据各自身处的环境、要完成的任务以及想成为什么样的角色来做决策,去学习和成长为什么样的人。

jinengshu

产品经理到底具备怎样的技能,到底应该学会什么,这可能是跟「什么是最好的计算机语言」一样,至少在当前这个时期是无解的。产品经理的工作可以说是没有边界,也可以说是没有一个标准。不同公司对产品经理的定义都差别很大。关于这个问题,隔壁的运营圈子更加热闹,产品运营、活动运营、内容运营、用户运营,再加上销售、市场、营销、品牌、公关、推广等等,扯不清楚。

互联网发展至今,大家习惯了不按传统套路出牌,也习惯了日新月异。为人师表、传道授业的道理,千百年前贤者的建议都不算过时;学者秉承的科学原则和工作方式,也都沿袭了过去的标准。但五年前的互联网从业者,即使经验再多丰富,直接拿当时的经验和知识来做当下的产品,必是一头雾水。

产品经理有太多的特殊性。如果是医生,需要学医多年才有资格问诊、坐诊多年才能算专家;如果是要做厂长,要先做经理和主管,经理和主管大多是从基层来,基层工人又需要很多技能。产品经理则不同。没有公司对产品经理有很苛刻的专业限制;年轻的产品经理照样能发挥出巨大的价值;理论知识、工作技能、工作经验、熟练度这些,对产品经理的工作究竟能起到多大价值、之间又有什么关系,这些都尚未可知。

更不用说,现在的产品经理,分散在各式各样的行业里,做着完全不同的事情,在接受完全不一样的指导,成长为截然不同的几种人。

我一直在这几年里思考产品经理应当具备的能力,到最近总结了很多。我把它们都放到产品经理的技能树里。大家知道,RPG 游戏技能树的各项并不一定都需要点亮的,每个人要根据各自身处的环境、要完成的任务以及想成为什么样的角色来做决策,去学习和成长为什么样的人。

有的产品经理会变成团队扛大旗的 leader,有的产品经理会成为体验专家,有的产品经理会转向业务和运营…… 具体怎么选,应该要每个人自己定。我只负责把我了解的技能罗列出来,跟大家分享。

我会从工作流和软实力两个大方面来论述这些技能。前者主要是工作流中可能会遇到的各种各样 的实际技能,包括需求分析、产品设计和项目跟进三个主要环节;后者是从个人素质层面讲的一些所谓的修为、内功,比如逻辑判断、数据分析、沟通、个人管理等。

如图所示(不排除未来有改动):

v2-adeb4575ea5103aecf954496f2420b5c_b

工作流技能

关于需求的种种

需求是产品经理的利刃,也是产品经理赖以生存的根本武器。对需求把握得足够好,产品的各种问题都会迎刃而解,跟老板和同事的协作也会更加顺畅。搞不懂需求,需求就成了达摩克利斯之剑,搞垮产品是分分钟的事。

需求也是最老生常谈的问题。从老板,到总监,到产品经理和产品助理,都言必称需求,不管是不是真搞懂了需求。需求是一些人的武器,也是另一些人的遮羞布和皇帝新衣。

那什么是需求呢?可以用一句话「需要的、希望得到的某些东西」来概括,许多新人产品经理也单纯觉得「用户肯定需要」就能定义需求了,这都远远不够。

互联网产品中,太多需求就是这么拍脑门、拍大腿… 随便拍什么拍出来的,却没有经过谨慎的考虑。

1. 谁?

之前在设计一个计算器 APP 时,我跟同事们正在头疼写发票时人民币要大写的问题。我们觉得,作为计算器,要是有一键转换成人民币大写文字的功能,肯定能有价值,这个需求肯定也存在——我们自己经常遇到的需求,不就是大家常说的真实需求吗?

后来,我们打消了这个念头,道理很简单:到底谁有需求?

v2-01ebda2f6202e20dad1b5d9f2e5a0a4b_b

到底是谁的需求?这个问题寻求的是需求的主语。如果按照最常见的方式区分,那就是 C 端用户( to custumer)、B 端用户(to business),以及其他用户,如图所示:

v2-b1983c985b189a51e12d12e446f295f1_b

对于 to C 的对象,也就是通常意义上的用户,一般是消费者,我们跟他们的关系相对疏远,需求的清晰程度低;to B 的对象,则关系更近一层,需求的内容相对比较具体,大都是企业级的用户,或者我们公司内部的其他部门的同事。而另外的特殊需求,比如老板的、投资人的一些需求,往往是根据特殊时期的特殊情况给出的要求,这样的需求往往不是常规需求,处理方式也都不同。

还有一个常见的分类,按照下图所示:

v2-456e98b133c96f3525d05208497b73e0_b

这是三个层次的用户,依据离产品或功能的关联程度来区分。(第二行的中文直译是「一手、二手和三手」,不够准确而且听起来怪怪的…… 所以还是用原文吧。)比如,假设我们是做公司集体午餐的,我们的产品直接用户是白领,是他们吃到我们的午餐;HR 是间接的用户,他们要对午餐做判断,看午餐是不是符合他们视角的需求;老板则是更间接的用户,他也要从自己角度做判断。

另外,还有一个角度,就是从更宏观的方面去看用户,看的是用户群体,也就是通俗所说的消费市场、或者行业状况。

我们经常说「这个需求可能是长尾需求」,或者「这个需求大概是垂直的需求」。这都是从并非单个用户的角度出发描述的,而是从群体层面的描述。

大致可以分为这样几个层次:

v2-d39f2db21b1129dc48ee3ced44b2aa14_b

每个用户所代表的,可能是仅仅自己,也可能是他所在的圈子,可能是整个行业或阶级,甚至可能是整个社会。在不同的层次,讨论需求意义当然也不一样。

需求的主语是核心元素,如果没有主语,我们只能证明「需求的存在性」,但证明不了我们「是否要满足需求」。

2. 心智层次

同样广泛存在的误区是,很多人对需求的心智层次不够敏感。说句不好听的,当前的大多产品经理都是文档产品经理和功能需求产品经理,他们更多关注点是当下用户的直接需求,比如用户怎样去下好一个订单、用户怎样去注册和登录页面更顺畅等等。

而像我们每天耳濡目染的「产品大神」的一些思维方式,比如乔布斯、张小龙他们的产品思路、设计方法,在我们的工作中都完全不能适用,这就造成了很大的错位。很多产品经理也表示找不到自己的位置,读了很多文章,依然过不好这一狗生。

从根本上说,并不存在「我们关注哪些需求是对的」这一说,并不能说讨论整个用户群体的人性概况,和讨论某一个按钮的摆放位置哪个更重要,而是这些需求我们都要条分缕析、搞清楚。

如下图所示,是一个示例。

v2-67a277703446b04dccd1ab62d2ea4221_b

这里面的每一条,我们能都说是需求。用户想办健身卡,这是需求吧?用户想通过健身卡减肥,这也是需求吧?用户想要在健身房里变瘦,同样是需求吧?…… 只是,每条需求,它们所在的层次不同。

在英文里,wants 和 needs 都能翻译成需求,它们能很好地表达两种不同的概念:一种是用户表达出的意愿,而另一种是意愿背后的需求。比如,表面上用户想要点外卖(want),背后是用户饿了、需要吃东西(need)。

再往更深层去分析,我们可能得到更多需求描述。像有的人减肥,是为了要瘦身,瘦身又是为了提高自己的形象气质,提高形象气质后就更有社交竞争力、有社交价值了。这些是相对直接和显著的需求,与其并列的,还有潜在的需求,比如瘦身的过程中不希望花太多钱(如果太贵,即使能瘦身也不会来)、不希望影响健康(不考虑手术和绝食),由于要提高形象气质,瘦身也要更科学合理,不能变丑(练成了变态肌肉男、肌肉女),同时也不要由于健身耽误了太多时间,破坏正常的社交。

我们要考虑每一个层面的需求,并且确保它们都能得到满足。所以,需求是在哪个心智层次的、是现实需求还是潜在需求、是用户意愿还是真实需求…… 都要做详尽的考察。

送你三句话(by Michael Sueoka):

v2-38bdc00caa17d1d7a49590c3d92d195f_b

3. 需求的价值

有了需求的主语和需求在用户心智里的层次,我们也就能够大致得到需求的价值。判别需求的价值有很多角度,最常见的是 Kano 模型里提出的需求类别,分别是基础型、期望型和兴奋型,如图所示:

v2-bee5a17b08d9ea3e17b54ddaa8bda89e_b

如果我们是要做电商产品中用户寻找产品的功能,那不同的需求,对用户的意义是不一样的。最基础的功能是「索引和分类」,这样至少能保证用户可以定位到想找的商品,也是绝大多数电商网站的基本功能;「文字搜索」则是一个进阶的功能,用户对这个功能的需求是有期望的,没有的话,用户会觉得很糟糕;「语音搜索」和「个性化推荐」这样的功能,则是能让用户兴奋的需求,不提供没关系,但有的话用户会更满意。

根据需求的价值,我们也就能顺利进行后续阶段的设计和实现了。

4. 做什么

对产品经理来说,以上所述的需求相关的元素都要清晰、明确。那么在需求方面产品经理究竟应该做哪些工作呢?

v2-645bc91b6b4a38b43780a3ad78e9175b_b

在我的理解里,需求挖掘、需求分析和需求验证,这三个环节都是必不可少的。

很多时候,我们都会忽视其中的一个或者几个环节。像只顾着拍大腿和拍脑门,就是完全罔顾这三个环节去考虑需求。

需求挖掘是指用相对合理和科学的方法,收集数据、获取信息,得到证据,来填充关于需求的方方面面的知识(像上文所述的内容)。需求分析,则是根据得到的知识,做出一些判断,生成一些结论。需求验证是所谓互联网思维最重要的组成部分,就是通过快速迭代去验证我们判断的需求是不是真实的(real)和正确的(correct)、以及对需求的描述是不是准确(accuracy)。

另外,现在产品经理在需求分析方面的工作,并不像传统行业或者其他学科一样,想法、判断是独立的,而执行、实施是独立的。需求的挖掘、分析和验证其实会渗透在工作的各个阶段、产品的各个时期,我们无时无刻不在对需求做判断、做分析。

总之,需求的方方面面涉及很多知识,也涉及很多方法,并非是依赖简单的「冥想」、「思考」和「头脑风暴」能完成的。那些在咖啡馆里谈笑风生、自以为发现了惊天大需求的人,往往都不是真正能将需求落实成产品的人。

具体关于需求的一些方法论,我会在后续连载中继续讲述。

推荐阅读:

1. Don’t design what users want

2. We need to talk about user needs

3. 产品新人该如何了解用户需求? – 刘飞的回答

#专栏作家#

刘飞,微信公众号:刘言飞语,人人都是产品经理专栏作家。互联网产品经理,先后在锤子科技、嘟嘟美甲和点我吧任产品经理,知乎产品经理领域最佳回答者之一。豆瓣阅读《最好的时代》作者。

本文原创发布于人人都是产品经理,未经许可,不得转载。

您的赞赏,是对我创作的最大鼓励。
4人打赏

评论( 5

登录后参与评论
  1. 很棒,飞哥文中的插图是用什么做的呢,很清晰有冲击力

    回复
  2. 分析的很透彻

    回复
  3. 学习了 刚从TE转PD

    回复
  4. 受益良多,感谢

    回复
  5. 需求分析,最重要的是分级处理;才能体现出产品迭代的价值。

    回复
加载中