編輯導語：產(chǎn)品經(jīng)理行業(yè)可以細分為多個崗位，例如數(shù)據(jù)產(chǎn)品經(jīng)理、PaaS產(chǎn)品經(jīng)理等，相信不少人對PaaS產(chǎn)品經(jīng)理崗位的內(nèi)容、職責都不是特別明晰。本篇文章里，作者就PaaS產(chǎn)品這個崗位內(nèi)容做了詳細解讀，一起來看一下。

PaaS是平臺即服務的縮寫。他是一種云計算模型，云計算的三種模型分別是PaaS，SaaS（軟件即服務）和IaaS（基礎架構即服務）。

IaaS主要就是指云計算的基礎設施如服務器、云存儲等，SaaS則是提供完整能力的標準化應用產(chǎn)品，如企業(yè)微信、有贊商城等。

而PaaS則是基于這兩類產(chǎn)品之間，他既不提供基礎的設施，也不提供現(xiàn)成的產(chǎn)品，PaaS多提供SDK、API等代碼包或接口，好像一個工具箱，通過它，APP不需要關心基礎能力的實現(xiàn)，只需要關注純粹的業(yè)務產(chǎn)品的功能。

如去年爆火的clubhouse，其底層的音視頻能力就是使用的國內(nèi)知名RTC廠商聲網(wǎng)，clubhouse團隊本身只需要關注語聊房內(nèi)的產(chǎn)品邏輯、UI界面、交互等應用功能；比如智聯(lián)招聘的HR與應聘者的文字溝通，其底層的IM即時通訊能力就是使用的網(wǎng)易云信的IM SDK。

從產(chǎn)品內(nèi)容看，PaaS產(chǎn)品往往提供的是源代碼、API接口等技術內(nèi)容與技術邏輯方案，而大部分非技術出身的產(chǎn)品經(jīng)理，對于這一類技術內(nèi)容往往也很難有很深刻的理解和認知。

也因此，在很多PaaS廠商中，產(chǎn)品經(jīng)理并不能像C端產(chǎn)品經(jīng)理一樣占據(jù)主導權，有時甚至做著做著就變成了一個傳聲筒。

看上去PaaS產(chǎn)品對于產(chǎn)品經(jīng)理而言，還是一個較為遙遠的知識盲區(qū)，那么究竟產(chǎn)品經(jīng)理該怎么做PaaS產(chǎn)品的策劃呢？

一、PaaS產(chǎn)品的本質(zhì)

首先我們需要給PaaS產(chǎn)品一個定義：純B端產(chǎn)品。

這個定義非常重要，相較于C端產(chǎn)品更關注的用戶量、日活等使用行為數(shù)據(jù)，B端產(chǎn)品經(jīng)理往往更注重商業(yè)成功。能不能賣的出去，能賣出去多少，能賣多少錢，這些都是大部分B端產(chǎn)品經(jīng)理都需要考慮的。

所以商業(yè)的考量就是PaaS產(chǎn)品策劃的第一步，首先需要知道自己的目標客戶是誰，給客戶解決了什么問題（所謂的需求就是有需要、且有解決方法）。

作為B端中的B端，PaaS的客戶多為企業(yè)或團隊，為業(yè)務實現(xiàn)所需而對外采購，需求的來源有可能是自己沒有能力實現(xiàn)，也可能是沒有人力滿足短期內(nèi)上線的要求。

而不同的PaaS產(chǎn)品往往擁有不同場景的客戶訴求，如聲網(wǎng)提供底層實時音視頻能力可以給到多行業(yè)的客戶（企業(yè)內(nèi)部的線上會議、娛樂社交的多人語聊房等）、高德地圖對外提供標準的API接口給到有定位、導航等訴求的客戶（如本地生活類的門店信息App、比如即時通訊產(chǎn)品的位置消息體）。

同一個客戶可能會有不同的能力需求，同一種能力也可以提供給不同行業(yè)的客戶。由此可見PaaS產(chǎn)品具有非常強的包容性和擴展性，找準自身產(chǎn)品的目標場景、目標客戶是PaaS產(chǎn)品經(jīng)理首先需要定義的。

