【作者】Conan

【來源】Conan產品研習社

【編輯】善小倩

 

故事從國內小貸業務上升開始。

 

小貸公司有他的天然短板——可以放貸、不能吸儲，資金不能形成閉環，因此普遍依賴外部資金方，不得不把到手的利潤讓出一部分。

 

在2017年，隨著各路小貸公司擴張規模，資金成本也一路上漲，利潤壓縮很嚴重，所以大家陸續開始考慮收購或者自己做資金端產品。

 

我在的公司也是出于這樣的考慮，開了一條P2P產品線。

 

這個產品（姑且叫A理財）的第一目的，是優化公司的資金結構。

 

這是從企業角度出發的產品目的，而對用戶來說，我們降低了中間成本、提高了用戶收益，但對市場來說這不足以做到差異化定位，還需要結合其它資源。

 

這是我第一次做理財產品。

 

調研分析過程花了比較長的時間，畫了好大好大一個腦圖來寫自己的idea然后一個一個處理掉，一路從需求摸索到提測，踩了無數坑，終于上線。

 

現在塵埃落定，我來復盤一下這個過程。

 

（對產品內容沒興趣的，可以直接跳到“復盤總結”去了）

 

 

一、P2P的6大塊

 

P2P產品簡單來說，可以分6個大塊：

 

1. 資產：包括資產接入、管理、風控、上標等

2. 資金：包括平臺資金、用戶資金、財務清結算等

3. 交易：包括標的/資金匹配、理財計劃、收益分配、逾期處理等

4. 賬戶：平臺/用戶多級賬戶體系

5. 合規：信息披露、簽章合同、現金流合規、資產合規等

6. 推廣：用戶拉新與留存、品牌推廣、紅包與加息券、社群

 

其中，風控我把它放在資產里，是因為貸前風控行為本身屬于資產端，對于小貸公司來說，P2P的風控與小貸風控差別有限，從業務模式到技術難度都不在一個量級。

 

下面一個一個地介紹。

 

1. 交易

 

之所以先寫交易，是因為它最難。

 

P2P交易的鏈條比較長，交易從借款人開始，包括四個大的部分：

 

1. 申請：申請借款–>平臺審核–>上標募集

2. 募集：出借人投標–>滿標–>劃撥資金給借款人–>開始計息

3. 收益清算：每日清算出借人昨日收益

4. 還款：借款人還款–>借款本金及利息劃款至出借人賬戶、服務費劃款給平臺收益賬戶，即完成一次正常還款；加上逾期、提前還款等違約情況，構成還款階段的主要事件。

 

在投標階段，因為資產類型不同：

 

• 對于大額資產來說，需要多個用戶去投才能滿標。

• 對小額資產來說，用戶一筆資金，可以滿好幾個標。

 

中間存在錯配，需要一個撮合策略，保證用戶投資后能盡快獲得收益。

 

2. 賬戶

 

賬戶分平臺賬戶、用戶賬戶兩類。平臺賬戶是一個大型賬戶下的多個子賬戶，用來做收益清結算、非常規交易中的資金清算。

 

用戶賬戶分兩級，第一級是資產結算賬戶，第二級有很多個，是出借人各個出借資產的收益清算賬戶。每次交易相當于給用戶建立一個新的二級賬戶，用來記錄投資人收益。

 

同時為了賬戶安全，接入實名二要素驗證，與銀行卡四要素驗證。

 

3. 資金

 

資金模塊為交易、賬戶提供基礎服務，包括接入支付通道、清結算服務、賬目流水，以及為財務和市場運行提供報表。

 

4. 資產

 

這一部分是小貸公司已有的業務，再增加資產是否通過審核、標的流標導致資產退回的行為。

 

5. 合規

 

合規要求現金流與資產流匹配，要求信息披露，有效的合同簽章，還有很多宣傳措辭問題。

 

這些在產品設計初期有所規劃，在設計后期與法務合作一個一個地處理下去就好。

 

這期間公司法務缺席了一段時間，用戶協議是我自己照貓畫虎地起草來的，想起來真是好不容易。

 

還有存管，交給商務團隊來處理。

 

6. 推廣

 

推廣是這個產品故事的高潮。

 

9月下旬產品終于上線，開始小范圍公測，我們在初期發相對高息的計劃（但對小貸業務來說是較低的資金成本），然后公司內部人手安裝一個。

 

因為周期較短，發薪當天，公司發出薪水的40%又回到了賬上。

 

為什么只有40%？

 

因為我們的工資卡是招商卡，它在支付通道筆單日限額太低，而我們設定的起投資金太高了[攤手]。

 

這很容易解決，只是出乎意料之外。

 

這一產品很受同事們喜歡，因為它利息高于外界同類產品，而且大家自己清楚它的風險點在哪，所以都非常捧場。

 

但在對外推廣的時候可以說是阻力重重。

 

首先是上架。

 

10月份應用市場風聲日緊，合規要求我們在新的實體中運作這個產品，但新產品在沒有金融資質的時候上不了架——看起來像個死局。

 

于是我們一邊嘗試IOS的企業開發者賬號，一邊走垂直社群，一邊做邀請紅包和加息劵。

 

我自己下手做客服，教IOS用戶不走App Store怎樣安裝（這后來在區塊鏈領域變成了通用手段）。

 

垂直社群推廣速度可以說非常慢，但用戶忠誠度出乎意料。

 

因為邁過了“產品沒有上架”“存管還在接”兩個心理門檻之后，用戶已經非常傾向于我們了;所以整個社群氛圍非常好，妹子們把閑錢放進來，還可以控制剁手。

 

然而，當時IOS收緊了審核標準，企業開發者賬號超級難申請，iOS的推廣幾乎是龜速，存管的推進一樣艱難。

 

