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