編輯導語：我們經常能看到很多產品做成功的經驗，失敗了的產品經驗卻很少能夠看到。然而，光有成功的經驗是遠遠不夠的，失敗的經驗也能給我們帶來警醒。本文作者覆盤了自己一年左右的項目經歷，從三個方面回顧了她是如何將一款SaaS產品做死的。
最近做的一個項目經過一年左右的迭代終於還是走到了項目生命的盡頭，做完最後兩個迭代後進入維護期不再做功能開發和推廣。
成功的經驗總被人談起，失敗的過程卻很少有人再提。成功很多時候不可再複製，而失敗卻總是有相同的原因，把失敗項目的覆盤記錄下來希望能在新的項目中少走彎路。
本文會從產品定位、需求把控、技術框架三個方面來複盤我是怎麼把一款SaaS產品做死的。
一、背景
1. 公司業務
公司有一個主營業務比較穩定，一個快銷品線上活動代運營業務，最後是我負責的創新業務產品，主要為公司尋找一些新的增長機會。
在進入公司負責該產品之前，公司已經已經在新業務探索了一年左右的時間，做過3、4個小程序但一直沒有能夠贏利的產品，這次上馬小程序SaaS產品對贏利期望較大。
2. 項目目標
在之前已經有一個購買的三方商城系統（10年前的產品），通過給品牌做商城系統及代運營服務拿到過訂單。項目立項時的目的是通過將商城進行SaaS化改造，快速部署商城及代運營的能力。
此時BD號稱手中已經有2筆商城系統訂單，每筆總價在50W左右。
另一方面，CTO和產品總監看到市面上有可自由組合的小程序產品宣稱能夠覆蓋大部分線下零售業務場景，期望在產品設計時也能夠參考，方便產品後期進行業態拓展。
二、項目發展回顧
回顧項目發展大致可分為三個階段：小程序化改造、框架完善、產品探索（框架完善同步進行）
1. 小程序化改造
確定好短期目標，是完成銷售手中的訂單後開始全力進行商城SaaS化改造的工作，所有產研同學都被拉入到項目室進行閉門開發。
通過一個多月的時間，終於完成了原有商城系統的多端改造，使用原有商城系統業務邏輯砍掉多餘功能。因為原有商城系統前後端不分離，對整個商城C端頁面進行了重寫後臺重新梳理出對應接口。
本著MVP原則，第一個版本所有小程序配置項都需要開發在代碼中配置。為支持多應用體系框架上增加了租戶層，用來作為賬號、權限、應用管理的平臺。
後來應為這個租戶端多應用體系還出過不少技術問題，暫且先不詳細展開。
當項目組所有成員歡欣鼓舞的完成第一個版本上線後，銷售那邊卻遲遲籤不下來合同，經過1個月左右的銷售跟進最終這兩個項目還是給丟了。
其實後面被銷售牽著鼻子走的事情還在一直髮生，只是當時整個決策都是想著如何能夠拿到錢向老闆證明項目的贏利能力，沒有體系化的去決定做什麼。
2. 框架完善
品牌自有商城項目未能接到訂單，銷售人員在品牌拿不到商城訂單的情況下產品只能另謀出路。主要思路轉為中小商家，希望借力各個平臺推廣自己平臺小程序的機會，推出更多端的小程序商城產品。
為此，在近3個月的迭代中有一半需求圍繞小程序版本和多端拓展的工作進行。
由於原有後臺管理頁面前後端不分離框架太老，新功能上線後都在新的系統框架中進行開發，新老框架來回跳轉帶來很多系統兼容問題，不得不再花一半的精力進行原有功能重構。
3. 產品探索
市場層面，既然賣不動那是否可以嘗試自己運營？
於是商務部門找來了幾個進口品牌渠道商，開通對應的品牌商城小程序，嘗試運營自己的私域流量賣貨。由於品牌知名度不夠，且商務對品牌運營經驗不夠，嘗試社群推介和直播推薦都沒有取得比較好的效果。
倒是運營人員一直在給商城提出營銷需求，商城功能遷移的同時不斷增加營銷玩法（營銷玩法多了後交易流程複雜性上升）。
自運營沒起來，老闆開始動用自己的關係拉客戶，找了商超、烘焙和洗車行業的店作為種子用戶；另一方面唯一的地推人員開始進行推廣，由於沒有行業限制，只要有小程序需求的商家都被銷售找了過來（美業、餐飲、母嬰）。
繁多的線下交易模式和原有線上商城的區別還是相對較大，在原有商城的基礎上進行對應的改造複雜度進一步提升。
但可惜的是，對應種子用戶在使用產品後由於缺乏流量運營手段，使用效果不佳對產品反饋不好，於是不斷的切換行業希望找到一個競爭較小的行業作為切入點，但這個點一直沒找到。
三、問題總結及反思
1. 戰略層面：不清楚產品核心業務模式和優勢
在這個項目中，產品的目標客戶和市場一直在變。
造成這個局面的很大一部分原因是覺得哪裡能看到錢就去做什麼，從最開始的品牌商商城到自營商城再到線下各行業零售業態的嘗試都是這個模式。
更多的需求來源於銷售驅動，銷售說這個做了就能賣錢，於是功能就往上加。每一項功能都有但每項功能都不能同競品形成優勢。同時沒有規劃的增加功能到最終會使系統複雜程度幾何倍的增加。
總結下來這個項目是沒有核心產品戰略的，碰到什麼做什麼。
SaaS產品功能做出來一定能賣出去嗎？即使賣出去那一定能賺錢嗎？
如果是賣功能就要找準產品的差異點，如果沒有差異點那就要拼渠道資源和銷售能力；如果不是靠付費作為主要收入來源，那就要想好其他商業模式贏利的關鍵點（例如：POS產商靠抽傭賺錢，CRM產商靠短信和廣告投放賺錢）。
就這個項目來說產品戰略可使用常用的SWOT分析方法，公司的優勢是有較多的品牌商資源如果從品牌方營銷的角度出發打造營銷平臺項目還是有可能存活下來的。
公司弱勢是技術能力，尤其在開發商城的過程中表現比較明顯。營銷活動相對較簡單和獨立，開發起來相對容易。在和支付寶小二溝通時其實也看到品牌對小B和C端用戶數據的一些訴求，結合這點去做營銷能力應該也能獲得平臺更大的支持。
現在回頭去看，阿里已經整合了零售通門店POS能力，使用小程序在中小零售店內進行品牌券的派發，逐步打通了品牌和中小零售商的信息壁壘。
這個模式，有空再單獨拿出來講背後的邏輯。
2. 需求把控：因為方向不明確帶來的需求優先級看客戶催的急不急
因為沒有明確的產品方向和產品方向的來回切換在確立需求優先級的時候，往往靠當時想要推的那個行業的種子客戶提了什麼需求，有需求就往上加。
例如：公司自運營商城的時候提出需要一個分銷功能，運營追著產品說上線前只要上線就能大賣，實際上線無人問津的情況。
究其原因，還是在確認需求前沒有對自身資源進行有效評估，做分銷最重要的是要有分銷渠道資源和激勵機制，並不是簡單的老闆有人脈往群裡扔一個分銷鏈接就能解決的問題。
應為對商城來說，客戶關心的是銷量所以更多的時候都是營銷需求，系統一些基礎功能如配送、商品管理功能從舊有系統遷移反而優先級被調低。
導致的後果是種子用戶在使用時來回在多個系統切換效率和體驗都非常差，還經常會出一些bug。但我們回頭去遷移這些基礎功能的時候，又花了大量精力去兼容在原有基礎功能上開發的營銷功能。
3. 技術框架：切忌貪大求全，適合的才是好的
在項目初期，正是中臺概念大火之時。
基於保證後續多行業的可拓展性和對中臺概念的著迷，整個系統採用了微服務的框架。經過大半年的迭代微服務數量達到了20多個，實踐中遇到兩個一直無法很好解決的問題。
- 服務數量導致的混亂和資源緊張：一個功能往往會涉及到多個服務，剛開始開發人員多的時候經常出現服務間信息不一致，後期開發資源減少又面臨一個開發人員維護多個服務，人多人少都或多或少的降低開發效率；
- 服務抽象不清晰，設計不合理，一個需求都需要大改服務。其實這個問題，有一部分原因也應該歸結於產品核心業務邏輯不明確。
新的技術固然有它的好處，但技術始終是服務於業務。對於新產品來說最重要的是要把業務跑起來能夠形成正向的循環而不是為了最求最新的技術。
下圖是當時做的架構藍圖，規劃還是很美好的：
四、總結
- 一個新的產品核心是要想好自己的業務模式；
- 在大的業務模式和戰略方向明確的情況下拆解階段性產品目標以階段目標指導需求優先級規劃；
- 以業務模式確定技術框架選型，不做大而全的設計，不為新技術而用新技術。
本文由 @遙遙瞎逼逼 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Pexels，基於 CC0 協議
