我們經常能看到很多產品做成功的經驗，失敗了的產品經驗卻很少能夠看到。然而，光有成功的經驗是遠遠不夠的，失敗的經驗也能給我們帶來警醒。本文作者復盤了自己一年左右的項目經歷，從三個方面回顧了她是如何將一款SaaS產品做死的。

最近做的一個項目經過一年左右的迭代終于還是走到了項目生命的盡頭，做完最后兩個迭代后進入維護期不再做功能開發(fā)和推廣。

成功的經驗總被人談起，失敗的過程卻很少有人再提。成功很多時候不可再復制，而失敗卻總是有相同的原因，把失敗項目的復盤記錄下來希望能在新的項目中少走彎路。

本文會從產品定位、需求把控、技術框架三個方面來復盤我是怎么把一款SaaS產品做死的。

一、背景

1. 公司業(yè)務

公司有一個主營業(yè)務比較穩(wěn)定，一個快銷品線上活動代運營業(yè)務，最后是我負責的創(chuàng)新業(yè)務產品，主要為公司尋找一些新的增長機會。

在進入公司負責該產品之前，公司已經已經在新業(yè)務探索了一年左右的時間，做過3、4個小程序但一直沒有能夠贏利的產品，這次上馬小程序SaaS產品對贏利期望較大。

2. 項目目標

在之前已經有一個購買的三方商城系統(tǒng)（10年前的產品），通過給品牌做商城系統(tǒng)及代運營服務拿到過訂單。項目立項時的目的是通過將商城進行SaaS化改造，快速部署商城及代運營的能力。

此時BD號稱手中已經有2筆商城系統(tǒng)訂單，每筆總價在50W左右。

另一方面，CTO和產品總監(jiān)看到市面上有可自由組合的小程序產品宣稱能夠覆蓋大部分線下零售業(yè)務場景，期望在產品設計時也能夠參考，方便產品后期進行業(yè)態(tài)拓展。

二、項目發(fā)展回顧

回顧項目發(fā)展大致可分為三個階段：小程序化改造、框架完善、產品探索（框架完善同步進行）

1. 小程序化改造

確定好短期目標，是完成銷售手中的訂單后開始全力進行商城SaaS化改造的工作，所有產研同學都被拉入到項目室進行閉門開發(fā)。

通過一個多月的時間，終于完成了原有商城系統(tǒng)的多端改造，使用原有商城系統(tǒng)業(yè)務邏輯砍掉多余功能。因為原有商城系統(tǒng)前后端不分離，對整個商城C端頁面進行了重寫后臺重新梳理出對應接口。

本著MVP原則，第一個版本所有小程序配置項都需要開發(fā)在代碼中配置。為支持多應用體系框架上增加了租戶層，用來作為賬號、權限、應用管理的平臺。

后來應為這個租戶端多應用體系還出過不少技術問題，暫且先不詳細展開。

當項目組所有成員歡欣鼓舞的完成第一個版本上線后，銷售那邊卻遲遲簽不下來合同，經過1個月左右的銷售跟進最終這兩個項目還是給丟了。

其實后面被銷售牽著鼻子走的事情還在一直發(fā)生，只是當時整個決策都是想著如何能夠拿到錢向老板證明項目的贏利能力，沒有體系化的去決定做什么。

2. 框架完善

品牌自有商城項目未能接到訂單，銷售人員在品牌拿不到商城訂單的情況下產品只能另謀出路。主要思路轉為中小商家，希望借力各個平臺推廣自己平臺小程序的機會，推出更多端的小程序商城產品。

為此，在近3個月的迭代中有一半需求圍繞小程序版本和多端拓展的工作進行。

由于原有后臺管理頁面前后端不分離框架太老，新功能上線后都在新的系統(tǒng)框架中進行開發(fā)，新老框架來回跳轉帶來很多系統(tǒng)兼容問題，不得不再花一半的精力進行原有功能重構。

3. 產品探索

市場層面，既然賣不動那是否可以嘗試自己運營？

于是商務部門找來了幾個進口品牌渠道商，開通對應的品牌商城小程序，嘗試運營自己的私域流量賣貨。由于品牌知名度不夠，且商務對品牌運營經驗不夠，嘗試社群推介和直播推薦都沒有取得比較好的效果。

倒是運營人員一直在給商城提出營銷需求，商城功能遷移的同時不斷增加營銷玩法（營銷玩法多了后交易流程復雜性上升）。

自運營沒起來，老板開始動用自己的關系拉客戶，找了商超、烘焙和洗車行業(yè)的店作為種子用戶；另一方面唯一的地推人員開始進行推廣，由于沒有行業(yè)限制，只要有小程序需求的商家都被銷售找了過來（美業(yè)、餐飲、母嬰）。

繁多的線下交易模式和原有線上商城的區(qū)別還是相對較大，在原有商城的基礎上進行對應的改造復雜度進一步提升。