當然，PaaS產(chǎn)品也會有一定的范圍局限，初創(chuàng)的團隊受限于資金、前景問題并不會在前期就選擇付費接入外部供應商；產(chǎn)品初期階段沒有大量用戶、前期團隊內(nèi)部技術能力可以完全支撐的大概率也不會選擇PaaS產(chǎn)品；特別大的公司因自身開發(fā)團隊完備、技術能力強并不需要外部供應商的支持，而高日活、高用量的產(chǎn)品若采購外部能力往往需要支付高額的費用，久而久之也會逐漸轉(zhuǎn)為自研支持。

因此PaaS產(chǎn)品的客戶多為中長尾客戶，在做PaaS產(chǎn)品策劃時也需要更多的針對中長尾客戶去做通用化設計。

二、PaaS產(chǎn)品的需求管理

目標客戶和需求來源明確完后，需求管理成為了PaaS產(chǎn)品經(jīng)理工作中非常重要的一環(huán)。對于PaaS而言，需求往往分為兩部分：產(chǎn)品能力、產(chǎn)品易用性。

其中產(chǎn)品能力包含PaaS產(chǎn)品可以實現(xiàn)的功能有哪些，比如IM SDK能夠支持點對點的私信也可以支持多人群聊，這些都是產(chǎn)品功能；還包含性能指標有多高，如IM SDK內(nèi)群聊能夠支持百人級別還是千人級別還是萬人級別？一條消息發(fā)出是否能保證百分百必達？多久能收到？延遲有多少？

產(chǎn)品易用性是指客戶接入過程中是否方便，是否可以保證在能力實現(xiàn)的基礎上快速接入。

因為PaaS本身是一個開發(fā)程序包或API接口，因此使用者多為程序員，不同的行業(yè)、不同的產(chǎn)品規(guī)模、不同的技能儲備都會影響客戶接入的整體流程。

易用性的需求在大部分時間內(nèi)不如產(chǎn)品功能或性能的需求優(yōu)先級高，但也是PaaS產(chǎn)品開發(fā)過程中不可或缺的一部分，如不同端的實現(xiàn)方式是否相同？功能底層邏輯設計的接口是否合理？因此PaaS產(chǎn)品在做版本期間一定需要組織一次技術評審，對齊服務端與客戶端、客戶端各端之間的技術方案是否對齊、接口是否合理。

此外，有別于C端產(chǎn)品里流傳的“我教張小龍做微信”笑談，PaaS產(chǎn)品的客戶需求甚至可以成為PaaS產(chǎn)品的生命線：PaaS的特性一定程度上限制了產(chǎn)品的發(fā)展方向與速度，PaaS產(chǎn)品存在的第一目的是幫助客戶實現(xiàn)業(yè)務訴求，這也導致了PaaS產(chǎn)品需要跟著客戶走而不是依靠純粹的市場分析或天才型的想法進行策劃，存在一定的落后性。

同時客戶的訴求有時候往往會帶給PaaS產(chǎn)品新的市場或商機，因此篩選客戶需求就變得尤為重要。

三、PaaS產(chǎn)品的需求策劃

PaaS產(chǎn)品的需求文檔在主體方向上與其他產(chǎn)品并無二致，但其展現(xiàn)的形式卻大有不同。

首先PaaS產(chǎn)品一般是不需要原型圖的，只需要把需求通過文字表達清楚即可。

其次部分PaaS產(chǎn)品需求文檔會存在開發(fā)級別的接口內(nèi)容（包括接口調(diào)用邏輯、接口名稱、接口限制等），這也就意味說產(chǎn)品經(jīng)理不僅需要對產(chǎn)品需求有完善的準備與輸出，對于技術內(nèi)容、性能指標也需要有明確的說明。

最后一點就是文章開頭所說PaaS產(chǎn)品同樣需要策劃關于產(chǎn)品售賣相關的配套能力，如何對外露出能力、收費策略如何、如何計算等，配套能力不僅有后臺的產(chǎn)品需求，也會有對外推廣售賣的商業(yè)需求。

