产品经理，你的「核心竞争力」是？

本文为人人都是产品经理特约稿件&＃xff0c;未经平台许可&＃xff0c;禁止转载

———— / BEGIN / ————

以前&＃xff0c;我对待这个问题是很敷衍的——阶段不同&＃xff0c;环境不同&＃xff0c;项目不同甚至合作伙伴的区别&＃xff0c;都会要求我们具备不一样的能力。

我曾认为&＃xff1a;所谓的核心竞争力并不存在。

我仍然坚信&＃xff1a;不同环境&＃xff0c;不同阶段需要具备的核心竞争力是不一样的。

比如初级产品经理&＃xff0c;高质量高效率的输出能力是最核心的竞争力&＃xff1b;而产品负责人则要看对市场的理解能力&＃xff0c;对需求的理解能力&＃xff1b;再往上&＃xff0c;我们会更加看重他的商业能力、战略能力&＃xff0c;看布局&＃xff0c;看规划&＃xff0c;也看团队影响力。

但假如&＃xff0c;真的有这么一种贯穿始终的核心竞争力&＃xff0c;那又是什么呢&＃xff1f;

这个能力能在我们不同的阶段&＃xff0c;在不同的环境里都扮演着举足轻重的角色&＃xff0c;甚至能够直接影响我们的发展潜力。

很难回答&＃xff0c;但不是没有答案。

这个问题值得我们深思——阶段的晋升并不是转岗&＃xff0c;而是由浅到深的变化&＃xff1b;也就是必然存在某种看不见的主线&＃xff0c;这样才能保证我们不会在繁琐的工作当中走偏&＃xff0c;或者走入误区。

于我而言&＃xff0c;产品经理的核心竞争力在于&＃xff1a;对信息的处理能力

对信息的处理能力

这是我抽象出来的一个概念。

产品经理的工作当中&＃xff0c;接触最多的不是需求&＃xff0c;而是信息&＃xff1b;需求只是诸多信息中的一个环节&＃xff0c;前者是后者的一个子项。

一个idea&＃xff0c;从0到1&＃xff0c;只需要考虑需求或者场景吗&＃xff1f;

显然不是。

团队的信息&＃xff0c;企业的信息&＃xff0c;资源的信息&＃xff0c;乃至时间的信息等等&＃xff0c;我们对非常多的信息进行收集和处理&＃xff0c;才能让这个idea转变成真正的产品。

仔细想想&＃xff0c;在我所经历的项目当中&＃xff0c;最为依赖的并不是落地的技能&＃xff0c;也不是空洞的理论&＃xff0c;而是对各种各样的信息进行处理的能力——这一点&＃xff0c;在一人多职的创业项目里&＃xff0c;尤其凸显。

产品经理不矫情&＃xff0c;或者说不能矫情&＃xff0c;我们需要使用一切能够使用到的资源用来解决自己遇到的问题。

比如&＃xff1a;需求挖掘。

我曾多次强调一个观点&＃xff1a;产品经理很特殊。这是互联网少数的没有具体指向性任务的岗位&＃xff0c;我们的工作内容几乎都需要自己为自己拟定&＃xff0c;自己挖掘需求&＃xff0c;然后把这个需求布置成自己的任务&＃xff0c;俗称“没事找事”。

不妨试想&＃xff0c;在你所处的项目当中&＃xff0c;你作为产品经理&＃xff0c;然而&＃xff1a;

会是什么样的一个局面&＃xff1f;

信息处理能力之对需求的挖掘

需求是什么&＃xff1f;

本质上而言&＃xff0c;需求是一种信息&＃xff0c;以文字、语言、行为等方式所表达出来的&＃xff1b;它没有固定的形态&＃xff0c;并且不够直接&＃xff0c;甚至可以说非常的隐晦。

坦白的讲&＃xff0c;若是对信息的处理能力比较弱&＃xff0c;几乎不具备成为产品负责人的潜力——因为缺乏从信息当中挖掘需求的能力。

给大家描述一个现象&＃xff1a;

最终&＃xff0c;这个问题在下一个版本被处理。

这个现象&＃xff0c;包含了哪些信息呢&＃xff1f;

1. 该产品后台广告管理部分&＃xff0c;缺少针对版本定向投放的需求&＃xff0c;导致功能缺失。

2. 该产品缺少相应的运营规范&＃xff0c;没有约定产品内的配置内容均需要实现版本控制功能。

3. 该产品客户端在加载广告位的页面&＃xff0c;没有上报用户使用的版本号&＃xff0c;因此不能临时修复&＃xff0c;只能通过迭代发版来处理。

4. 该团队的发版流程不够健全&＃xff0c;未进行版本兼容性测试。

你还能针对已知的信息提炼出哪些需求呢&＃xff1f;

• 比如&＃xff0c;产品稳定迭代的过程中&＃xff0c;必须考虑到新旧版本的兼容问题。

