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 協議

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