这“2.5”个B端产品方法论,我想分享给你

编辑导语:关于B端产品的相关知识,大家已经了解了不少,然而关于B端产品方法论,不同的人会有不同的见解。本文作者通过回顾自己4年的平台产品工作经验,总结了“2.5”个B端产品方法论,希望对你有所启发。

这“2.5”个B端产品方法论,我想分享给你

距离上次发表文章已经过去30+个月了,在当下这家公司负责了15+个项目(还没算上一些不成项目的流程优化),高效的工作效率/沟通效率让我能够同时负责多个项目且脑子不堵车。

接近4年的平台产品工作经验,又临近工作更换的节点,将这段时间的一些个人思考和收获梳理成型,和大家分享。

前言: 由于行业/公司/部门的情况不同,造成了不同产品岗位所需要的能力不同。但抽象一下,所有(产品)岗位提供的都是解决问题的能力。当然问题是五花八门的,但解决问题总有相同的方法/思路。

笼统来说,解决问题总共有三个步骤,且分先后:

  1. 分析问题关键
  2. 提供解决方案
  3. 效果验证
  4. 循环迭代(分析/解决/验证 新的问题)

这“2.5”个B端产品方法论,我想分享给你

一、分析问题

在分析问题上,有个很著名的梗<怎么把大象放进冰箱?>。答案大家都知道<打开冰箱门,把大象放进去,关上冰箱门>,不妨就以这个问题来展开讨论。

1. 细化流程

分析问题的首要步骤,毫无疑问是要先细化问题。一个天马行空的问题,不代表问题本身100%是天马行空的,一部坏的电视机可能只是某个零件出了问题,放大象进冰箱我们也可以帮忙开关门。

可惜的是,大部分人的第一反应是对问题本身全盘否认。而一旦否认问题后,问题解决者的价值也就一同被否认了(或者变成了否认提出问题的人的观点),毕竟没人愿意为一个解决不了的问题去投入成本。

回到放大象进冰箱的梗,细化流程之后,问题就清晰很多了。

  1. 打开冰箱门——可行(成本低)
  2. 把大象放进去——存在难度(成本高)
  3. 关上冰箱门——可行(成本低)

再对第二步拆分,从某地把大象运到冰箱前,引导它进去。流程拆分得越细,要解决的问题就越清晰,相应的,解决问题的方法也就越清晰。

2. 到底要多细

我的答案是,细到能解决的地步,或者尽你所知道的程度就足够了。这分两步细到能解决,问题解决了,继续细没意义,除非再细下去能有替换方案降低成本。

尽自己所能的细,是自我安慰的选择。信息/知识 容纳量的大小,在一定程度上等于一个人的智商/能力/价值的水平,不要在超出自己能力范围的东西上对自己要求过高,否则只会给自己带来挫败感。

而尽自己所能的细,要做到这一步也不容易。这要求我们对自己所了解的东西融会贯通,做到举一反三。在工作场景中,这要求我们能够结合项目过往的内容/正在执行的方案/将来可能的规划,给出一个成本最低的答案。

再结合例子来看:

  1. 从某地获得大象使用权(当然偷一个也行,不过违法的成本可能是无限大的)
  2. 运到冰箱前
  3. 引导它进去

如果公司有钱买下一头大象,那么使用权问题就解决了。如果公司刚好是海运行业,那么运输问题就解决了。如果公司里面有员工当过动物园饲养员而你又知道,那么引导的问题就解决了。

但公司能用的资源往往不是充足的,如果能创造出未有的方法(将成本无限大的问题转为成本有限的问题),或者选择更低成本的方法去解决,中间的gap就是问题解决者的价值所在了。

这个方法在现实情况中也是多种多样的,可能是员工的人脉关系,过往工作的知识储备等等。

3. 为什么要做?

在ab两点上,都是对问题提供解决方案的思考。

而在实际工作中,特别是产品经理,经常遇到上下游提出的各种需求。这要求产品经理在问题的出发点上进行更多的思考,做不做,为什么要做,做了后收益是否足够可观,而不是直接埋头去想怎么做。

如果仅是为了展示部门能力而把大象放入冰箱,那么将部门的资源拿去买大象(内部消耗)是否值得?但如果是为了向股东/客户展示能力而获得更多合作机会,那么听上去就是一个不错的方案了(不过我在工作上,很多时候都是先思考细化流程,分析发现成本过大,反推目的,梳理责任边界,然后拒需求的hhh)。

