产品的“故事分析法”

3 评论 7595 浏览 19 收藏 14 分钟

编辑导语:对于产品经理而言,良好的表达是很重要的能力体现,在介绍产品时,要能清晰地表达自己的设计理念和产品特性,从而将产品推广出去。那么我们如何提升这一能力呢?本文提出了“故事分析法”这一概念,具体实操如何?跟随本文一起了解学习吧。

表达对于产品经理来说很重要,但是这个表达绝对不是像辩论选手一样秒杀一切对手,而是能够清晰的表达自己的理念和产品设计。

我们在做产品设计的时候往往也需要设定一个核心的定位,成为一个生活方式,记录美好生活……所以说我们需要刻意的训练自己去尝试设定产品的顶层设计,然后将这个理念表达出去,在这个理念之下很多问题都会有了决策的依据。

一、学会讲故事

在表达产品设计方案的方法中,讲故事是一个很有效的方法;训练自己可以用100个字表达任何一个你做的项目、设计的系统、设计的功能;同样这种表达可以是在你设计结束以后对外的宣讲,同时也是在设计之前的思路复盘整理,而这个故事不是基于功能而是基于场景和角色的陈述,例如:

我们都知道账户中心作为对资产的记录,往往会因为一些交易场景造成账户的透支,形成了用户对平台的欠款;那么欠款就有坏账的风险;为了资金安全考虑,我们就需要发现欠款并且能够追回来,而基于实际情况这种偿还的途径可以有多种。

二、故事里的秘密

上面的一段描述其实就是一个故事,这个故事很平淡,也描述的很清楚,任何一个场合,无论是面对研发、测试、老板还是打扫卫生的大妈,我想大家都知道你要因为什么而做什么,这样的一段话你可能不知道,它足以引领你完成整个项目的设计。

所以,我称这段描述就是“产品的故事”,我们很容易表达出自己的产品故事,就像我们可以很轻松的表达出我们饿了想吃饭。

为什么说这个故事里有很多秘密呢,我们把关键词标注出来,你发现了什么。

我们都知道账户中心作为对资产的记录,往往会因为一些交易场景造成账户的透支,形成了用户对平台的欠款;那么欠款就有坏账风险;为了资金安全考虑,我们就需要发现欠款并且能够追回来,而基于实际情况这种偿还的途径可以有多种。

故事里的关键词就像引擎的入口一样,可以帮助我们不断的打开思维的大门,慢慢的一座系统的缜密的架构就出来了,不信我们试试。

1. 资产

什么是资产,不同的情况或者不同的公司的用户会有不同的定义,结算款是资产,保证金是资产,在途结算款也是资产,也许信用也可以成为资产;所以说,我们要问自己如何“定义资产”,这就是我们下一步围绕资产的分析工作,资产就有他的形式、他的度量、他的优劣等级;假如我们得出来的用户的资产有这样几种形式。

结算款、保证金、在途待结算。

那么这些资产怎么表达呢,账户里的好说,就是余额,那么在途结算款怎么获得呢?这不新的分析任务又来了……所以围绕资产的分析在逐步展开,而且相互自洽和补充。

2. 一些交易场景

账户资产其实都是基于交易产生的,那么有些交易场景就会有不同的资产方向变化,比如什么交易场景会增加资产,什么交易场景会流失资产,这里也只有流失资产的交易场景才会造成资产的透支;那么有哪些交易场景会造成账户透支呢?这又是一个分析任务,同样不同的交易场景造成的透支是不是可以通过制度解决掉呢?这里我们又发现了一个解决问题的可能性。

3. 透支

透支是一个现象,不一定所有的账户中心都允许透支,那么就算不允许透支,一些交易场景发生以后也会出现欠款,只不过这种欠款更隐蔽,比如订单退款因为余额不足而无法退款成功,那么这个待退款订单其实就是欠款的另一种表达;那么让账户透支的好处是什么呢,其实就是让欠款显现出来,而且更容易进行核算,比如后续的收入可以直接抵扣欠款;不然的话后续收入无法与待退订单进行抵消;所以说我们对透支有了更深的分析,当然这个分析可以继续下去。

4. 欠款

欠款是资产风险的暴露,是一个结果;那么也是我们这次要解决的主人公,欠款一旦发生,就意味着未来可能有损失;这里像定义资产一样,我们怎么定义欠款,以什么样的形式呈现出来;假如我们以账户余额为负作为欠款的表达。

5. 风险

前面说了欠款是主人公,那么风险就是我们要消灭的对象,也是我们做产品的目的,这个风险有多大,有没有达到要马上解决的地步,如果堵住了,意味着多大的价值;对风险的定义和量化,就成了我们定义产品价值的关键;假如当下总欠款体量1000万,那么这个体量明显是需要堵住的,所以说这个产品的意义就是为了堵住1000万的风险资金缺口。

6. 资金安全

