直面使用者，PaaS產品經理的“免死金牌”和“尚方寶劍”

PaaS產品的設計非常依賴於技術和開發的方案，因此PaaS產品經理常常比較被動，會陷入枯燥且沒有動力的困境。那麼，作為一個PaaS產品經理，又該如何體現自身的價值、做出使用者喜愛的產品呢？

PaaS產品通常是以提供SDK和API的方式幫助開發者快速實現業務需求，而SDK和openAPI的設計又偏偏非常依賴技術能力與開發方案。也因如此，PaaS產品經理的工作往往被吐槽為被動、枯燥乃至傳聲筒，甚至有部分PaaS團隊直接由開發負責人來牽設計落地。那麼，作為一個PaaS產品經理，又該如何體現自身的價值、做出使用者喜愛的產品呢？

直面使用者，是一個解決問題的好答案。相信所有的公司、所有的產品團隊，都會把“使用者第一”放置在相當重要的地位。而對於PaaS產品經理而言，這尤其重要，甚至到達了決定生死存亡的地步。本文將透過PaaS本身與PaaS產品崗的特性進行介紹。

一、產品的本身特性

1. 直面使用者是商業化的必然要求

PaaS屬於B端產品，其商業化的屬性天然流淌在產品血液裡的。而幫助使用者提升業務指標或達到降本增效的目的，並以此獲取相應的報酬，是PaaS產品的基礎商業邏輯。

因此，想要真正把PaaS產品做好，使用者需要什麼、使用者的痛點哪裡、使用者的付費意願與付費能力這些都需要產品經理瞭然於心，僅靠開發提供技術方案是遠遠不夠的。

因為沒有直面使用者，我們就在一個產品定價問題上栽了跟頭。這是一個全新的產品模組，其特性會導致產品的成本相較其他模組在同等規模下會有大幅的提升，因此針對該模組設定了獨立的付費模式，同時為了防止體量過大，我們又增設了一個認為僅用來兜底的全新收費項。

而這一方案完全沒有與任何使用者溝通，也並未在一個使用者上預估，導致該計價方案一經上線，在第一個使用者身上就翻車了。該使用者在使用了產品新模組後，月賬單整整比之前高出了2000%，而實際觀測到的成本僅比上月增加了20%，結果也可想而知，使用者對於該月費用金額並不認可，我們也只能透過折扣、免額的方式快速修正賬單，不僅沒有提升收入，反而降低了使用者對我們的好感度和信任值。

如果我們可以更早一些的直面使用者，瞭解使用者對於新模組的付費意願程度、瞭解使用者的使用場景，相信我們一定可以設計出更合適、準確、高效獲客的定價機制。

另外，不論何時，產品經理的介入可以讓使用者感受到重視，同時增加對產品和服務的好感度，在同質化以及競爭如此激烈的當下，真誠的確可以增加新客簽約、老客增值或續費的成功率。

2. 只有直面使用者才能知道問題在哪

除了商業化，產品的功能、易用性也是PaaS產品的關鍵點。相較於SaaS，PaaS大大提升了產品多元化、定製化的能力，使用者只需考慮如何建立最佳使用者體驗即可。因此PaaS產品的使用者除了購買產品的“客戶”外、還有真正使用產品的開發者。

對於開發者而言，他的任務是對接PaaS平臺，並基於PaaS平臺的能力實現自身的產品需求。在對接過程中，最關心的無非兩個點：功能是否滿足、接入是否易用。這其中接入的易用性往往容易被人忽略，卻也往往成為產品成功的關鍵因素。

C端或SaaS產品是否易用往往體現在應用介面、互動體驗上，而PaaS產品的易用重心主要在開發文件與開發介面上。而介面則代表著工具本身的易用與否，介面的功能完善程度、個性化擴充套件能力、多端統一方案甚至是程式碼的簡潔優雅性，決定著開發者接入時的易用程度；開發文件就像是工具的說明書，是否簡單易懂又是否完整準確，同樣是影響開發者接入的重要因素。

作為PaaS產品經理，時常能聽到開發者對這兩項的吐槽和建議，而一般產品經理並不會完全接手這兩部分的工作，往往由開發和文件工程師提供相應的內容輸出，作為產品的領航者，產品經理能做的就是直面客戶、直面真實場景下的產品使用效果。

在沒有直面使用者前，永遠不會知道究竟是什麼原因導致開發者的吐槽。即便開發者使用者吐槽的內容非常的具體（如多端介面不統一），產品經理也同樣無法做到感同身受。但當你真正與開發者進行溝通甚至面對面看開發者敲程式碼時，所有問題與壓力如沙塵暴一般負面而來。這時候你才知道原來介面不統一會給應用開發帶去多大的麻煩；文件介紹不清晰、場景功能文件散落各地能讓人多抓狂；即便介面文件沒有任何問題，產品概念的特殊性也會讓開發無從下手。

透過直面開發者使用者，可以瞭解到介面對齊的重要性，在後續需求迭代過程中增加介面一致性、技術方案統一評審的流程；可以瞭解到不同產品&場景下的使用情況、量級、頻控等，可基於場景輸出最佳實踐方案；可以瞭解到接入的開發者中大多不具備自主開發能力、大部分專案也沒有過多的時間與人力資源，在產品提供的形式上增加simple code、demo甚至uikit（元件式接入）的形式，提升產品的整體易用性

