兩年SaaS之旅:我如何克服“老好人”困境
本文深入探討了作者在轉行過程中面臨的困境、所采取的策略以及最終實現的轉變。通過系統性解決方案的實施,作者不僅克服了“老好人病”,還幫助企業在SaaS領域尋找到了新的成長路徑。這篇文章不僅是個人職業轉型的記錄,更是對SaaS產品開發和需求管理策略的深刻洞察,提供了寶貴的經驗和啟示,推薦同行業的產品經理閱讀。
2022年9月從工作多年的教育行業,轉行至企業服務賽道。準確來說是從做教育行業To B產品轉為HR SaaS產品,將近2年時間。
在【如何在入職1周內,輸出產品規劃?】一文中,簡單聊過當時轉行的基本情況。
當時自己是有疑惑跟焦慮的,不確定是否可以順利轉行,更不確定HR SaaS產品的產品空間跟想象空間多大。
唯一確定的就是:HR SaaS產品賽道是市場足夠細分,產品足夠聚焦。所以它與教育行業B端產品所需的能力模型、方法論等,應該具備一定匹配度。
換句話說,產品能力與方法論足夠抽象的話,它是具備穿透行業的遷移能力的。甚至不夸張地說,它不局限于做產品。
比如你的學習力、抽象能力、思維方式等是可遷移的。所以面對新業務、新環境、新系統,比拼這些能力時,我是自信的。
比如你提煉/運用方法論的能力以及方法論本身,是可遷移的。
比如需求是0,方案是1、站在用戶視角看待問題、PM首先是用戶、從系統結構層面解決問題,而不是通過改變癥狀或人解決問題等方法論。
過程中,你也會發現有些方法論的局限性。
比如目標<=>任務=行為1…+行為N和行為=動機+能力+觸發,它只適用于角色類的工作臺之類的產品設計,不夠通用;
一問二定三量四確定:它不夠抽象,不具備遷移能力,只適用于某個足夠細分、足夠聚焦的角色或業務;
你也會重新發現或提煉一些“新”方法論(可能只是對于我來說新,實際對你已經是常識)
比如以終為始,全局思考;從始至終,最小閉環,它適用于B端產品的微積分模式;
KISS原則:SaaS產品設計最重要的原則的“三層八化”,它適用于SaaS產品的全局體驗設計提升與優化,它也再次印證了做企業產品的抽象能力的重要性。
如果時光倒流至兩年前的秋天,面對那時的自己,我可能會說:“恭喜你,你的判斷基本正確,你確實勝任了這份工作。”
然而,有兩件事是你未曾預料到的:
一是做SaaS產品竟然可以治好“老好人病”。
另一件是,雖然你勝任了這份工作,卻也和企業一起步入了寒冷的SaaS“冰封期”。
一、SaaS企業的需求長尾效應
在教育行業的ToB產品領域,當業務趨于成熟且未發生結構性變化時,面向內部教師、運營、學科等角色的需求往往會顯著減少。這種需求的減少可能會導致企業不得不投入資源去滿足一些成本高但價值相對較低的需求,這或許可以看作是行業內卷的一種體現。
以我們公司為例,我們幾乎每年都會對1-2個系統進行重構,如CRM系統、業務系統、客服系統、教師時段系統、教師管理平臺、教研系統、教師工作臺等。這些重構的目的是為了支持業務未來5-10年的發展(主要體現在系統的擴展性上),以及提升用戶體驗和工作效率(主要體現在交互設計上)。每次這樣的重構工程至少需要半年時間才能完成。
此外,我們也會不斷地深入優化核心模塊的產品功能,如課程產品規則、課程銷售方式、續報流程、排班系統等。這些工作可以被看作是精細化產品運營的一部分,盡管有人可能會戲稱為“沒事找事”。
因此,我曾經認為,產品經理最重要的能力是產品規劃能力。只有那些能夠進行半年甚至更長時間的產品規劃的產品經理,才能被稱為資深或專家級別的產品經理。
然而,當我進入HR SaaS行業時,我面臨的挑戰與教育行業的ToB產品截然不同。入職時,我面前有1736條待解決的需求。在近兩年的工作中,我解決了近1000條需求,但待解決的需求卻增加到了5219條。每周,我們還會收到超過10條新的需求。
更令人驚訝的是,至少90%的這些需求都是合理的。需求的分散性非常嚴重,呈現出一種長尾狀態。這意味著,很少有需求是超過20家客戶需要的,一部分需求是10-20家客戶需要的,更少的需求是5-10家客戶需要的,而最多的需求是只有1-5家客戶需要的。
二、“老好人”型PM的精疲力盡
SaaS業務的根本在于續費能力,而系統的穩定性、安全性和持續的免費迭代是確保續費的基礎。因此,我們全力以赴地接受并實現客戶的需求。
銷售團隊為了簽約客戶,如果存在5%-10%的需求未能得到滿足,他們往往會將這些需求寫入合同,并承諾客戶在某個特定時間點前解決,這就形成了倒排期的項目。
實施團隊為了縮短實施周期并確??蛻裟軌蝽樌\行系統,會盡力解決任何阻礙性問題,這通常也意味著系統需要升級迭代,從而成為倒排期的項目。
客戶成功團隊為了提高續費率,會在續費期采取“用需求換續簽”的策略,即承諾在某個時間點解決客戶的需求,這同樣導致了倒排期的項目。
為了“討好”客戶和內部團隊(包括銷售、實施和客戶成功),我全力以赴地迭代需求,不愿拒絕任何人,擔心說“不”會讓他們感到失望或憤怒,害怕拒絕可能引發的沖突(我厭惡沖突中的相互指責和無能為力)。
隨著時間的推移,我發現了幾個問題:
- 我們的需求迭代速度,只能達到新增需求的1/5(甚至更低)。即使我們有很長一段時間的每周“1096”(即每天10點-21點,每周6天);
- 我們重點投入的大項目、大需求,卻只解決5%-10%客戶需求,投入產出比不合理。例如,我們花費1-2個月時間完成了一些銷售新簽的承諾需求,但這些需求上線后,并沒有帶來預期的收益(如更多客戶使用或更高的續費率),反而可能帶來一些負面影響(如因交互設計或邏輯變化導致的客戶投訴)
- 如果一個人發現用策略(或手段)可達到獨占公共資源的話,TA不會因“得了便宜”而收斂,而是會“變本加厲”的持續占用,這是典型屬于“公地悲劇”。例如,總是那么2-3個銷售人員在簽約時將承諾需求寫入合同,他們可能還來自同一個團隊;或者在續費卡單時,總是那么幾個客戶成功人員提出必須承諾解決的需求,他們可能只是因為距離產品經理的物理位置更近。
- 產品經理的“老好人病”由整個團隊買單,而不只是你自己。例如,你輕易承諾的需求變成了倒排期項目,所有產研團隊成員只能加班工作,甚至為了按時交付不得不放棄一些擴展性的考慮。或者,在承諾需求之前未能充分溝通需求場景,承諾后才發現所需的投入資源是你最初預估的2-3倍,但由于已經承諾,只能硬著頭皮去做,導致投入產出嚴重不合理。
經過近一年的心力交瘁和團隊人員變動,我逐漸領悟到了幾個重要的道理:
- 再極限的“老好人”,也解決不了需求過剩問題,這是資源與能力的匹配問題。這就好比修建再多的路,也不一定能解決擁堵問題一樣;
- 通用需求的解決與客戶續費之間存在滯后效應,所以你無法有效衡量,通用需求的迭代,可以有效解決客戶滿意度(尤其是客戶老板、HRD等決策人);
- 需求的長尾效應是SaaS行業是通病。一定要尋求根本解,而不能依賴PM或相關伙伴;
- 你是“老好人”或“老惡人”,都不影響事情的結局,除了自我的內耗。所以尋求減少內耗的方式,才是解決問題的核心,而不是改變自己的性格
這些認識幫助我重新審視了工作的方式和方法,促使我尋找更加合理和高效的需求管理策略,以確保團隊能夠在滿足客戶需求的同時,保持健康的工作節奏。
三、系統性解決方案:超越個人角色的戰略視角
一個SaaS企業是一個復雜的系統,它與其服務的客戶群體共同構成了一個更大的生態系統。因此,解決問題的方法應當圍繞整個系統構建,而不是僅僅依賴于系統中的個別角色。
例如,讓一個“討好型”性格的產品經理不斷地通過上線需求來滿足銷售、客戶成功、實施團隊或客戶,其效果是有限的。同樣,要求銷售團隊在新簽合同時不承諾需求,或者讓客戶成功團隊不利用個人關系來推動需求排期,這些都不是長期的解決方案。
1. 明確戰略選擇和目標,實現需求優先級的精準定位
系統可以定義為:系統 = 目標 * 連接關系。
我們的目標從追求增長轉變為追求盈利,而盈利的關鍵在于降低成本和提高效率。降低成本主要包括控制產品研發、營銷、銷售和服務的成本,而這些成本的核心在于提升續費率和降低新簽成本。
首先,企業戰略選擇是關鍵,它涉及到企業定位、客戶心智和企業資源匹配度的權衡。
例如,根據客戶規模,可以分為巨型、超大型、大型、中型、小型和迷你型客戶;根據行業,可以分為制造業、互聯網、醫療醫藥、服務業、漁業、畜牧業、物業管理、娛樂業等;根據地域分布,可以分為國內不同區域和國外市場;根據客戶階段,可以分為意向、新簽、簽約和續簽客戶,每個階段的客戶需求也有所不同。
在資源有限的情況下,聚焦是明智的選擇。我們經過一段時間的探索,最終確定了我們的戰略方向。
第一階段,我們試圖從中小型企業轉向服務大型客戶,希望通過提高客單價來實現盈利。我們選擇了每個行業的1-2個標桿企業,圍繞它們的需求進行產品迭代,希望標準化產品能夠滿足更多同行業中小企業的需求。然而,經過半年的執行和復盤,我們發現標桿客戶的效果未達預期,原因主要包括:
- 用戶心智。我們在用戶心智中定位為中小型企業的SaaS服務商,想要改變這一形象并非易事;
- 管理機制與理念。即使是同一行業的相似規模和階段的企業,也可能因管理機制和理念的差異而有顯著不同的需求;
- 投入產出比。我們半年的努力僅滿足了3-4家大型客戶的需求,而這些需求并未被同行業其他企業采納。
第二階段,我們回歸到中小型企業客戶群,并專注于關鍵成長潛力的行業,如新興互聯網、制造業、醫療醫藥等。
在需求規劃時,我們聚焦于目標客戶群體的需求,策略性地放棄全局通用性需求和非目標客戶群體的需求。在與銷售、客戶成功、實施團隊溝通需求排期時,也優先考慮目標客戶群體的需求。
通過這些措施,我們算是邁出了構建系統性解決方案的關鍵一步,盡管還有很長的路要走。
2. 插件化:解決需求長尾效應的潛在方案
目前,有效解決SaaS行業長尾需求的方案主要有兩種:PaaS(包括低代碼平臺)和插件化市場。
PaaS兼具創造性和風險,它既能解決個性化的長尾需求,也可能帶來高昂的研發成本。
插件化市場雖然不易實施,但對于標準化SaaS產品企業來說,它具有可行性和想象力。其目標是解決客戶個性化需求,底層邏輯是有效利用社會資源。即標準化SaaS企業搭建插件平臺并運營插件市場,每個插件由自研或第三方團隊開發,旨在解決特定需求,同時可以在市場上銷售,以回收研發成本。
盡管成功不易,插件化是我們必須探索的路徑。在中國SaaS市場,標準化SaaS產品的優勢已經不如以往。
3. 重塑系統要素之間的連接關系,改善需求流轉機制
我們主要通過機制、流程和工具來重塑產品經理與客戶、銷售、實施、客戶成功團隊之間的需求流轉關系,以實現系統性解決方案。
具體措施包括:
1. 工具:建立需求池的反饋機制作為緩沖區,讓所有需求正常流轉,減輕產品經理的決策壓力。 例如,當銷售、實施或客戶成功團隊提出需求時,如果不是緊急需求,可以建議他們先將需求提交到需求池,然后統一進行規劃排期。
2. 流程:基于目標與戰略選擇,轉化為需求規劃以及對應原則,并文檔化與透明化,讓合作伙伴清晰需求機制,有效構建需求流轉流程。
基于系統的目標與戰略,落地為產品規劃原則與機制,并完成(季度/半年)產品規劃。同時,無論是產品規劃原則,還是產品規劃,最終都實現100%對外開放與透明,讓所有伙伴可隨時查閱,確保其提需求時,可查看規劃與原則。
3. 模式:用插件化模式,撬動社會化研發資源,解決個性需求。
首先,構建插件需求響應機制。
第二,基于SaaS的標準版本,構建可支持插件化的平臺。
第三,打造插件化案例,并開放對應插件平臺給第三方。
4. 雙向需求通路機制:這一機制旨在區分并解決個性緊急需求和通用性需求。
對于個性且緊急的需求,我們優先推薦插件化解決方案。如果客戶擁有自己的產研團隊,我們建議他們自行開發插件;如果沒有,我們會評估人力資源情況,并根據客戶的付費意愿來確定需求的優先級。
對于通用性需求,我們會評估其優先級。如果客戶愿意付費(或需求直接影響續簽),我們會適當調整其優先級以加快處理;否則,我們將這些需求納入常規規劃流程。
在資源與排期出現沖突時,我們會將涉及的多方及其領導拉入同一個群組,共同決定需求的最終優先級。
5. 法務介入的郵件確認流程:為了防止銷售團隊因新簽壓力而隨意承諾需求,我們引入了法務部門的介入。
銷售團隊在承諾任何需求之前,必須通過郵件與產品經理確認需求的排期和解決方案。法務團隊將參與評估,以確保承諾的可行性。只有當承諾被認為是可以執行的,銷售團隊才能進行排期;否則,他們不得承諾。
通過這些流程、機制、模式的建立,我們不僅提高了需求管理的效率,還降低了潛在的法律風險和運營成本。
四、總結一下
做SaaS產品是否可以治愈PM的“老好人病”?這個說法既有其合理性,也有其局限性。
合理性在于,通過實施系統性解決方案,我不再因需求問題給自己過大壓力,不再因害怕拒絕或討好別人而輕易承諾需求。我現在完全遵循流程、機制和模式來解決問題,即使是拒絕,我也能輕松且坦然地說“不”,避免自己和團隊承擔不必要的責任。
然而,這并不意味著我的性格發生了根本改變,而是我解決問題的方法變了。原本由我個人決策和控制的事情,現在轉變為依靠系統性解決方案(即流程、機制和模式),從而減輕了決策者的壓力。
系統性解決方案的含義是:系統 = 目標 * 連接關系。
系統性解決方案 = 通過重塑系統目標以及要素之間的連接關系來解決問題(而不是依賴人來解決)的方案。
例如,在SaaS行業中解決大量的長尾需求,并非僅靠PM(或其他角色)的努力就能實現,而是需要新模式、新流程、新機制。
系統性解決方案的關鍵要素包括:
- 目標:由追求增長轉變為追求盈利。
- 戰略:確定將三大行業的中小型企業作為核心客戶群。
- 工具:使用需求池的反饋機制作為緩沖區,讓所有需求正常流轉,減少PM的決策精力和壓力。
- 流程:根據目標和戰略選擇,轉化為需求規劃和對應原則,并將其文檔化和透明化,讓合作伙伴清晰了解需求機制,有效構建需求流轉流程。
- 模式:采用插件化模式,利用社會化研發資源,解決個性化需求。
- 機制:實施雙向需求通路,解決不同類型的需求。
- 流程:通過法務的介入,采用郵件確認形式,解決銷售隨意承諾需求的問題。
通過這些措施,SaaS產品的需求管理變得更加系統和規范,從而有助于PM克服“老好人病”,實現更加健康和可持續的工作方式。
專欄作家
邢小作,微信公眾號:邢小作之家,人人都是產品經理專欄作家。一枚在線教育的產品,關注互聯網教育,喜歡研究用戶心理。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
文章寫的很棒,很有參考價值。
另提醒文章的配圖已暴露隱私,建議重新打碼
是嗎?我再檢查看看,感謝提醒