你还在犯草根产品经理在犯的错吗?

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

caogenchanpin

随着互联网的发展,产品经理的需求越发旺盛。而互联网产品经理没有对应大学专业。有幸进入大型互联网公司工作和学习的产品经理毕竟少数。多数产品经理都在经历着从草根到专业的转变过程。细数这几年,自己眼见新人曾经犯过的错误,值得深思与总结。

一、关于职能定位

许多产品经理刚入门的时候都是从简单的原型制造开始,更准确地说应该是临摹其他产品的相关页面。在这个过程中从界面上逐渐去辨别某一个产品功能的好与坏,美与丑。慢慢地就认为这些就是产品经理这份工作的everything了。他们的目光永远聚焦在产品的外衣,而对于产品内在的价值和意义思考不深,甚至完全忽略。这样的产品经理通常只能算一个不专业的交互设计师。

出现这种现象的原因主要是许多公司缺乏对产品经理的认知、判断、培养的能力。在不同公司,对产品团队的工作要求、重视程度差异较大。更直白点说,许多公司缺乏产品经理基因,压根就不知道招聘什么样的产品经理,不知道他们应该做什么事情。

回到主题,产品经理对自己的职能定位一定要深刻。高度要能俯视整体产品线,广度要能涉猎更多知识面,深度要能直入业务最本质。忽然想起林夕的歌词“在高处凝望世界流动”,Yes,这就是产品经理应有的视角!

二、关于需求管理

1、没有建立完整、客观的需求获取通道。需求往往来自运营部门、市场部门或老板的要求,产品经理沦为需求文档撰写者,把别人的想法写成文档,交付给技术团队。这样的产品经理则沦为传统软件开发的需求分析师。要建立完整、客观的需求获取通道产品经理必须“眼观六路,耳听八方”:定期收集外部用户对产品的评价和反馈;定期对竞争对手的产品动向进行分析和跟踪;定期从后台提取用户行为数据,分析用户行为,通过数据提供产品迭代的理论依据;

2、没有建立合理的需求考评机制。需求漫天飞,永远不知道哪些需求要做,哪些不做,哪些先做,哪些后做。产品经理要为产品建立需求池,打造需求管理体系。从需求获取、需求排序、需求分析、需求评审到需求设计、需求开发和需求变更都要有依据和操作规范。以此来确保整个产品研发方向的合理性,摸索出一个适合市场要求和团队研发实力的迭代节奏。比如迭代周期以及每次迭代研发团队能承受的工作量。

三、关于流程管理

流程管理是最容易刨出坑的地方。关于流程方面的问题通常有两种表现形式。一种是日常化工作没有形成明确的流程,造成团队工作混乱。比如关于需求变更流程,如果没有明确的流程,产品经理在发起需求变更的时候很容易出现信息传递不对等。团队应该事先规定清楚,影响程度不同的变更必须上报到哪一个层级。以此来控制需求变更的合理性。需求变更应该通知的范围,除了技术、测试还应该通知运营团队甚至老板。以什么样的形式表达需求变更?邮件形式还是需求文档?这些问题没有相关流程会造成很多团队间扯皮、推诿的现象。

另一种情况则是团队通过讨论通过艰难地制定出某一个流程,可是在执行阶段出现问题。团队缺乏执行力,缺乏对流程的培训机制,缺乏对流程的改进和迭代。一个流程正如一个产品,要深入人心需要不断试错,升级。因此对于研发团队中最核心最常见的流程,必须靠强大的执行力来支撑,最终在团队里形成一种良性的工作习惯。

四、关于市场调查

在需要听取到团队之外的声音之时,产品经理通常会想到通过市场调查的方式收集信息。如果产品经理本身对市场调查方面的工作不够精通,通常会犯这几类错:

1、调查目的不明确。每一次市场调研需要当做一个独立项目去完成,在项目立项之前,就已经有一个明确的方向和目的。比如针对产品的某个指标发起的一次调研。那么首先需要把这个指标细分成多个相对可量化的指标。在后续调查问卷的设计中,或者用户访谈问题的设计中都有明确的方向和逻辑。比如,要调查用户对某个产品用户体验的满意度。可以细分成界面美观程度、主要流程易用性、主要流程加载速度、还有一些软性能的满意度等等。

2、样本采集不科学。采样的准确性直接关系最终结果的准确度。在调研中有些问题则必须通过与用户面谈,有些问题则打死不能当面与用户沟通,必须通过在线问答的形式。比如满意度,当面去询问对产品的满意度,用户碍于面子给予的反馈通常会比实际想法不符。因此采用的时候要综合考虑采用的渠道、样本的数量才能得到相对客观的基础数据。

3、问卷设计不合理。俗话说上梁不正下梁歪,如果调研的目的和调研逻辑没梳理清楚,到了问卷设计步骤一定会凌乱。而问卷设计部合理最常见的有如下情况:问题与中心无关、问题描述太笼统、选项不完备、选项不互斥、问题带有强烈的诱导下等等。

五、关于跨团队沟通

产品经理在整个大团队中无疑应该充当”万金油“的角色。需要平衡不同团队的特性,在技术面前要积极推动需求的实施,在运营团队面前则要坚持合理的节奏和原则。沟通能力差的产品经理通常会沦为运营对付技术的工具,或者是技术对抗运营的牺牲品。产品经理不要在团队里”搞政治“,却必须能游刃于团队间,靠的是过硬的专业技能和人格魅力。

1、在技术面前强调需求的价值,让程序猿深刻认识到自己开发的功能为何而生。同时建议在需求设计阶段就邀请他们参与,多听取技术的意见,与程序猿建立浓厚的感(ji)情(qing)。

2、在运营面前强调需求合理性,运营通常给出的需求是没有站在整个产品规划上来思考的,多数属于”哪痛帖哪“”指哪打哪“这样的场景。更不会去考虑需求可行性,天马行空的需求漫天飞也是正常的。这些无处不在考验着你的沟通能力!

或许我们都经历过从草根到专业的过程。本文列举的问题也未必适用于所有人或团队。仍然希望对广大新入门的产品汪有所帮助。

 

本文由人人都是产品经理专栏作家 @陈滨淋 原创发布于人人都是产品经理 。未经许可,禁止转载。

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

评论( 7

登录后参与评论
  1. ……没错 写的就是我,针针见血(啪啪打脸。。
    非常的受用,需要改变的地方太多了,感谢感谢,受益匪浅!

    回复
    1. 回复

      都是这么过来的,包括我自己!加油共勉!

  2. 写的不错,受益。期待大神的新文章。

    回复
  3. :grin: :grin:

    回复
  4. 楼主总结的不错 :razz: :razz: :razz:

    回复
  5. :!:

    回复
  6. 非常好的文章,受教,谢谢

    回复
加载中