當然了，PaaS產(chǎn)品終究也只是蕓蕓眾生的一種產(chǎn)品類型，需求文檔還是需要回歸產(chǎn)品。

PaaS產(chǎn)品需求文檔最重要的三件事：場景、多場景、很多場景。所有需求都源自場景，只有真正應用在場景中了，我們才能說這個需求是合格的。

PaaS產(chǎn)品需求同樣如此，在講需求前先把場景想明白，這個需求在什么場景下使用？怎么使用？除了這個場景還有沒有其他場景可以使用？把場景想清楚以后，需求的功能點、性能指標、邊界值等也就出來一大半了。否則就只是盲人摸象，毫無頭緒，開發(fā)隨口的靈魂拷問就會被打的體無完膚。

PaaS產(chǎn)品還有一個很大的特點是覆蓋面廣，一個即時通訊能力可以用在娛樂社交的陌生人一對一聊天內(nèi)、可以用在購物直播間的彈幕里、也可以用在企業(yè)協(xié)同的組織群內(nèi)，不同的行業(yè)都可以是PaaS功能的使用方，因此在設計需求時一定要考慮需求的使用范圍、可復用性，可覆蓋全行業(yè)的需求往往是優(yōu)先級最高也最復雜的需求。

四、PaaS產(chǎn)品的推廣

需求文檔搞定了，評審也通過了，看上去產(chǎn)品的工作告一段落了，然而PaaS產(chǎn)品經(jīng)理的工作其實才剛剛進行到一半。

如上所說，作為深度B端產(chǎn)品，PaaS產(chǎn)品經(jīng)理不僅要負責把產(chǎn)品生出來，還需要負責把產(chǎn)品推出去。除了基礎的產(chǎn)品策劃能力外，產(chǎn)品經(jīng)理與前向銷售部門的溝通、市場的溝通甚至是客戶的溝通都需要做到得心應手。當產(chǎn)品投入開發(fā)后，產(chǎn)品經(jīng)理需要同步（甚至可以更早）考慮產(chǎn)品的推廣問題。

都說產(chǎn)品經(jīng)理是各個部門之間的橋梁，我想PaaS產(chǎn)品經(jīng)理一定是最忙碌的橋梁。因為PaaS產(chǎn)品的復雜性，其團隊的組成往往比較龐大，除了基礎的產(chǎn)研測團隊外，還會有售前解決方案、售后技術支持、銷售商務經(jīng)理等。

那么當產(chǎn)品有輸出后，產(chǎn)品經(jīng)理往往需要同步輸出信息給到團隊的所有人。如提供給銷售、售前解決方案人員以產(chǎn)品的報價、優(yōu)勢兩點，與市場部門做前期的推廣策略溝通，以及給技術支持部門做相應的培訓。

只有把所有的這些事情做完，PaaS產(chǎn)品策劃整流程才算真正的跑完。最后附錄一份PaaS大廠內(nèi)部的需求文檔模板，僅供參考~

五、附錄：PaaS產(chǎn)品的文檔模板

1. 需求概述

需求描述：一句話描述需求。

2. 背景介紹

需求的直接來源與背景介紹。

3. 價值描述

解決的問題、滿足的場景訴求，對自身的產(chǎn)品價值。

4. 需求詳情

1. 需求目標：清晰描述需求的目標。
2. 產(chǎn)品方案：清楚描述產(chǎn)品場景，方案，功能設計、數(shù)據(jù)埋點設計、向下兼容設計、價格方案設計等。

5. 需求驗收標準

描述能夠通過驗收、上線的標準。

6. 競品對比

1. 競品方案：調(diào)研競品的功能方案、使用流程。
2. 競品價格：調(diào)研競品的價格設計、收費模式。
3. 競品差異對比：對比與競品的差異，當前的產(chǎn)品優(yōu)勢。

本文由 @碌碌無為的阿栓 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于 CC0 協(xié)議