編輯導語：我們經常能看到很多産品做成功的經驗，失敗了的産品經驗卻很少能夠看到。然而，光有成功的經驗是遠遠不夠的，失敗的經驗也能給我們帶來警醒。本文作者複盤了自己一年左右的項目經曆，從三個方面回顧了她是如何将一款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多個，實踐中遇到兩個一直無法很好解決的問題。

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

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

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

四、總結

1. 一個新的産品核心是要想好自己的業務模式；
2. 在大的業務模式和戰略方向明确的情況下拆解階段性産品目标以階段目标指導需求優先級規劃；
3. 以業務模式确定技術框架選型，不做大而全的設計，不為新技術而用新技術。

本文由 @遙遙瞎逼逼 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Pexels，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部