PaaS產(chǎn)品的設(shè)計非常依賴于技術(shù)和開發(fā)的方案，因此PaaS產(chǎn)品經(jīng)理常常比較被動，會陷入枯燥且沒有動力的困境。那么，作為一個PaaS產(chǎn)品經(jīng)理，又該如何體現(xiàn)自身的價值、做出用戶喜愛的產(chǎn)品呢？
PaaS產(chǎn)品通常是以提供SDK和API的方式幫助開發(fā)者快速實現(xiàn)業(yè)務(wù)需求，而SDK和openAPI的設(shè)計又偏偏非常依賴技術(shù)能力與開發(fā)方案。也因如此，PaaS產(chǎn)品經(jīng)理的工作往往被吐槽為被動、枯燥乃至傳聲筒，甚至有部分PaaS團(tuán)隊直接由開發(fā)負(fù)責(zé)人來牽設(shè)計落地。那么，作為一個PaaS產(chǎn)品經(jīng)理，又該如何體現(xiàn)自身的價值、做出用戶喜愛的產(chǎn)品呢？
直面用戶，是一個解決問題的好答案。相信所有的公司、所有的產(chǎn)品團(tuán)隊，都會把“用戶第一”放置在相當(dāng)重要的地位。而對于PaaS產(chǎn)品經(jīng)理而言，這尤其重要，甚至到達(dá)了決定生死存亡的地步。本文將通過PaaS本身與PaaS產(chǎn)品崗的特性進(jìn)行介紹。
【資料圖】
一、產(chǎn)品的本身特性
1. 直面用戶是商業(yè)化的必然要求
PaaS屬于B端產(chǎn)品，其商業(yè)化的屬性天然流淌在產(chǎn)品血液里的。而幫助用戶提升業(yè)務(wù)指標(biāo)或達(dá)到降本增效的目的，并以此獲取相應(yīng)的報酬，是PaaS產(chǎn)品的基礎(chǔ)商業(yè)邏輯。
因此，想要真正把PaaS產(chǎn)品做好，用戶需要什么、用戶的痛點哪里、用戶的付費(fèi)意愿與付費(fèi)能力這些都需要產(chǎn)品經(jīng)理了然于心，僅靠開發(fā)提供技術(shù)方案是遠(yuǎn)遠(yuǎn)不夠的。
因為沒有直面用戶，我們就在一個產(chǎn)品定價問題上栽了跟頭。這是一個全新的產(chǎn)品模塊，其特性會導(dǎo)致產(chǎn)品的成本相較其他模塊在同等規(guī)模下會有大幅的提升，因此針對該模塊設(shè)置了獨(dú)立的付費(fèi)模式，同時為了防止體量過大，我們又增設(shè)了一個認(rèn)為僅用來兜底的全新收費(fèi)項。
而這一方案完全沒有與任何用戶溝通，也并未在一個用戶上預(yù)估，導(dǎo)致該計價方案一經(jīng)上線，在第一個用戶身上就翻車了。該用戶在使用了產(chǎn)品新模塊后，月賬單整整比之前高出了2000%，而實際觀測到的成本僅比上月增加了20%，結(jié)果也可想而知，用戶對于該月費(fèi)用金額并不認(rèn)可，我們也只能通過折扣、免額的方式快速修正賬單，不僅沒有提升收入，反而降低了用戶對我們的好感度和信任值。
如果我們可以更早一些的直面用戶，了解用戶對于新模塊的付費(fèi)意愿程度、了解用戶的使用場景，相信我們一定可以設(shè)計出更合適、準(zhǔn)確、高效獲客的定價機(jī)制。
另外，不論何時，產(chǎn)品經(jīng)理的介入可以讓用戶感受到重視，同時增加對產(chǎn)品和服務(wù)的好感度，在同質(zhì)化以及競爭如此激烈的當(dāng)下，真誠的確可以增加新客簽約、老客增值或續(xù)費(fèi)的成功率。
2. 只有直面用戶才能知道問題在哪
除了商業(yè)化，產(chǎn)品的功能、易用性也是PaaS產(chǎn)品的關(guān)鍵點。相較于SaaS，PaaS大大提升了產(chǎn)品多元化、定制化的能力，用戶只需考慮如何創(chuàng)建最佳用戶體驗即可。因此PaaS產(chǎn)品的用戶除了購買產(chǎn)品的“客戶”外、還有真正使用產(chǎn)品的開發(fā)者。
對于開發(fā)者而言，他的任務(wù)是對接PaaS平臺，并基于PaaS平臺的能力實現(xiàn)自身的產(chǎn)品需求。在對接過程中，最關(guān)心的無非兩個點：功能是否滿足、接入是否易用。這其中接入的易用性往往容易被人忽略，卻也往往成為產(chǎn)品成功的關(guān)鍵因素。
C端或SaaS產(chǎn)品是否易用往往體現(xiàn)在應(yīng)用界面、交互體驗上，而PaaS產(chǎn)品的易用重心主要在開發(fā)文檔與開發(fā)接口上。而接口則代表著工具本身的易用與否，接口的功能完善程度、個性化擴(kuò)展能力、多端統(tǒng)一方案甚至是代碼的簡潔優(yōu)雅性，決定著開發(fā)者接入時的易用程度；開發(fā)文檔就像是工具的說明書，是否簡單易懂又是否完整準(zhǔn)確，同樣是影響開發(fā)者接入的重要因素。
作為PaaS產(chǎn)品經(jīng)理，時常能聽到開發(fā)者對這兩項的吐槽和建議，而一般產(chǎn)品經(jīng)理并不會完全接手這兩部分的工作，往往由開發(fā)和文檔工程師提供相應(yīng)的內(nèi)容輸出，作為產(chǎn)品的領(lǐng)航者，產(chǎn)品經(jīng)理能做的就是直面客戶、直面真實場景下的產(chǎn)品使用效果。
在沒有直面用戶前，永遠(yuǎn)不會知道究竟是什么原因?qū)е麻_發(fā)者的吐槽。即便開發(fā)者用戶吐槽的內(nèi)容非常的具體（如多端接口不統(tǒng)一），產(chǎn)品經(jīng)理也同樣無法做到感同身受。但當(dāng)你真正與開發(fā)者進(jìn)行溝通甚至面對面看開發(fā)者敲代碼時，所有問題與壓力如沙塵暴一般負(fù)面而來。這時候你才知道原來接口不統(tǒng)一會給應(yīng)用開發(fā)帶去多大的麻煩；文檔介紹不清晰、場景功能文檔散落各地能讓人多抓狂；即便接口文檔沒有任何問題，產(chǎn)品概念的特殊性也會讓開發(fā)無從下手。
通過直面開發(fā)者用戶，可以了解到接口對齊的重要性，在后續(xù)需求迭代過程中增加接口一致性、技術(shù)方案統(tǒng)一評審的流程；可以了解到不同產(chǎn)品&場景下的使用情況、量級、頻控等，可基于場景輸出最佳實踐方案；可以了解到接入的開發(fā)者中大多不具備自主開發(fā)能力、大部分項目也沒有過多的時間與人力資源，在產(chǎn)品提供的形式上增加simple code、demo甚至uikit（組件式接入）的形式，提升產(chǎn)品的整體易用性
二、產(chǎn)品崗位的特性
前面一部分，講的都是PaaS產(chǎn)品本身特性引發(fā)的直面用戶的重要性，作為PaaS產(chǎn)品經(jīng)理，其本身工作的崗位也有不少特性是需要通過直面用戶而實現(xiàn)的。
1. 產(chǎn)品經(jīng)理負(fù)責(zé)的內(nèi)容決定著需要直面用戶
作為PaaS產(chǎn)品經(jīng)理，雖然不需要做很多原型設(shè)計的工作，但負(fù)責(zé)的全鏈路產(chǎn)品策劃并不比C端產(chǎn)品簡單。
從前期的價值評估、種子客戶尋找、產(chǎn)品設(shè)計、產(chǎn)品驗證、產(chǎn)品包裝、產(chǎn)品定價，到發(fā)布后的材料準(zhǔn)備、客戶對接、產(chǎn)品迭代，再到穩(wěn)步發(fā)展時的競品對比、用戶回訪、產(chǎn)品創(chuàng)新等等，每一步都需要產(chǎn)品經(jīng)理踩下夯實的腳步，而想要做到夯實，直面客戶是最基礎(chǔ)的。
在產(chǎn)品設(shè)計之初，同時也是產(chǎn)品的調(diào)研階段，直面用戶可以幫助產(chǎn)品經(jīng)理快速定位商業(yè)的價值點、定義MVP版本的需求范圍。火如釘釘，在創(chuàng)立之初直接派團(tuán)隊成員駐扎在種子用戶公司，觀察、體驗辦公流程等一些列直面行為完成MVP版本發(fā)布。
MVP版本上線后，是驗證產(chǎn)品核心價值的關(guān)鍵階段。在這一階段里，明確產(chǎn)品的下一步規(guī)劃進(jìn)展，包括產(chǎn)品功能的迭代、產(chǎn)品問題的修復(fù)、產(chǎn)品包裝的策略、新品定價等，基本包含了全鏈路的產(chǎn)品基礎(chǔ)要素。而這些都需要產(chǎn)品經(jīng)理直面種子用戶，并基于用戶的使用情況、反饋內(nèi)容以及付費(fèi)意愿等作出相應(yīng)的判斷。可以說，該階段的產(chǎn)品經(jīng)理除了本職工作外，還是新品的銷售、方案溝通師、售后對接人等等。
而在產(chǎn)品完成灰度或穩(wěn)步增長后，一旦有新用戶的接入或咨詢，產(chǎn)品經(jīng)理通過直面了解用戶場景，結(jié)合產(chǎn)品自身的特點主動給用戶提供相應(yīng)解決方案，也是產(chǎn)品成功獲客的關(guān)鍵一步。
2. 直面用戶指導(dǎo)產(chǎn)品設(shè)計
直面用戶可以幫助產(chǎn)品經(jīng)理快速、明確的了解用戶場景，減少因信息傳輸鏈路過長、前向成員表達(dá)錯誤等因素造成的信息不對齊、方案偏差。相信作為B端產(chǎn)品經(jīng)理，經(jīng)常能夠聽到一些來自客戶或前向的“指導(dǎo)”：我想要一個XXX的功能、客戶需要在這里加一個字段、那里的效果能不能改成XXX…..
這一類訴求往往是基于現(xiàn)狀或已有認(rèn)知提出的具體解決方案，至于這個方案是否能完全解決問題？作為PaaS平臺最看重的延展性，該方案是否對其他用戶適用？在產(chǎn)品經(jīng)理未做細(xì)致了解與分析前均無法判斷，如果這時候貿(mào)然接手并開發(fā)交付，不僅會浪費(fèi)人力、機(jī)器資源，甚至有丟失客戶的風(fēng)險。
以IM產(chǎn)品（即時通訊聊天）舉例，相信現(xiàn)在大家對于直播間的實時彈幕已經(jīng)習(xí)以為常了，其本質(zhì)就是多人互動聊天，若基于早期的IM產(chǎn)品提供支持，用戶會提出“我想要一個無上限的群聊功能”，但作為IM PaaS產(chǎn)品經(jīng)理，如果直接把需求做轉(zhuǎn)述并要求開發(fā)設(shè)計技術(shù)方案，那就真的成為了需求的傳聲筒，甚至連需求分析師都稱不上。
真正的做法應(yīng)該是了解直播彈幕的場景以及基于該場景下的特殊需求：當(dāng)前火爆的直播現(xiàn)狀，無論是購物直播還是秀場直播，觀看直播的人數(shù)往往可以突破百萬千萬，靠普通的群聊能力的確是完全無法支撐；但同時直播間往往沒有復(fù)雜的人員管理邏輯、進(jìn)入直播間的成員也不會有長期留存的打算，一旦直播結(jié)束或切換直播間就會離開，因此從產(chǎn)品形態(tài)上完全沒有必要用到復(fù)雜的群聊管理能力與群聊維護(hù)能力。有了對直播場景的深入了解后產(chǎn)品經(jīng)理就可以針對場景設(shè)計全新的輕盈的產(chǎn)品模式，既不需要做所謂“無上限群聊”的高難度需求，也可以通過產(chǎn)品經(jīng)理的能力去提升PaaS產(chǎn)品本身的競爭力。
3. 技術(shù)知識儲備逼迫產(chǎn)品經(jīng)理不得不直面用戶
如引言所說，在PaaS這類如此偏技術(shù)傾向性的領(lǐng)域里，產(chǎn)品經(jīng)理所占據(jù)的地位話語權(quán)往往高不到哪去。用戶想要在線上會議里使用十級美顏，開發(fā)說實現(xiàn)不了，產(chǎn)品瞬間沒招，只能忍痛拒絕客戶；用戶希望說希望一次同步可以獲得全量信息返回，開發(fā)說只能返回200個，產(chǎn)品仍然毫無辦法；開發(fā)者頻繁吐槽產(chǎn)品不好用，接入很麻煩，產(chǎn)品聽著確實一頭霧水，不知如何下筆。
其中，大部分的原因在于產(chǎn)品經(jīng)理的技術(shù)支持儲備有限，對于技術(shù)方案可干涉程度也沒有那么高，即便是原開發(fā)轉(zhuǎn)的產(chǎn)品，在一段時間不接觸代碼后對產(chǎn)品技術(shù)方案的熟悉程度也會逐漸下降。因此開發(fā)對產(chǎn)品在技術(shù)知識儲備維度的降維打擊在PaaS領(lǐng)域內(nèi)尤為顯著。
這也是作為PaaS產(chǎn)品更應(yīng)該直面用戶、接近用戶的一大原因，和開發(fā)正面硬剛研發(fā)能力毫無勝算、強(qiáng)迫通過技術(shù)方案（如200人群升級為百萬人群）既浪費(fèi)資源又體現(xiàn)不出價值，只有做到真正從用戶中來，到用戶中去，做到心中有用戶、腦中有場景、筆下有方案，才能真正坐穩(wěn)、坐好PaaS產(chǎn)品經(jīng)理之位。
本文由 @碌碌無為的阿栓 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載
題圖來自Unsplash，基于 CC0 協(xié)議
關(guān)鍵詞： 直面用戶 PaaS產(chǎn)品經(jīng)理的免死金牌和尚方寶劍
