SaaS產(chǎn)品工作的幾點感悟
編輯導語:大家做SaaS產(chǎn)品的工作應該已經(jīng)有一段時間了,SaaS是一個非常有挑戰(zhàn)的產(chǎn)品形態(tài),作者在這段時間踩了很多坑,也練出了一身肌肉。在這個過程中感到最大的挑戰(zhàn)就是客戶量起來后,對外如何用一套標準產(chǎn)品滿足不同行業(yè)不同類型客戶的花式需求,對內(nèi)如何高效協(xié)調(diào)好有限的研發(fā)資源,好鋼用在刀刃上,去實現(xiàn)每個迭代的產(chǎn)品目標。作者總結(jié)了一下個人感悟分享出來,希望對大家有所幫助。
一、產(chǎn)品設計的“完整性原則”
SaaS產(chǎn)品最大的特性就是用一套標準產(chǎn)品去滿足不同類型客戶的需求,因此在產(chǎn)品設計方面最重要的一個原則就是“完整性原則”,完整性原則就是產(chǎn)品經(jīng)理在進行需求設計時要完整考慮場景、考慮全部行業(yè)全部用戶、并且考慮未來迭代的擴展性,一次性把需求設計到位。
這是實際工作當中最容易犯的錯誤,很容易陷入“就事論事”,單個問題、單個模塊、單個客戶、單個時間點解決問題的大坑。
舉個例子說明一下:比如A客戶提出希望解決人員列表中存在的員工重名問題,希望增加工號字段;我們就需要完整考慮重名問題哪些場景還會遇到?除了名字還有其他字段重復時會產(chǎn)生麻煩?最終形成一個完整方案。
再比如B客戶提出希望不在組織通訊錄內(nèi)的代理商客戶也可以查閱企業(yè)的學習資料。這里就要完整考慮外部用戶除了代理商還可能有哪些?需求都是同樣的嗎?除了看學習資料,還需要下載轉(zhuǎn)發(fā)嗎?需要考試嗎?等等。
總之,產(chǎn)品設計需求的時候沒有考慮完整,最后不斷的修修補補,在整個相關功能上花費的研發(fā)工作量,遠遠超出了一次性完整開發(fā)一個功能模塊所需要的功能。
二、產(chǎn)品開發(fā)的靈活性
不同行業(yè)、類型客戶間產(chǎn)品使用的主場景差異不大,但是細節(jié)功能上的差異非常大,因此SaaS產(chǎn)品功能設計一定要具有普適性和靈活性??赡艽嬖趥€性化的流程一定要設計靈活的可配置項。為了提升靈活性,產(chǎn)品開發(fā)要遵循“樂高化”原則。
前端設計成一個個小組件,新的功能頁面只是使用已有組件去拼裝,就和搭積木一樣;后段采用微服務化,避免過度耦合。對于客戶的定制需求模塊也要獨立代碼開發(fā),最后通過接口與現(xiàn)有服務對接起來,不要在現(xiàn)有代碼上直接疊加開發(fā)。
三、產(chǎn)品需求管理的前置
SaaS售賣模式是“現(xiàn)在的產(chǎn)品+未來的承諾”,客戶對于未來產(chǎn)品迭代是有期待的,很多中大型客戶簽約時會提出自己的個性化需求;產(chǎn)品經(jīng)理要為銷售賦能,引導好客戶預期。(這里插一句題外話,銷售人員都是“短視”的,考慮的都是眼前的利益,因為屁股決定腦袋,銷售團隊考核的都是當月銷售業(yè)績,沒人考核兩年以后的,所以銷售人員一定要拿下眼前的這個單子)
所以產(chǎn)品團隊一定要提前規(guī)劃好產(chǎn)品的演進方向,將產(chǎn)品發(fā)展規(guī)劃的文檔同步到銷售團隊,這些內(nèi)容可以作為對于客戶的額外承諾,通過這個產(chǎn)品規(guī)劃可以將客戶需求限定在可掌控的范圍內(nèi),產(chǎn)品團隊掌握了需求的主動性,會省去非常多的麻煩。
四、個性化需求的處理
很多個性化需求都發(fā)展成了定制化,尤其是面對一些付費能力比較強的大客戶,這是一個做SaaS避不開的難題,老板舍不得大單,只能硬著頭皮接下來;問題是定制化需求的性價比極低,是對于產(chǎn)研資源的巨大浪費,是獲取短期利益,損害產(chǎn)品長遠發(fā)展的。
對于產(chǎn)品經(jīng)理來說,需要能將客戶的個性化需求引導轉(zhuǎn)化為標準化需求,把單個客戶的需求轉(zhuǎn)換成大多數(shù)客戶的功能,這個是做SARS的產(chǎn)品經(jīng)理能力當中最為關鍵的一點,具體怎么做要具體分析。
舉個例子說明:學習平臺中設定學員學習行為會加“學分”,輔助學習行為(上傳學習資料、授課視頻等)會增加積分,C客戶提出個性化需求:老師授課(屬于輔助學習行為)不要加積分,希望改為加學分。
這與平臺設定的規(guī)則完全違背,不可能為了這單個客戶去改其他客戶已經(jīng)適應了的規(guī)則,面對這種“寶藏需求”我們進行了深入分析,發(fā)現(xiàn)客戶是希望學員教師雙身份的人能夠把學分、積分合并,以便于自己學習好同時也能幫助他人學習的員工在排行榜上能排名更靠前,明白了“提升榮譽感”這個原始訴求我們就可以進行相應的引導設計。
以上是個人的一點感悟,SaaS產(chǎn)品不是簡單的B端產(chǎn)品,它的產(chǎn)品形態(tài)決定了他所面臨的挑戰(zhàn),我們作為產(chǎn)品經(jīng)理要針對不同的服務模式、不同的客戶類型去調(diào)整我們的設計思路。
PS:大家可以關注一下產(chǎn)品經(jīng)理相關的招聘信息。就會發(fā)現(xiàn)關于SaaS相關能力要求的產(chǎn)品崗越來越多了,說明這種產(chǎn)品形態(tài)越來越普及。企業(yè)逐漸接受用租賃而不是一次性買斷的方式,尤其是在疫情的背景下,這種低成本又靈活的軟件形態(tài)更受歡迎,各位產(chǎn)品同學可以沉淀一下相關的能力。
本文由 @Jiahhy 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
這段不太懂它的實現(xiàn)原理:
對于客戶的定制需求模塊也要獨立代碼開發(fā),最后通過接口與現(xiàn)有服務對接起來,不要在現(xiàn)有代碼上直接疊加開發(fā)。
意思應該是不要改動現(xiàn)有代碼,另外加接口實現(xiàn)用戶的定制需求,用戶也可以使用這些接口API,公司可以提供開放接口API地址
這個是做SARS的產(chǎn)品經(jīng)理能力當中最為關鍵的一點
—
這里是不是寫錯了,應該是SAAS
是的,感謝糾錯
關于不同客戶的不同需求,如何做好引導設計,作者能夠詳細的介紹下嗎,感謝!
這個問題很難,很復雜
整篇文章看下來,我覺得SaaS產(chǎn)品的工作很有條理性!明確的知道產(chǎn)品定位及工作方向,今后的工作也要向他們學習!
感覺還得多看幾遍才能看懂
厲害厲害
寫得好好!
這個確實有點厲害