编辑导语：对于产品经理而言，良好的表达是很重要的能力体现，在介绍产品时，要能清晰地表达自己的设计理念和产品特性，从而将产品推广出去。那么我们如何提升这一能力呢？本文提出了“故事分析法”这一概念，具体实操如何？跟随本文一起了解学习吧。
表达对于产品经理来说很重要，但是这个表达绝对不是像辩论选手一样秒杀一切对手，而是能够清晰的表达自己的理念和产品设计。
我们在做产品设计的时候往往也需要设定一个核心的定位，成为一个生活方式，记录美好生活……所以说我们需要刻意的训练自己去尝试设定产品的顶层设计，然后将这个理念表达出去，在这个理念之下很多问题都会有了决策的依据。
在表达产品设计方案的方法中，讲故事是一个很有效的方法；训练自己可以用100个字表达任何一个你做的项目、设计的系统、设计的功能；同样这种表达可以是在你设计结束以后对外的宣讲，同时也是在设计之前的思路复盘整理，而这个故事不是基于功能而是基于场景和角色的陈述，例如：
我们都知道账户中心作为对资产的记录，往往会因为一些交易场景造成账户的透支，形成了用户对平台的欠款；那么欠款就有坏账的风险；为了资金安全考虑，我们就需要发现欠款并且能够追回来，而基于实际情况这种偿还的途径可以有多种。
上面的一段描述其实就是一个故事，这个故事很平淡，也描述的很清楚，任何一个场合，无论是面对研发、测试、老板还是打扫卫生的大妈，我想大家都知道你要因为什么而做什么，这样的一段话你可能不知道，它足以引领你完成整个项目的设计。
所以，我称这段描述就是“产品的故事”，我们很容易表达出自己的产品故事，就像我们可以很轻松的表达出我们饿了想吃饭。
为什么说这个故事里有很多秘密呢，我们把关键词标注出来，你发现了什么。
我们都知道账户中心作为对资产的记录，往往会因为一些交易场景造成账户的透支，形成了用户对平台的欠款；那么欠款就有坏账的风险；为了资金安全考虑，我们就需要发现欠款并且能够追回来，而基于实际情况这种偿还的途径可以有多种。
故事里的关键词就像引擎的入口一样，可以帮助我们不断的打开思维的大门，慢慢的一座系统的缜密的架构就出来了，不信我们试试。
什么是资产，不同的情况或者不同的公司的用户会有不同的定义，结算款是资产，保证金是资产，在途结算款也是资产，也许信用也可以成为资产；所以说，我们要问自己如何“定义资产”，这就是我们下一步围绕资产的分析工作，资产就有他的形式、他的度量、他的优劣等级；假如我们得出来的用户的资产有这样几种形式。
结算款、保证金、在途待结算。
那么这些资产怎么表达呢，账户里的好说，就是余额，那么在途结算款怎么获得呢？这不新的分析任务又来了……所以围绕资产的分析在逐步展开，而且相互自洽和补充。
账户资产其实都是基于交易产生的，那么有些交易场景就会有不同的资产方向变化，比如什么交易场景会增加资产，什么交易场景会流失资产，这里也只有流失资产的交易场景才会造成资产的透支；那么有哪些交易场景会造成账户透支呢？这又是一个分析任务，同样不同的交易场景造成的透支是不是可以通过制度解决掉呢？这里我们又发现了一个解决问题的可能性。
透支是一个现象，不一定所有的账户中心都允许透支，那么就算不允许透支，一些交易场景发生以后也会出现欠款，只不过这种欠款更隐蔽，比如订单退款因为余额不足而无法退款成功，那么这个待退款订单其实就是欠款的另一种表达；那么让账户透支的好处是什么呢，其实就是让欠款显现出来，而且更容易进行核算，比如后续的收入可以直接抵扣欠款；不然的话后续收入无法与待退订单进行抵消；所以说我们对透支有了更深的分析，当然这个分析可以继续下去。
欠款是资产风险的暴露，是一个结果；那么也是我们这次要解决的主人公，欠款一旦发生，就意味着未来可能有损失；这里像定义资产一样，我们怎么定义欠款，以什么样的形式呈现出来；假如我们以账户余额为负作为欠款的表达。
前面说了欠款是主人公，那么风险就是我们要消灭的对象，也是我们做产品的目的，这个风险有多大，有没有达到要马上解决的地步，如果堵住了，意味着多大的价值；对风险的定义和量化，就成了我们定义产品价值的关键；假如当下总欠款体量1000万，那么这个体量明显是需要堵住的，所以说这个产品的意义就是为了堵住1000万的风险资金缺口。
堵住风险和确保资金安全是一个正面一个反面的表达，这也是作为一名资金产品经理最核心的职责，确保资金的安全。
现在欠多少钱呢，谁欠钱呢，所以说我们需要一个机制可以将风险报出来，提供给负责的人员进行评估。
啥是追回来，其实就是要钱，怎么要，什么时候要，所以说我们需要建立完善的追缴制度。
既然要追钱，是不是就需要追缴的方法，用户想还钱，是不是就需要还钱的途径；另外用什么还，用保证金？直接支付欠款？每个还款方式怎么样？这里慢慢我们就开始看到了解决方案的影子……而且随着发展，这个途径会越来越多，那么这个地方也会成为一个拓展性的口子，我成为“拓展基因”。
以故事为起点，一篇产品大戏慢慢拉开。
我们做产品设计不要一上来就开始画页面，做脑图，想讲故事，然后确定主业务流程，也就是场景模拟。
上面的故事里，虽然我们发现了几个分析入口，其实整个故事中蕴藏一个主线，这个主线就是业务流程；而业务流程的梳理将决定了设计的好坏。
其实流程很容易，我们在表达一件事情或者思考一件事情的时候，可以从最确定的最宏观的视角入手，然后不断的去修正和补充，直到这个链条足够顺畅。
就像交易的主业务流程一样：用户下单，发货收货，完成，这个就很容易理解，这个理解还不会出错，那么我可以继续细化她
选商品，下单，支付，发货，确认收货，算账，给商家结算……。
同样上面的故事里我们可以抽象出这样一个流程。
流程看什么，流程拆开看环节；对每一个环节进行分析；先确保环节没有遗漏，然后丰富每一个环节。
就像把大象放冰箱需要几步，把冰箱门打开，把大象放进去，把冰箱门关上；这个时候你肯定需要思考，怎么打开冰箱门，用手拉门把手么，还是有一个远程按钮……思考永远是从一个最简单的切入点逐步深入；在没有确定这三步之前就不要直接思考怎么打开冰箱门，为什么，因为你不知道为什么要打开，无法知道打开与前后的联动性和关联性，而这种全局思考会影响对单个环节的定义和判断。
从上面的流程里我们发现其实资产的定义、欠款的发现都是静态结果的显示；而追缴这个环节貌似非常丰富，首先我们会有疑问：怎么追缴，谁来追缴，用户用什么偿还，怎么偿还？……
这就需要我们具备流程拆解能力，在一个大的流程里，我们会发现存在小的流程，或者更复杂的网状的流程；从环节里拆解出更精细的流程，比如刚才我们上面说的“追缴环节”，其中就有几个我们需要进行抽象的，比如：
怎么追缴：追缴方式的抽象，比如线上追缴、线下追缴。
谁来追缴：追缴职责的界定，比如运营人员。
用户用什么偿还：给用户的可抵扣资产的抽象，比如用保证金，用银行卡。
怎么偿还：这个其实就是追缴环节的子流程，也就是每一个追缴方式的子流程。
而且从流程图中我们发现，在追缴方式上具备拓展性，随着发展，追缴方式会越来越多，而触达追缴方式的入口就是在选择要追缴某笔欠款的时候。
在上面的已经拆解过的流程里，我们发现了三个子流程，那就是“不同追缴方式”的流程；而且要针对不同的追缴方式单独设计流程。
同样在资产的定义环节也会有任务要做，就是有几种资产，怎么定义资产，每种资产怎么计算获得；那么计算每种资产将成为资产环节的子流程，而资产的分类将成为未来的拓展主线。
到了这一步我们再去思考我们需要什么样的功能其实就容易多了，比如资产定义环节那么就做一个“总资产管理”，发现欠款环节就做一个“欠款管理”，每条欠款资产后面我们就加一个“追缴”入口，然后呢就是确定“追缴方式”，进入每一个追缴方式的流程里……
本文的核心目的就是要养成讲故事的能力，然后从故事里发现秘密，发现流程，并对流程进行有条不紊的拆解，从而一步步的完成产品的定义、分析、抽象和设计工作。
这样做的好处就是我们从故事出发，不以实现功能为目的，而是以实现故事描述的未来为方向，一层层的剥开故事的情节，达到目标。
陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；天使投资人；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。