怎样体现产品经理的专业?(分享下我对产品经理能力衡量的几个方法)

qinzhiqiang 12-21 9:37 561次浏览

产品经理是个很神奇的岗位,既好像入门门槛很低,不论什么专业,不需要什么技术,人人都可以做 。 又好像要求挺高,既是全才还是专才。

产品经理的专业度如何体现?

同样一个产品一个项目 ,好像不论遇到谁做产品经理,不论是小白还是大神,反正都可以上线。那小白和大神的区别怎么体现的呢?

跟大家分享下我对产品经理能力衡量的几个方法。

1、过程衡量

A、考虑是否周全

小白与大神最大的区别在于,同样做一个项目,是否能考虑足够全,足够深。是否能考虑到产品的可复用性、可扩展性、实现逻辑、数据流、信息架构、与其它产品线的交叉影响等等。(详情可以看我另一篇文章《产品经理的全局观需要考虑些什么》,在此不再赘述)

那是否考虑周全会如何体现呢?

(1)体现在PRD评审中

大神在写PRD之前一定会跟需求方和开发做充分的沟通,从需求细节到实现方案都已非常清晰明了。因此,PRD经过相关同学评审之后,很少会发现遗漏或方案欠妥当的说明点,PRD评审会比较顺利,评审结束后对PRD改动较小。

相反,小白在写PRD时,要么沟通不到位,要么考虑不到位,PRD中有较多的遗漏点或方案明显不合理的地方。评审的时候往往会被各个角色同学挑战,评审结束后再对PRD做大面积的修改。

(2)体现在开发过程中

大神级的产品经理,在PRD评审后,如果没有其它项目,即使休假也不会对项目进展造成多大影响。因为,从逻辑到细节,项目组同学都已经非常清晰,在开发过程中也很少会发现需求中哪里没有讲清楚,需要再check 的地方。

小白级的,在PRD评审后,还会非常忙碌。因为在开发过程中,随时可能被开发同学发现有需求不清晰或漏掉没讲的地方,随时需要跟产品临时讨论确定方案,属于一边讨论一边开发。如果产品经理不在,那项目几乎就瘫痪了。

(3)体现在测试用例中

测试同学做测试用例的过程,是对产品每一个细节、正常流程、异常流程考虑得最全面的过程。

大神级的产品经理写的PRD几乎可以涵盖测试用例中每一种用例情况的说明。

遇到小白级的产品经理,测试同学在做测试用例过程中会不停跟产品经理确认哪种情况该如何处理。因为这些情况小白根本没有考虑到,也不会写进PRD。

B、项目管理能力

大神级产品经理能准确把握项目进度,让项目按时上线。小白控制的项目经常被一而再再而三的延期。为什么呢?

原因一:

大神级的产品经理因为PRD比较完整,所以项目组同学根据完整PRD估计出的工作时长相对比较准确。

小白的PRD本身残缺不全,项目组评估出的时间跟实际需求产品的时间会有较大出入。

原因二:

大神随时跟进项目阶段进度,且具有良好的沟通和资源协调能力,当项目过程中出现资源抢占等问题的时候能够主动、及时协调资源,确保项目进度正常。

小白在完成PRD评审后,就感觉自己的事情做完了,坐等收货。然而在项目时限快到的时候才发现因为中途的某些问题,导致项目被延期了。此时已经无力回天,只能被延期。

2、结果衡量

总体来说,结果衡量是跟着业务目标走的。除了共同的业务目标以外,还可以单看产品设计上的目标。例如,一些用户行为数据,反应产品设计是否合理等。

3、态度衡量

小白产品经理,在完成PRD评审,并根据评审结果修改一次PRD后,就会“定稿”PRD,不再做修改。但是项目过程中,产品交互、视觉都会不断优化,开发测试过程中也可能会发生部分细节的需求增删改。这样就会导致上线的产品跟PRD不符的情况。

大神的PRD是不断完善、更新。上线后的产品与PRD是完全符合,PRD可沉淀为产品说明,供其他同学参考的。

大神写PRD一般会经历下面几个阶段:

  • step1、跟需求方充分沟通 就实现细节与技术充分沟通
  • step2、结合产品原型写PRD初稿
  • step3、修改评审后的PRD
  • step4、交互定稿后,根据交互稿更新PRD
  • step5、视觉定稿后,根据交互稿更新PRD
  • step6、上线后,根据上线效果图更新PRD,包括定稿的每个文案。

所以,即使最后的结果都是产品上线了,但是遇到的产品经理是小白还是大神,将直接决定项目的一生是坎坷的还是顺利的。

而最有感触的应当是跟产品经理合作的项目团队同学。所以我经常提倡,产品经理的KPI应该有合作团队的同学参与考评,不仅仅是直属leader来决定。