策略产品经理工作锦囊

2018-04-05 发布
3262 字 • 9 分钟

~ 持续汇总对策略产品经理工作技能的思考:

核心能力

核心能力得从角色职能出发——策略产品经理也是产品经理,而产品经理的职能是带领团队高效给用户提供解决方案。

这就需要挖掘用户真实需求、设计解决方案,实现解决方案,对应的即是发现问题、挖掘需求、决策、沟通能力。

做决策、评估优先级

决策质量也很区分产品经理功力。上如现在最需要解决的问题是什么、项目目标到底是什么、什么时候需要完成,下到这个支付时限到底要不要调整,如何调整。

大的决策下面提了些,先主要说说小决策,支付时限的例子。调研结果出来了,什么样时限的都有,且各家差异不小,我们到底要不要改?要做这个决策,需要考虑的问题不少:

  • 我们改支付时限想解决的问题、达到的目标是什么?要达到目标有无更高效的方案?
  • 现有支付时限实行多年,在几千万用户中已形成认知,他们对此变化的敏感程度如何?调整后的负面影响比正面影响大的概率有多大?
  • 用简单却更易达到目标的方案,好像没怎么体现我作为策略产品经理的价值,此时要不要来个复杂点的方案?(时刻反思 ROI ,不要炫技)
  • ……

以及,这不仅需要决策能力,还需要敢于承担的勇气和善后智慧。

定义问题

这是决定产品成败的关键,更是策略产品经理的核心竞争力。能把问题定到痛点,就易事半功倍。

比如梳理地图产品的推荐策略,如果把「待解决的问题」只定义为给用户推荐从起点到终点的最优路线,那肯定大半用户都走了,毕竟每个用户每次使用都是独特场景,算法再强大,也不可能每次都正中用户下怀。要「智能+人工」,用户才易找到满意方案。所以「待解决的问题」,私以为定义为 给用户推荐从起点到终点的路线,并令用户可根据不同维度便捷查询、排序,选出心仪路线 更妥当。

设定项目目标

面对同样的现象,不同产品经理会设定出不同的项目目标。比如同样面对「 3% 的用户会在订单取消后,30mins ~ 120mins 内二次生成生成订单,二次购买」这个现象,有人定的项目目标是提升自动取消后的二次成单率;有人定的是降低自动取消后的二次成单率,提升一次成单率;有人定的是提升总成单率。

不同目标反映了不同的格局、对业务的理解,对业务全局把握越准确的人,更能定出直达本质的目标,提升团队 ROI。

沟通

驱动大伙儿一块儿共建,注意「context not control」, 详见《Netflix Culture: Freedom & Responsibility》 https://www.slideshare.net/reed2001/culture-1798664

微观体感

洞察细微差异,发现问题挖掘需求,做出正确决策,这一系列行为都需要敏感品位,暂且概括为微观体感。

工作习惯

遇到新问题不慌,借助《How to Solve it》框架理思路

工作中常会遇到新问题,这很正常,不必慌乱。

如何应对,How to Solve It - Wikipedia 早已道尽奥秘:明确目标,弄清已知、未知数据以及他们的关系,明确边界条件,制定计划,执行计划,效果回归:

chart-how-to-solve-it_polya.jpg

关注用户故事

抽象的需求描述,远不如具体场景故事,更易令人体察那些打动人心的细节和更深层的诉求,让产品更有魅力。

比如自己之前在公司推行 GitHub 周报提交机制,大伙觉得交流不便,希望能有更多交流。我刚收到同事反馈时,不能理解为什么大伙儿那么希望交流,为什么有那么多要交流的,以及为什么现行机制满足不了。后来在午餐会这种非正式交流场合,让大伙儿举几个希望交流的例子,一下就能理解大伙儿的诉求了:

  • 比如 A 在周报里说自己最近弄什么事情有点难,B 说最近公众号同事总加班到很晚,好在数据终于有点起色,C 看到后,很希望能方便地给他们一些回复,有时候哪怕只是简单的一句么么哒感谢、祝贺,或是说这种感觉我能理解,抱抱,辛苦了,都能让对方感觉有人关心,让同伴觉得这个团队,不只在意你飞得高不高,也有人关心你飞得累不累;同事不只理性,也有温度,有温情。
  • 又如 D 在周报里说自己预计遇到个什么困难,A 看到后正好有建议,可以顺手周报里回复给对方。
  • 还如,E 看到 F 周报里写的思考,更能理解团队为什么要做某个决策,自己不再只是单纯的执行,而是知道为什么要做这个事情。也更清楚之前哪些地方自己做得不足,接下来可以做哪些调整。
  • 而这些细小的信息交换,如果直接在微信上发给对方,或把对方拉出来当面说,都太刻意,也没那功夫。且很多细微的情绪起伏转瞬即逝,过了可能就忘记了。