用戶對我們保證的“正在接存管”也慢慢不再期待。

 

風險敏感的用戶開始撤離。

 

產品好像要死掉了。

 

我們盡力向用戶解釋我們的嚴謹和審慎（這一類設計會導致在產品中出現一些反用戶直覺的情況），我們的為存管做的準備已經全部上線，我們在小貸領域的盈利情況等等。

 

這樣，總算留下大部分用戶支持我們。

 

經歷了這一波低潮，資金盤有縮減，而公司度過了資金困境，不再關注這里，存管銀行對新產品興趣寥寥，即使新產品沒有歷史包袱。因為有太多做出了業績的公司在排隊。

 

孤立無援。

 

我們幾乎只能靠自我約束取信客戶——聽起來很好笑對不對？

 

具體怎么做的呢？

 

我們做了有效的資金管理，嚴格劃分每一筆資金的來龍去脈，平臺賬戶中的資金什么時候應該到達什么位置、到達誰的手上、什么時候需要充、哪一部分可以提，非常明確。

 

有的用戶喜歡嘗試提現，以確認資金未被挪用，我們從來沒有讓他們失望過。

 

這樣，資金盤又慢慢大了起來。

 

到了12月，2017年12月，是整個互聯網金融的寒冬。

 

現金貸被一刀切，消費金融被重新定義，P2P被下最后通牒，貨幣基金、支付通通下發監管通知…

 

整個行業愁云慘淡。

 

我們的產品，也終于無力挽回了。

 

用戶和標的一起減少，最后的最后，只有公司內部還有人在使用。

 

迭代已經停了，但運維依然為我們保留了線上的服務器，雖然它幾乎是死掉了。

 

二、復盤總結

 

這是我第一次主要負責一款產品。中間得到同事非常多的支持，也踩了很多坑。

 

現在寫最重要的幾點，給后來的盆友們：

 

1. 初期業務流程在閉環的前提下盡量簡化，直指目標不啰嗦

 

除非你非常確定這個產品前途不可限量，否則不需要在業務上設想太多可能性，貼合自己公司的（老板想要的）才最有效。

 

在我的這一個產品啟動的時候，已經是P2P嚴格監管的時候，競品多利潤空間小，產品最初目的只是滿足公司的資金需求，而我卻在處理產品做大之后一定會需要的拓展性問題，可謂是不合時宜。

 

產品最開始的時候還是要面向最核心的訴求，減少旁枝末節，拓展性問題可以想想，但具體的放在迭代再處理不遲。

 

2. 不要因為推廣邏輯簡單就放松警惕

 

互聯網金融業面對復雜的業務邏輯和簡單的推廣邏輯，普遍輕視推廣需求——但其實，里面每一個細節都意味著：推廣花出去的錢能買到多少用戶。

 

前期放松的代價，是上線后推廣獲客效果被將就。

 

因此在產品初期、研發資源傾斜的時候，推廣拉新和留存的關鍵環節，一定不能儉省，更不要拖到迭代再處理。

 

3. 不要過分壓縮設計周期

 

如果你的設計師沒有足夠的抗壓能力，壓縮時間的下場就是做得不夠好還沒時間改。實在時間緊就壓縮一下自己畫原型的周期。

 

4. 主動參與項目管理角色，而不是被動等待問題反饋

 

及時check研發進度，control研發節奏，中期加班好過最后加班。

 

當項目周期較長的時候，在研發進程中增加溝通，可以避免一些研發對需求細節理解偏差的情況。

 

比如，偶爾旁聽一下研發的例會，主動詢問研發是否遇到問題，主動與各組負責人溝通，參與黑盒測試等等。

 

特別是在快速推進的時候，研發壓力比較大，有可能出現“直接按照自己的理解來做”還覺得跟需求一模一樣的情況。

 

5. 重視第一次迭代

 

認真規劃上線后第一次迭代，不要只當成簡單的fixbug，產品前期迭代是用戶增長的關鍵時刻。

 

對留存來說，更新后用戶的問題得到解決，他會更愿意留下。對拉新來說，迭代做好后成功率更高。

 

6. 主動與領導溝通，而不是被動向領導匯報

 

在主導設計一個產品的時候，除了硬實力要求，日常工作方式也要有轉變。除了對下游的主動推動，對領導也應該主動溝通，獲得更多信息，也向領導反饋更多信息。

 

這個產品雖然上線時機不好，但并非完全沒有生機。

 

如果我在公司資源偏移的時候更多地嘗試爭取，去提升它在領導心里的優先級，更主動與業務團隊接觸，主動推進業務進程，也許還有一些跑贏監管時間的機會。

 

三、總結

 

現在基本塵埃落定了，悔之無用，唯有總結成文，希望對你有用。

 

當然，這中間也有非常多的收獲。

 

從產品思維到項目管理、部門協調、人際溝通等等，我都得到非常多的提升；這也是我們第一次，嘗試多部門、快節奏、高耦合度的協作。

 

整個過程中，各研發小組的同事都非常nice。

 

• 測試的同事陪同研發做單元測試規避了好多坑；

• app小組在設計師沒能全部交稿的時候就開始干活，雙方找到了新的協作模式，為測試省出更多時間；

• 運維負責人直接找到我，建議增加資金流水數據監控；

• BI團隊為新產品上線了全新的報表系統；

• 還有服務端的同事為了標的資金撮合策略加班到凌晨5點；

• 更不用說上線后同事們的捧場支持了。

 

協作本身成功了，也影響了后續很多項目的推進模式，整個團隊變得更緊湊，也更高效。

 

期間還收獲了很多小伙伴，在新的產品線一起合作。