• 比如&＃xff0c;与后台搭配使用的功能&＃xff0c;必须考虑到对版本的定向控制&＃xff0c;还可以延展出&＃xff0c;对系统的定向控制&＃xff08;区分IOS与ANDROID&＃xff09;

表面上来看&＃xff0c;这是一个极为普通的BUG&＃xff0c;但解决BUG的办法却是以需求的形式进行处理&＃xff1b;并且&＃xff0c;这个需求所覆盖的范围&＃xff0c;远超这个BUG的影响范围。

你觉得&＃xff1a;这是从信息当中提取的需求&＃xff0c;还是测试或者开发考虑的解决bug的技术方案呢&＃xff1f;

需求藏在信息里&＃xff0c;用户只是信息的一个组成成分&＃xff0c;它很重要&＃xff0c;但并不是需求的全部。

1. 信息处理能力之需求理解

作为产品经理而言&＃xff0c;真需求和伪需求几乎是人人都会提及的概念。

其实严格上来讲&＃xff0c;是不存在“伪需求”的——在足够大的数据前提下&＃xff0c;任何离谱的需求都是某些用户的真实诉求。

只是从性价比的角度来看待&＃xff0c;我们会将受众小、低频、性价比低的需求&＃xff0c;视为“伪需求”&＃xff0c;意思是这个需求不具备市场价值&＃xff0c;或者这个需求对应的市场价值是不靠谱的&＃xff0c;是虚假的。

正确的理解&＃xff1a;并不是人们想去太空旅行的需求是伪的&＃xff0c;而是太空旅行所对应的市场价值是伪的&＃xff0c;至于需求本身是真实存在的。

在工作当中&＃xff0c;你又是如何去判断需求真假的呢&＃xff1f;

我所知道的部分产品经理&＃xff0c;其实是在用自己的主观价值观来进行判断。

即&＃xff1a;我没有这个需求&＃xff0c;所以这个需求是伪需求。

或者&＃xff1a;我认为&＃xff0c;用户没有/有这个需求&＃xff0c;所以他是伪需求/真需求。

在极端&＃xff0c;但又常见的场景里&＃xff0c;我们又该如何判断呢&＃xff1f;

某社区类产品&＃xff0c;曾经做了这样一个用户调研&＃xff1a;

针对发布内容的按钮摆放位置的问题&＃xff0c;产品经理向用户给出了两个选项&＃xff1a;一个是放在底部按钮的中间位置&＃xff0c;类似大部分图片社区&＃xff0c;一个是放在屏幕的右上角&＃xff0c;类似微信。

用户调研的样本数是100&＃xff0c;两个选项的获票相同&＃xff0c;均得到了50票。

此时&＃xff0c;该产品经理接到任务&＃xff0c;两个位置&＃xff0c;只能二选一&＃xff0c;必须砍掉一个。

你会怎么做呢&＃xff1f;

有时候&＃xff0c;我们其实是很懒惰的&＃xff0c;喜欢将所有的选择都交给用户——有争议时&＃xff0c;就投票&＃xff1b;票多的&＃xff0c;就做&＃xff0c;票少的&＃xff0c;则砍。

但若用户没有办法帮我们进行决策时&＃xff0c;终究是要自己进行分析&＃xff0c;自己进行理解的。

这个问题其实要对需求进行深层次的理解&＃xff1a;

发布内容这个行为&＃xff0c;是用户主动、依赖的行为&＃xff0c;还是被动&＃xff0c;随意的行为&＃xff1f;

若是前者&＃xff0c;我们便可以将其置于右上角&＃xff0c;若是后者&＃xff0c;则需要将其置于底部中间按钮。

2. 信息处理之应变能力

需求变更是我们工作当中的常态。

尽管我们的口号是拥抱变化&＃xff0c;但实际上&＃xff0c;没有人真的喜欢变化——这意味着原本的计划被破坏&＃xff0c;原本的节奏被打乱&＃xff1b;也同样意味着时间变得更少&＃xff0c;加班变得更频繁。

需求变更的本质有两种&＃xff1a;其一是产品经理考虑不全面&＃xff0c;属于对需求的理解能力出现了问题&＃xff1b;其二&＃xff0c;则是突如其来的新的信息介入。

前者&＃xff0c;在上面的内容已经提及了一部分&＃xff1a;这里主要讲讲后者&＃xff0c;即新的信息介入引起的变化。

受到新消息介入影响最大的&＃xff0c;诸如与政策密切相关的网约车产品&＃xff0c;受到上游限制的淘宝客产品&＃xff0c;合作性产品等&＃xff0c;此类需要依托于第三方的决策来调整自己策略的项目&＃xff0c;必然都会受到新信息介入产生的影响。

最经典的战役&＃xff0c;无疑是滴滴&＃xff0c;面对政策的封杀&＃xff0c; 尽然硬是开出了一条先河。

但假如你是滴滴的产品总监&＃xff0c;在关键时刻&＃xff0c;你该如何做呢&＃xff1f;