优秀的产品经理,多会在产品设计伊始,就不停打磨产品的用户故事。

if 未来设计或迭代产品, then 多请用户举几个有这类需求/困扰的具体场景。

关注别人、别的产品做对了什么、如何借鉴,而非挑错

「少年得到」刚出来时,有位妈妈就个人体验抓住少年得到的某一错误写了篇文章批评其内容不够科学专业(见少年得到:为孩子提供知识服务,还是向家长贩卖焦虑)。其作为用户如此表达不满和失望没问题,但咱们作为产品经理、创业团队,可不能这样,更应关注他们做对了什么、如何借鉴。就这个例子来说,咱们更应关注和借鉴:

  1. 同类错误在少年得到占比多大,在同行中是高是低,如何做到的?
  2. 其处理速度如何,相较咱们团队是快是慢,我们如何更快?对于这类情况咱们可以做哪些优化——如何预防?如何响应?
  3. 得到为什么推出少年得到,如此布局是想抓住什么红利或应对什么窘境?背后的考量对咱们有什么启发?

区分原始数据和演绎数据

做产品免不了分析数据,标注时一定注意区分原始数据和演绎数据,别给自己和团队找事儿。

如何区分?

  1. 原始数据要有留档:创建副本后再清洗、加工,以防万一
  2. 标注时不加个人演绎。以分析天气 query 识别情况为例:
    • 何为个人演绎?直接标注某 query 为有天气查询的强需求、中需求、弱需求,并设定了对应的处理规则。但强中弱需求区分是个人主观判断,其它同事若有另一套强弱标准,这些标注就得遍历校正。
    • 何为不加个人演绎?
      • 直接标注事实属性,比如某 query 属「地名+体感词汇」或「地名+衣着词汇」、「地名+饮食词汇」,再梳理各类 query 对应的处理规则。
      • 如此,即使其他同事对对应的处理规则有疑议,调整规则就好,不必重新标注。

多用演绎法

归纳法只能基于已知信息做决策,但演绎法可基于模型推演出可能的情况,未雨绸缪。

仍以上述分析天气 query 识别情况为例,如果仅基于抽样的 200 个 query 来提优化方案,那 query 里没出现的情况就不会考虑到,下回还得优化。比如这 200 个 query 中就没出现「地点+吃类词汇」,比如 凤凰古城小吃推荐,但这的确可能有出行需求,可以提供天气信息。归纳法没法发现这个情况提前设定规则。

但如果用演绎法——用户在什么情况下可能有天气查询需求?他有出行需求时。那如何知道他有出行需求?当他输入的 query 有以下情况时:

  • 地点+天气词汇,比如南宁明天下雨吗
  • 地点+体感词汇,比如南宁现在冷吗
  • 地点+衣食住行词汇,比如
    • 去南宁要准备什么衣服
    • 南宁有什么好吃的
    • 南宁五星级酒店推荐
    • 南宁到成都骑行路线

用演绎法得出处理策略后,再从抽样 case 中验证策略是否可行,完善策略。

不搞开发,也要有工程素养

越发觉得,即使不搞开发,工程素养也很重要,直接影响工作方方面面。

比如常见场景工作交接:如何让新人快速上手,把工作干得和你一样漂亮?有工程素养和没有,交付效果天差地别。若有,交付的成果易用易拓展易维护;若无,叫人难免头疼这是让我们也吃不了兜着走啊。

从机器语言迁移到自然语言,也是相通的——写文档如创造产品,你得定义清楚使用场景、用户,才令别人更易使用;若人设混乱,你写得累心,人用得糟心。也似写程序,恰当拆分模块,才令程序更易拓展和维护:该拆分的尽量拆分,一个文档只解决一个问题;相同内容勿在协作系统出现多次,他处要用直接引用,力求实体唯一;形式选取长点心眼,以便未来复用拓展。

又如编辑文章时管理图片、插入图片,有工程素养没有,效率也会差出几十条街。一些细小的习惯差异,比如遵循「实体唯一原则」和不懂「实体唯一原则」,能造成五倍十倍,随着时间和协同人数的增长甚至百倍的效率差异……

高效做竞品分析

详见如何做竞品调研

别动不动给别人丢思维导图的图片

这个行为对双方界面都不友好:对方即使放大查看也挺费劲;自己若要更新,还得把新的图片更新出来,甚至得告知修改了什么。

解决方案:

CHANGELOG

  • 180603 闪闪增补区分原始数据和演绎数据,多用演绎法等工作习惯
  • 180517 闪闪增补核心能力和习惯
  • 180410 闪闪增补习惯
  • 180405 闪闪创建