———— / BEGIN / ————
故事从国内小贷业务上升开始。
小贷公司有他的天然短板——可以放贷、不能吸储，资金不能构成闭环，因此普遍依赖外部资金方，不能不把得手的利润让出1部份。
在2017年，随着各路小贷公司扩大范围，资金本钱也1路上涨，利润紧缩很严重，所以大家陆续开始斟酌收购或自己做资金端产品。
我在的公司也是出于这样的斟酌，开了1条P2P产品线。
这个产品（姑且叫A理财）的第1目的，是优化公司的资金结构。
这是从企业角度动身的产品目的，而对用户来讲，我们下降了中间本钱、提高了用户收益，但对市场来讲这不足以做到差异化定位，还需要结合其它资源。
这是我第1次做理财产品。
调研分析进程花了比较长的时间，画了好大好大1个脑图来写自己的idea然后1个1个处理掉，1路从需求摸索到提测，踩了无数坑，终究上线。
现在尘埃落定，我来复盘1下这个进程。
（对产品内容没兴趣的，可以直接跳到“复盘总结”去了）
1、P2P的6大块
P2P产品简单来讲，可以分6个大块：
- 资产：包括资产接入、管理、风控、上标等
- 资金：包括平台资金、用户资金、财务清结算等
- 交易：包括标的/资金匹配、理财计划、收益分配、逾期处理等
- 账户：平台/用户多级账户体系
- 合规：信息表露、签章合同、现金流合规、资产合规等
- 推行：用户拉新与保存、品牌推行、红包与加息券、社群
其中，风控我把它放在资产里，是由于贷前风控行动本身属于资产端，对小贷公司来讲，P2P的风控与小贷风控差别有限，从业务模式到技术难度都不在1个量级。
下面1个1个地介绍。
1. 交易
之所以先写交易，是由于它最难。
P2P交易的链条比较长，交易从借款人开始，包括4个大的部份：
- 申请：申请借款–>平台审核–>上标召募
- 召募：出借人投标–>满标–>划拨资金给借款人–>开始计息
- 收益清算：逐日清算出借人昨日收益
- 还款：借款人还款–>借款本金及利息划款至出借人账户、服务费划款给平台收益账户，即完成1次正常还款；加上逾期、提早还款等背约情况，构成还款阶段的主要事件。
在投标阶段，由于资产类型不同：
- 对大额资产来讲，需要多个用户去投才能满标。
- 对小额资产来讲，用户1笔资金，可以满好几个标。
中间存在错配，需要1个撮合策略，保证用户投资后能尽快取得收益。
2. 账户
账户分平台账户、用户账户两类。平台账户是1个大型账户下的多个子账户，用来做收益清结算、非常规交易中的资金清算。
用户账户分两级，第1级是资产结算账户，第2级有很多个，是出借人各个出借资产的收益清算账户。每次交易相当于给用户建立1个新的2级账户，用来记录投资人收益。
同时为了账户安全，接入实名2要素验证，与银行卡4要素验证。
3. 资金
资金模块为交易、账户提供基础服务，包括接入支付通道、清结算服务、账目流水，和为财务和市场运行提供报表。
4. 资产
这1部份是小贷公司已有的业务，再增加资产是不是通过审核、标的流标致使资产退回的行动。
5. 合规
合规要求现金流与资产流匹配，要求信息表露，有效的合同签章，还有很多宣扬措辞问题。
这些在产品设计早期有所计划，在设计后期与法务合作1个1个地处理下去就好。
这期间公司法务缺席了1段时间，用户协议是我自己照猫画虎地起草来的，想起来真是好不容易。
还有存管，交给商务团队来处理。
6. 推行
推行是这个产品故事的高潮。
9月下旬产品终究上线，开始小范围公测，我们在早期发相对高息的计划（但对小贷业务来讲是较低的资金本钱），然后公司内部人手安装1个。
由于周期较短，发薪当天，公司发出薪水的40%又回到了账上。
为何只有40%？
由于我们的工资卡是招商卡，它在支付通道笔单日限额太低，而我们设定的起投资金太高了[摊手]。
这很容易解决，只是出乎意料以外。
这1产品很受同事们喜欢，由于它利息高于外界同类产品，而且大家自己清楚它的风险点在哪，所以都非常捧场。
但在对外推行的时候可以说是阻力重重。
首先是上架。
10月份利用市场风声日紧，合规要求我们在新的实体中运作这个产品，但新产品在没有金融资质的时候上不了架——看起来像个死局。
因而我们1边尝试IOS的企业开发者账号，1边走垂直社群，1边做约请红包和加息劵。
我自己下手做客服，教IOS用户不走App Store怎样安装（这后来在区块链领域变成了通用手段）。
垂直社群推行速度可以说非常慢，但用户虔诚度出乎意料。
由于迈过了“产品没有上架”“存管还在接”两个心理门坎以后，用户已非常偏向于我们了;所以全部社群氛围非常好，妹子们把闲钱放进来，还可以控制剁手。
但是，当时IOS收紧了审核标准，企业开发者账号超级难申请，iOS的推行几近是龟速，存管的推动1样艰巨。
用户对我们保证的“正在接存管”也渐渐不再期待。
风险敏感的用户开始撤离。
产品好像要死掉了。
我们尽力向用户解释我们的严谨和审慎（这1类设计会致使在产品中出现1些反用户直觉的情况），我们的为存管做的准备已全部上线，我们在小贷领域的盈利情况等等。
这样，总算留下大部份用户支持我们。
经历了这1波低潮，资金盘有缩减，而公司度过了资金窘境，不再关注这里，存管银行对新产品兴趣寥寥，即便新产品没有历史包袱。由于有太多做出了事迹的公司在排队。
孤立无援。
我们几近只能靠自我束缚取信客户——听起来很可笑对不对？
具体怎样做的呢？
我们做了有效的资金管理，严格划分每笔资金的来龙去脉，平台账户中的资金甚么时候应当到达甚么位置、到达谁的手上、甚么时候需要充、哪1部份可以提，非常明确。
有的用户喜欢尝试提现，以确认资金未被挪用，我们历来没有让他们失望过。
这样，资金盘又渐渐大了起来。
到了12月，2017年12月，是全部互联网金融的寒冬。
现金贷被1刀切，消费金融被重新定义，P2P被下最后通牒，货币基金、支付统统下发监管通知…
全部行业愁云惨淡。
我们的产品，也终究无力挽回了。
用户和标的1起减少，最后的最后，只有公司内部还有人在使用。
迭代已停了，但运维仍然为我们保存了线上的服务器，虽然它几近是死掉了。
2、复盘总结
这是我第1次主要负责1款产品。中间得到同事非常多的支持，也踩了很多坑。
现在写最重要的几点，给后来的盆友们：
1. 早期业务流程在闭环的条件下尽可能简化，直指目标不啰嗦
除非你非常肯定这个产品前程不可限量，否则不需要在业务上假想太多可能性，贴合自己公司的（老板想要的）才最有效。
在我的这1个产品启动的时候，已是P2P严格监管的时候，竞品多利润空间小，产品最初目的只是满足公司的资金需求，而我却在处理产品做大以后1定会需要的拓展性问题，可谓是不合时宜。
产品最开始的时候还是要面向最核心的诉求，减少旁枝末节，拓展性问题可以想一想，但具体的放在迭代再处理不迟。
2. 不要由于推行逻辑简单就放松警惕
互联网金融业面对复杂的业务逻辑和简单的推行逻辑，普遍轻视推行需求——但其实，里面每个细节都意味着：推行花出去的钱能买到多少用户。
前期放松的代价，是上线后推行获客效果被将就。
因此在产品早期、研发资源倾斜的时候，推行拉新和保存的关键环节，1定不能俭省，更不要拖到迭代再处理。
3. 不要过分紧缩设计周期
如果你的设计师没有足够的抗压能力，紧缩时间的下场就是做得不够好还没时间改。实在时间紧就紧缩1下自己画原型的周期。
4. 主动参与项目管理角色，而不是被动等待问题反馈
及时check研发进度，control研发节奏，中期加班好过最后加班。
当项目周期较长的时候，在研发进程中增加沟通，可以免1些研发对需求细节理解偏差的情况。
比如，偶尔旁听1下研发的例会，主动询问研发是不是遇到问题，主动与各组负责人沟通，参与黑盒测试等等。
特别是在快速推动的时候，研发压力比较大，有可能出现“直接依照自己的理解来做”还觉得跟需求1模1样的情况。
5. 重视第1次迭代
认真计划上线后第1次迭代，不要只当做简单的fixbug，产品前期迭代是用户增长的关键时刻。
对保存来讲，更新后用户的问题得到解决，他会更愿意留下。对拉新来讲，迭代做好后成功率更高。
6. 主动与领导沟通，而不是被动向领导汇报
在主导设计1个产品的时候，除硬实力要求，平常工作方式也要有转变。除对下游的主动推动，对领导也应当主动沟通，取得更多信息，也向领导反馈更多信息。
这个产品虽然上线时机不好，但并不是完全没有生机。
如果我在公司资源偏移的时候更多地尝试争取，去提升它在领导心里的优先级，更主动与业务团队接触，主动推动业务进程，或许还有1些跑赢监管时间的机会。
3、总结
现在基本尘埃落定了，悔之无用，惟有总结成文，希望对你有用。
固然，这中间也有非常多的收获。
从产品思惟到项目管理、部门调和、人际沟通等等，我都得到非常多的提升；这也是我们第1次，尝试多部门、快节奏、高耦合度的协作。
全部进程中，各研发小组的同事都非常nice。
- 测试的同事陪同研发做单元测试规避了好多坑；
- app小组在设计师没能全部交稿的时候就开始干活，双方找到了新的协作模式，为测试省出更多时间；
- 运维负责人直接找到我，建议增加资金流水数据监控；
- BI团队为新产品上线了全新的报表系统；
- 还有服务真个同事为了标的资金撮合策略加班到清晨5点；
- 更不用说上线后同事们的捧场支持了。
协作本身成功了，也影响了后续很多项目的推动模式，全部团队变得更紧凑，也更高效。
期间还收获了很多小火伴，在新的产品线1起合作。
———— / END / ————
作者：Conan
来源：人人都是产品经理，