但可惜的是，對應種子用戶在使用產品后由于缺乏流量運營手段，使用效果不佳對產品反饋不好，于是不斷的切換行業(yè)希望找到一個競爭較小的行業(yè)作為切入點，但這個點一直沒找到。

三、問題總結及反思

1. 戰(zhàn)略層面：不清楚產品核心業(yè)務模式和優(yōu)勢

在這個項目中，產品的目標客戶和市場一直在變。

造成這個局面的很大一部分原因是覺得哪里能看到錢就去做什么，從最開始的品牌商商城到自營商城再到線下各行業(yè)零售業(yè)態(tài)的嘗試都是這個模式。

更多的需求來源于銷售驅動，銷售說這個做了就能賣錢，于是功能就往上加。每一項功能都有但每項功能都不能同競品形成優(yōu)勢。同時沒有規(guī)劃的增加功能到最終會使系統(tǒng)復雜程度幾何倍的增加。

總結下來這個項目是沒有核心產品戰(zhàn)略的，碰到什么做什么。

SaaS產品功能做出來一定能賣出去嗎？即使賣出去那一定能賺錢嗎？

如果是賣功能就要找準產品的差異點，如果沒有差異點那就要拼渠道資源和銷售能力；如果不是靠付費作為主要收入來源，那就要想好其他商業(yè)模式贏利的關鍵點（例如：POS產商靠抽傭賺錢，CRM產商靠短信和廣告投放賺錢）。

就這個項目來說產品戰(zhàn)略可使用常用的SWOT分析方法，公司的優(yōu)勢是有較多的品牌商資源如果從品牌方營銷的角度出發(fā)打造營銷平臺項目還是有可能存活下來的。

公司弱勢是技術能力，尤其在開發(fā)商城的過程中表現(xiàn)比較明顯。營銷活動相對較簡單和獨立，開發(fā)起來相對容易。在和支付寶小二溝通時其實也看到品牌對小B和C端用戶數(shù)據(jù)的一些訴求，結合這點去做營銷能力應該也能獲得平臺更大的支持。

現(xiàn)在回頭去看，阿里已經整合了零售通門店POS能力，使用小程序在中小零售店內進行品牌券的派發(fā)，逐步打通了品牌和中小零售商的信息壁壘。

這個模式，有空再單獨拿出來講背后的邏輯。

2. 需求把控：因為方向不明確帶來的需求優(yōu)先級看客戶催的急不急

因為沒有明確的產品方向和產品方向的來回切換在確立需求優(yōu)先級的時候，往往靠當時想要推的那個行業(yè)的種子客戶提了什么需求，有需求就往上加。

例如：公司自運營商城的時候提出需要一個分銷功能，運營追著產品說上線前只要上線就能大賣，實際上線無人問津的情況。

究其原因，還是在確認需求前沒有對自身資源進行有效評估，做分銷最重要的是要有分銷渠道資源和激勵機制，并不是簡單的老板有人脈往群里扔一個分銷鏈接就能解決的問題。

應為對商城來說，客戶關心的是銷量所以更多的時候都是營銷需求，系統(tǒng)一些基礎功能如配送、商品管理功能從舊有系統(tǒng)遷移反而優(yōu)先級被調低。

導致的后果是種子用戶在使用時來回在多個系統(tǒng)切換效率和體驗都非常差，還經常會出一些bug。但我們回頭去遷移這些基礎功能的時候，又花了大量精力去兼容在原有基礎功能上開發(fā)的營銷功能。

3. 技術框架：切忌貪大求全，適合的才是好的

在項目初期，正是中臺概念大火之時。

基于保證后續(xù)多行業(yè)的可拓展性和對中臺概念的著迷，整個系統(tǒng)采用了微服務的框架。經過大半年的迭代微服務數(shù)量達到了20多個，實踐中遇到兩個一直無法很好解決的問題。

服務數(shù)量導致的混亂和資源緊張：一個功能往往會涉及到多個服務，剛開始開發(fā)人員多的時候經常出現(xiàn)服務間信息不一致，后期開發(fā)資源減少又面臨一個開發(fā)人員維護多個服務，人多人少都或多或少的降低開發(fā)效率；服務抽象不清晰，設計不合理，一個需求都需要大改服務。其實這個問題，有一部分原因也應該歸結于產品核心業(yè)務邏輯不明確。

新的技術固然有它的好處，但技術始終是服務于業(yè)務。對于新產品來說最重要的是要把業(yè)務跑起來能夠形成正向的循環(huán)而不是為了最求最新的技術。

下圖是當時做的架構藍圖，規(guī)劃還是很美好的：

四、總結

一個新的產品核心是要想好自己的業(yè)務模式；在大的業(yè)務模式和戰(zhàn)略方向明確的情況下拆解階段性產品目標以階段目標指導需求優(yōu)先級規(guī)劃；以業(yè)務模式確定技術框架選型，不做大而全的設計，不為新技術而用新技術。