假如你是滴滴的产品负责人&＃xff0c;在产品正常运营、开发团队正常开发的某天&＃xff0c;你突然收到大量的汇报&＃xff0c;各个地方的运营负责人&＃xff0c;都在向你反馈信息&＃xff1a;他们所在城市的滴滴司机被抓了&＃xff0c;并且&＃xff0c;政府多次警告网约车属于违法行为。

此时&＃xff0c;你该做些什么&＃xff0c;来保障滴滴能够度过这个难关呢&＃xff1f;

对信息的处理能力&＃xff0c;要求我们将复杂的事情简单化处理。

在我身边&＃xff0c;善于处理信息的朋友具备一些典型特征——他们似乎永远都不会感到急躁&＃xff0c;也不会感到懊恼&＃xff1b;我们能想到的所有的恶劣的情况&＃xff0c;于他们而言&＃xff0c;都只是信息的变化而已&＃xff0c;本质并没有发声任何改变。

这就如同1&＃43;1的问题&＃xff0c; 变成了3&＃43;4&＃xff0c;或者1&＃43;1&＃43;4&＃xff0c;信息发生了变化&＃xff0c;但任然是一种计算。

你能想象&＃xff0c;一位信息处理能力比较差的产品经理&＃xff0c;该如何面对新信息突然介入的情况吗&＃xff1f;

大概会是慌乱&＃xff0c;手足无措&＃xff0c;四处寻找帮助的状态吧。

这和经验无关&＃xff0c;只是单纯的&＃xff0c;对信息处理能力较为薄弱。

贯穿始终的能力

我们一直都在对各种信息进行处理&＃xff0c;这个能力就会贯穿了整个行业&＃xff0c;不管是新人又或者是老司机&＃xff0c;始终无法规避这个问题&＃xff0c;甚至我们可以将其视为对个人能力的判断指标。

信息处理能力越强&＃xff0c;产品能力也就越强&＃xff0c;反之&＃xff0c;则产品能力也就越弱。

不仅如此&＃xff0c;我们对信息的收集、理解&＃xff0c;是从初级产品经理到中级产品经理的一个瓶颈&＃xff1b;而对信息的应变能力&＃xff0c;则是高级产品经理必须突破的一个瓶颈。

每个阶段&＃xff0c;都会有不同的要求&＃xff0c;到了一定程度时&＃xff0c;这些要求就会成为我们的瓶颈。

如果你曾尝试过突破瓶颈&＃xff0c;你应该还记得这种感受&＃xff1a;

我们能够很明显的感知到自己对信息的处理能力变强了&＃xff0c;这体现在更快速得做出决策&＃xff0c;更深度的理解需求。

更重要的是&＃xff1a;能够明确的感知到&＃xff0c;自己在单位时间里能够处理的信息量变得更多了&＃xff1b;有一种拨开云雾见青天的感觉&＃xff0c;似乎一切都变得清晰明朗。

产品经理其实并没有生产任何事物&＃xff0c;只是把自己收集到的信息进行处理&＃xff0c;再以一种可视化的&＃xff0c;可操作的形式展现了出来。

需求&＃xff0c;一直都在&＃xff0c;不管有没有产品经理&＃xff0c;不管有没有对应的产品&＃xff0c;需求一直都在&＃xff0c;问题在于我们作为产品经理而言&＃xff0c;能否将这些需求&＃xff0c;从诸多信息中提取出来&＃xff0c;并以他最本质的样貌表达出来。

而这&＃xff0c;需要我们具备极强的信息处理能力&＃xff0c;也是我们的核心竞争力。

附&＃xff1a;一些产品技能所对应的信息处理技巧

• 需求挖掘&＃xff1a;通过收集大量的用户反馈&＃xff0c;市场反馈&＃xff0c;进行深度分析&＃xff0c;寻找信息总的共性&＃xff0c;关联性。

• 需求分析&＃xff1a;已经具备了某种猜测性的结论&＃xff0c;需要进行分析验证&＃xff0c;常用的方法&＃xff0c;是判断该需求在对应市场所在的环节&＃xff0c; 覆盖面积&＃xff0c;产生的价值&＃xff0c;以及未来的发展趋势。

• 产品设计&＃xff1a;结合人们的一些特性来设计产品&＃xff0c;所应用到的技巧包含但不限于心理学&＃xff0c;语言学&＃xff0c;行为学&＃xff0c;社会学&＃xff0c;以及对用户所处环境的特征分析&＃xff0c;特定群体的习惯分析。

• Coding&＃xff1a;是指产品的生产环节&＃xff0c;需要考虑到技术门槛&＃xff0c;规避技术风险&＃xff0c;弱化或简化需求以减少开发成本的耗损&＃xff0c;同时需要兼顾团队成员的合作方式&＃xff0c;尽力确保团队战斗力高效发挥。

本质上&＃xff0c;均是以不同的形式&＃xff0c;对不同的信息进行不同的处理&＃xff0c;均是处理信息的能力。

———— / END / ————

12月16日深圳站报名中

扫上方二维码咨询详情&参与700元组团优惠

点击“阅读原文”直接抢占前排座位