在分析问题的方法上,分享一些我实际遇到的例子,解决方案足够旁大的都已经成为我简历上的项目了(我的经历在文末):

  1. 如何减少一线人员的划水情况?
  2. 如何对比内外部模型水平差异?
  3. 如何降低线上工作和质检工作环境的差异?
  4. 如何设计一个评分弹窗?

实际上问题3在实际工作中没有暴露出这么明显,当时情况是质检准确率总是比较低,经过一番调研后才发现这个问题,这也比较符合大部分产品经理实际工作遇到的情况。

而问题4是我在面试中遇到的一个问题,它掠过了问题分析的步骤,要求直接提供问题的解决方案。但是评分弹窗何时出现,用户评分结果要用在哪里,都没有给出,设计起来就比较困难了,面试结果也不如人意。

那么如何设计一个评分弹窗呢?

二、提供解决方案

后台产品的设计往往是为了支撑上游业务,提供信息化的传输/协调能力,从而加快整体流程,达到节省成本的作用,规范/加快/简化业务流程是解决方案重要且基本的要求。

在此之上,节省开发成本的多少,是区分产品优劣的另一个因素。如何降低开发成本呢?有三种可能,且一般情况下优劣同先后顺序:

1. 当下开发成本为0

这意味着,用现有的流程去满足新的业务需求。

已有流程可能不完美,但如果能快速实现,且满足业务方的关键要求,对比之下便是最好的选择。还有一点是,紧急的流程可能是低频且不重要的流程,毕竟如果足够重要,往往早已实现,或在部门的大规划上。

入门的产品经理在面对业务需求时,对现有功能/历史情况不了解,即使明明有菜刀了,还要另外造一把匕首。

2. 有多个方案的情况下,选择开发成本最小的一种

运大象到冰箱前,还是运冰箱到大象前更简单?新规划一条航线去运大象,还是将原定航线上的船空出来一个位置比较节省成本?这个选择很简单,但可能会和3冲突。

3. 流程可兼容日后流程/规划,节省以后的成本

如果逼不得已要新建一个流程,最好将其做到足够通用(减少个性化)。而通用的要求是,先将多个流程的维度抽象出来,变成一个个个性化的值。这么说有点模糊,放出我一般梳理需求时都会用到的excel表:

这“2.5”个B端产品方法论,我想分享给你

(表1)

这“2.5”个B端产品方法论,我想分享给你

(表2)

表1是对表单设计时的信息梳理。后台的每个任务(电商入库,每个货物/包裹都是一张入库流水单;oa系统,每个用户/id都是一条记录。

如果信息过多,则通过uid将储存在不同库表的信息关联起来)都对应一条数据记录,而每条数据记录都有自己的信息,通过将实际的线下流程节点和记录的状态数据变更触发点关联起来,一个个流程便可以实现。

可以看到,我:

  • 首先将每个任务需要记录的信息维度列出,比如任务名称/任务时间/…这要求我们对所有场景的流程需要用到的相同信息抽象出来;
  • 再将信息维度归类,归为任务信息/业务范围/投放时机/…信息归类可以帮助产品自己对每个信息的用处有更深的了解,对开发同学设计库表,理解业务时也有帮助;
  • 根据每个场景,制定每个维度里面都有什么值。

表2与表1的区别在于,表1是对一个个任务(如实物)的信息进行抽象,表2是对一个个流程(虚物)的将信息进行抽象。只要练习多了,就可以将不同对象都按照不同维度抽象起来。

实际上按照不同维度来抽象描述,这和技术同学的[面向对象编程]有相似之处,而日常在介绍各类内容时,我们也是按照一定逻辑/维度顺序的,比如时间顺序、空间顺序…

这个方法可是我的压箱法宝了,它帮助我在一天内就把这个容纳了双审/质检/培训的系统方案给梳理完善出来。当然,我所负责的业务的流程复杂程度相对而言是比较低的,有些行业的线下业务流程可要复杂得多,但抽象总是有用的。

以电商流程为例,如果抽象的流程为[入库],那么购置的货物入库/退货入库/调仓入库/…是不是都可以使用同一套流程呢?只是货物来源不同,那么货物来源又可以定义为一个维度了。

三、效果验证

这part主要描述的内容是 [制定关键指标](结果),以及不只看[关键指标](关注过程)。就当0.5个,下次有机会再分享吧~

本文由 @Ien 原创发布于。未经许可,禁止转载。

题图来自unsplash,基于CC0协议

(0)
小多多的头像小多多创始人

相关推荐

发表回复

登录后才能评论