堵住风险和确保资金安全是一个正面一个反面的表达,这也是作为一名资金产品经理最核心的职责,确保资金的安全。

7. 发现欠款

现在欠多少钱呢,谁欠钱呢,所以说我们需要一个机制可以将风险报出来,提供给负责的人员进行评估。

8. 追回来

啥是追回来,其实就是要钱,怎么要,什么时候要,所以说我们需要建立完善的追缴制度。

9. 途径

既然要追钱,是不是就需要追缴的方法,用户想还钱,是不是就需要还钱的途径;另外用什么还,用保证金?直接支付欠款?每个还款方式怎么样?这里慢慢我们就开始看到了解决方案的影子……而且随着发展,这个途径会越来越多,那么这个地方也会成为一个拓展性的口子,我成为“拓展基因”。

以故事为起点,一篇产品大戏慢慢拉开。

三、学会抽象业务流程

我们做产品设计不要一上来就开始画页面,做脑图,想讲故事,然后确定主业务流程,也就是场景模拟。

上面的故事里,虽然我们发现了几个分析入口,其实整个故事中蕴藏一个主线,这个主线就是业务流程;而业务流程的梳理将决定了设计的好坏。

其实流程很容易,我们在表达一件事情或者思考一件事情的时候,可以从最确定的最宏观的视角入手,然后不断的去修正和补充,直到这个链条足够顺畅。

就像交易的主业务流程一样:用户下单,发货收货,完成,这个就很容易理解,这个理解还不会出错,那么我可以继续细化她

选商品,下单,支付,发货,确认收货,算账,给商家结算……。

同样上面的故事里我们可以抽象出这样一个流程。

通过这个项目学会产品的“故事分析法”

流程看什么,流程拆开看环节;对每一个环节进行分析;先确保环节没有遗漏,然后丰富每一个环节。

就像把大象放冰箱需要几步,把冰箱门打开,把大象放进去,把冰箱门关上;这个时候你肯定需要思考,怎么打开冰箱门,用手拉门把手么,还是有一个远程按钮……思考永远是从一个最简单的切入点逐步深入;在没有确定这三步之前就不要直接思考怎么打开冰箱门,为什么,因为你不知道为什么要打开,无法知道打开与前后的联动性和关联性,而这种全局思考会影响对单个环节的定义和判断。

从上面的流程里我们发现其实资产的定义、欠款的发现都是静态结果的显示;而追缴这个环节貌似非常丰富,首先我们会有疑问:怎么追缴,谁来追缴,用户用什么偿还,怎么偿还?……

四、业务流程的拆解

这就需要我们具备流程拆解能力,在一个大的流程里,我们会发现存在小的流程,或者更复杂的网状的流程;从环节里拆解出更精细的流程,比如刚才我们上面说的“追缴环节”,其中就有几个我们需要进行抽象的,比如:

怎么追缴:追缴方式的抽象,比如线上追缴、线下追缴。

谁来追缴:追缴职责的界定,比如运营人员。

用户用什么偿还:给用户的可抵扣资产的抽象,比如用保证金,用银行卡。

怎么偿还:这个其实就是追缴环节的子流程,也就是每一个追缴方式的子流程。

通过这个项目学会产品的“故事分析法”

而且从流程图中我们发现,在追缴方式上具备拓展性,随着发展,追缴方式会越来越多,而触达追缴方式的入口就是在选择要追缴某笔欠款的时候。

五、业务子流程的设计

在上面的已经拆解过的流程里,我们发现了三个子流程,那就是“不同追缴方式”的流程;而且要针对不同的追缴方式单独设计流程。

通过这个项目学会产品的“故事分析法”

六、其他环节的整理

同样在资产的定义环节也会有任务要做,就是有几种资产,怎么定义资产,每种资产怎么计算获得;那么计算每种资产将成为资产环节的子流程,而资产的分类将成为未来的拓展主线。

七、产品功能分析

到了这一步我们再去思考我们需要什么样的功能其实就容易多了,比如资产定义环节那么就做一个“总资产管理”,发现欠款环节就做一个“欠款管理”,每条欠款资产后面我们就加一个“追缴”入口,然后呢就是确定“追缴方式”,进入每一个追缴方式的流程里……

本文的核心目的就是要养成讲故事的能力,然后从故事里发现秘密,发现流程,并对流程进行有条不紊的拆解,从而一步步的完成产品的定义、分析、抽象和设计工作。

这样做的好处就是我们从故事出发,不以实现功能为目的,而是以实现故事描述的未来为方向,一层层的剥开故事的情节,达到目标。

#专栏作家#

陈天宇宙,微信公众号:陈天宇宙,人人都是产品经理专栏作家。多平台支付领域专栏作者,十年资深产品;天使投资人;专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务!

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 学习了,感谢分享

    来自广东 回复
  2. hi

    回复
  3. APP产品都有自己独特的SLOGAN,更加鲜活,有生命力

    来自山东 回复