酷播亮新聞
最棒的知識補給站

經驗貼:一個P2P產品的生死記

2017年是互聯網金融行業飛到最高點然後摔的半死的一年。 我很幸運地在這一年正在從事這個行業。 現在塵埃基本落定,复盤一下我當時做到死的一款產品。

這個故事從國內小貸業務上升開始。 小貸公司有他的天然短板,可以放貸、不能吸儲,資金不能形成閉環,因此普遍依賴外部資金方,不得不把到手的利潤讓出一部分。

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

我在的公司也是出於這樣的考慮,開了一條P2P產品線。 所以這個產品(姑且叫A理財)的第一目的,是優化公司的資金結構。 這是從企業角度出發的產品目的,而對用戶來說,我們降低了中間成本、提高了用戶收益,但對市場來說這不足以做到差異化定位,還需要結合其它資源。

這是我第一次做理財產品。 調研分析過程花了比較長的時間,畫了好大好大一個腦圖來寫自己的idea然後一個一個處理掉,一路從需求摸索到提測,踩了無數坑,終於上線。 現在塵埃落定,我來复盤一下這個過程。

(對產品內容沒興趣的,可以直接跳到“复盤總結”去了)

P2P產品簡單來說,可以分6個大塊。

  1. 資產:包括資產接入、管理、風控、上標等
  2. 資金:包括平台資金、用戶資金、財務清結算等
  3. 交易:包括標的/資金匹配、理財計劃、收益分配、逾期處理等
  4. 賬戶:平台/用戶多級賬戶體系
  5. 合規:信息披露、簽章合同、現金流合規、資產合規等
  6. 推廣:用戶拉新與留存、品牌推廣、紅包與加息券、社群

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

下面一個一個地介紹。

交易

之所以先寫交易,是因為它最難。 P2P交易的鏈條比較長,交易從借款人開始,包括四個大的部分:

  1. 申請:申請借款–>平台審核–>上標募集
  2. 募集:出借人投標–>滿標–>劃撥資金給借款人–>開始計息
  3. 收益清算:每日清算出借人昨日收益
  4. 還款:借款人還款–>借款本金及利息划款至出借人賬戶、服務費划款給平台收益賬戶,即完成一次正常還款。 加上逾期、提前還款等違約情況,構成還款階段的主要事件。

在投標階段,因為資產類型不同,對於大額資產來說,需要多個用戶去投才能滿標。 對小額資產來說,用戶一筆資金,可以滿好幾個標。 中間存在錯配,需要一個撮合策略,保證用戶投資後能盡快獲得收益。

賬戶

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

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

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

資金

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

資產

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

合規

合規要求現金流與資產流匹配,要求信息披露,有效的合同簽章,還有很多宣傳措辭問題,這些在產品設計初期有所規劃,在設計後期與法務合作一個一個地處理下去就好。 這期間公司法務缺席了一段時間,用戶協議是我自己照貓畫虎地起草來的,想起來真是好不容易。

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

推廣

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

9月下旬產品終於上線,開始小範圍公測,我們在初期發相對高息的計劃(但對小貸業務來說是較​​低的資金成本),然後公司內部人手安裝一個。 因為周期較短,發薪當天,公司發出薪水的40%又回到了賬上。 為什麼只有40%? 因為我們的工資卡是招商卡,它在支付通道筆單日限額太低,而我們設定的起投資金太高了[攤手]。 這很容易解決,只是出乎意料之外。

這一產品很受同事們喜歡,因為它利息高於外界同類產品,而且大家自己清楚它的風險點在哪,所以都非常捧場。 但在對外推廣的時候可以說是阻力重重。

首先是上架。

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

於是我們一邊嘗試IOS的企業開發者賬號,一邊走垂直社群,一邊做邀請紅包和加息劵。 我自己下手做客服,教IOS用戶不走appstore怎樣安裝(這後來在區塊鏈領域變成了通用手段)。

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

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

然而,當時IOS收緊了審核標準,企業開發者賬號超級難申請,Ios的推廣幾乎是龜速,存管的推進一樣艱難。 用戶對我們保證的“正在接存管”也慢慢不再期待。

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

產品好像要死掉了。

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

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

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

孤立無援。 我們幾乎只能靠自我約束取信客戶——聽起來很好笑對不對?

具體怎麼做的呢?

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

有的用戶喜歡嘗試提現,以確認資金未被挪用,我​​們從來沒有讓他們失望過。 這樣,資金盤又慢慢大了起來。

到了12月,2017年12月,是整個互聯網金融的寒冬。 現金貸被一刀切,消費金融被重新定義,P2P被下最後通牒,貨幣基金、支付通通下發監管通知…整個行業愁雲慘淡。

我們的產品,也終於無力挽回了。

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

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

复盤總結

這是我第一次主要負責一款產品。 中間得到同事非常多的支持。 也踩了很多坑。 現在寫最重要的幾點,給後來的盆友們。

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

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

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

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

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

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

前期放鬆的代價,是上線後推廣獲客效果被將就。

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

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

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

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

及時check研發進度,control研發節奏,中期加班好過最後加班。 當項目週期較長的時候,在研發進程中增加溝通,可以避免一些研發對需求細節理解偏差的情況。

比如,偶爾旁聽一下研發的例會,主動詢問研發是否遇到問題,主動與各組負責人溝通,參與黑盒測試等等。 特別是在快速推進的時候,研發壓力比較大,有可能出現“直接按照自己的理解來做”還覺得跟需求一模一樣的情況。

5.重視第一次迭代

認真規劃上線後第一次迭代,不要只當成簡單的fixbug,產品前期迭代是用戶增長的關鍵時刻。 對留存來說,更新後用戶的問題得到解決,他會更願意留下。 對拉新來說,迭代做好後成功率更高。

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

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

這個產品雖然上線時機不好,但並非完全沒有生機,如果我在公司資源偏移的時候更多地嘗試爭取,去提升它在領導心裡的優先級,更主動與業務團隊接觸,主動推進業務進程 ,也許還有一些跑贏監管時間的機會。

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

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

整個過程中,各研發小組的同事都非常nice。 測試的同事陪同研發做單元測試規避了好多坑;app小組在設計師沒能全部交稿的時候就開始乾活,雙方找到了新的協作模式,為測試省出更多時間;運維負責人 直接找到我,建議增加資金流水數據監控,BI團隊為新產品上線了全新的報表系統,還有服務端的同事為了標的資金撮合策略加班到凌晨5點;更不用說上線後同事們的捧場支持了 。

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

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

 

作者:Conan

來源:微信公眾號:Conan產品研習社

本文由 @Conan  授權發佈於人人都是產品經理,未經作者許可,禁止轉載。

題圖來自PEXELS,基於CC0協議

如有侵權請來信告知:酷播亮新聞 » 經驗貼:一個P2P產品的生死記