二、產品崗位的特性

前面一部分，講的都是PaaS產品本身特性引發的直面使用者的重要性，作為PaaS產品經理，其本身工作的崗位也有不少特性是需要透過直面使用者而實現的。

1. 產品經理負責的內容決定著需要直面使用者

作為PaaS產品經理，雖然不需要做很多原型設計的工作，但負責的全鏈路產品策劃並不比C端產品簡單。

從前期的價值評估、種子客戶尋找、產品設計、產品驗證、產品包裝、產品定價，到釋出後的材料準備、客戶對接、產品迭代，再到穩步發展時的競品對比、使用者回訪、產品創新等等，每一步都需要產品經理踩下夯實的腳步，而想要做到夯實，直面客戶是最基礎的。

在產品設計之初，同時也是產品的調研階段，直面使用者可以幫助產品經理快速定位商業的價值點、定義MVP版本的需求範圍。火如釘釘，在創立之初直接派團隊成員駐紮在種子使用者公司，觀察、體驗辦公流程等一些列直面行為完成MVP版本釋出。

MVP版本上線後，是驗證產品核心價值的關鍵階段。在這一階段裡，明確產品的下一步規劃進展，包括產品功能的迭代、產品問題的修復、產品包裝的策略、新品定價等，基本包含了全鏈路的產品基礎要素。而這些都需要產品經理直面種子使用者，並基於使用者的使用情況、反饋內容以及付費意願等作出相應的判斷。可以說，該階段的產品經理除了本職工作外，還是新品的銷售、方案溝通師、售後對接人等等。 而在產品完成灰度或穩步增長後，一旦有新使用者的接入或諮詢，產品經理透過直面瞭解使用者場景，結合產品自身的特點主動給使用者提供相應解決方案，也是產品成功獲客的關鍵一步。

2. 直面使用者指導產品設計

直面使用者可以幫助產品經理快速、明確的瞭解使用者場景，減少因資訊傳輸鏈路過長、前向成員表達錯誤等因素造成的資訊不對齊、方案偏差。相信作為B端產品經理，經常能夠聽到一些來自客戶或前向的“指導”：我想要一個XXX的功能、客戶需要在這裡加一個欄位、那裡的效果能不能改成XXX…。。

這一類訴求往往是基於現狀或已有認知提出的具體解決方案，至於這個方案是否能完全解決問題？作為PaaS平臺最看重的延展性，該方案是否對其他使用者適用？在產品經理未做細緻瞭解與分析前均無法判斷，如果這時候貿然接手並開發交付，不僅會浪費人力、機器資源，甚至有丟失客戶的風險。

以IM產品（即時通訊聊天）舉例，相信現在大家對於直播間的實時彈幕已經習以為常了，其本質就是多人互動聊天，若基於早期的IM產品提供支援，使用者會提出“我想要一個無上限的群聊功能”，但作為IM PaaS產品經理，如果直接把需求做轉述並要求開發設計技術方案，那就真的成為了需求的傳聲筒，甚至連需求分析師都稱不上。

真正的做法應該是瞭解直播彈幕的場景以及基於該場景下的特殊需求：當前火爆的直播現狀，無論是購物直播還是秀場直播，觀看直播的人數往往可以突破百萬千萬，靠普通的群聊能力的確是完全無法支撐；但同時直播間往往沒有複雜的人員管理邏輯、進入直播間的成員也不會有長期留存的打算，一旦直播結束或切換直播間就會離開，因此從產品形態上完全沒有必要用到複雜的群聊管理能力與群聊維護能力。有了對直播場景的深入瞭解後產品經理就可以針對場景設計全新的輕盈的產品模式，既不需要做所謂“無上限群聊”的高難度需求，也可以透過產品經理的能力去提升PaaS產品本身的競爭力。

3. 技術知識儲備逼迫產品經理不得不直面使用者

如引言所說，在PaaS這類如此偏技術傾向性的領域裡，產品經理所佔據的地位話語權往往高不到哪去。使用者想要在線上會議裡使用十級美顏，開發說實現不了，產品瞬間沒招，只能忍痛拒絕客戶；使用者希望說希望一次同步可以獲得全量資訊返回，開發說只能返回200個，產品仍然毫無辦法；開發者頻繁吐槽產品不好用，接入很麻煩，產品聽著確實一頭霧水，不知如何下筆。

其中，大部分的原因在於產品經理的技術支援儲備有限，對於技術方案可干涉程度也沒有那麼高，即便是原開發轉的產品，在一段時間不接觸程式碼後對產品技術方案的熟悉程度也會逐漸下降。因此開發對產品在技術知識儲備維度的降維打擊在PaaS領域內尤為顯著。

這也是作為PaaS產品更應該直面使用者、接近使用者的一大原因，和開發正面硬剛研發能力毫無勝算、強迫透過技術方案（如200人群升級為百萬人群）既浪費資源又體現不出價值，只有做到真正從使用者中來，到使用者中去，做到心中有使用者、腦中有場景、筆下有方案，才能真正坐穩、坐好PaaS產品經理之位。

本文由 @碌碌無為的阿栓 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基於 CC0 協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。