編輯導語：産品經理行業可以細分為多個崗位，例如數據産品經理、PaaS産品經理等，相信不少人對PaaS産品經理崗位的内容、職責都不是特别明晰。本篇文章裡，作者就PaaS産品這個崗位内容做了詳細解讀，一起來看一下。

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

IaaS主要就是指雲計算的基礎設施如服務器、雲存儲等，SaaS則是提供完整能力的标準化應用産品，如企業微信、有贊商城等。

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

如去年爆火的clubhouse，其底層的音視頻能力就是使用的國内知名RTC廠商聲網，clubhouse團隊本身隻需要關注語聊房内的産品邏輯、UI界面、交互等應用功能；比如智聯招聘的HR與應聘者的文字溝通，其底層的IM即時通訊能力就是使用的網易雲信的IM SDK。

從産品内容看，PaaS産品往往提供的是源代碼、API接口等技術内容與技術邏輯方案，而大部分非技術出身的産品經理，對于這一類技術内容往往也很難有很深刻的理解和認知。

也因此，在很多PaaS廠商中，産品經理并不能像C端産品經理一樣占據主導權，有時甚至做着做着就變成了一個傳聲筒。

看上去PaaS産品對于産品經理而言，還是一個較為遙遠的知識盲區，那麼究竟産品經理該怎麼做PaaS産品的策劃呢？

一、PaaS産品的本質

首先我們需要給PaaS産品一個定義：純B端産品。

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

所以商業的考量就是PaaS産品策劃的第一步，首先需要知道自己的目标客戶是誰，給客戶解決了什麼問題（所謂的需求就是有需要、且有解決方法）。

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

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

同一個客戶可能會有不同的能力需求，同一種能力也可以提供給不同行業的客戶。由此可見PaaS産品具有非常強的包容性和擴展性，找準自身産品的目标場景、目标客戶是PaaS産品經理首先需要定義的。

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

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

二、PaaS産品的需求管理

目标客戶和需求來源明确完後，需求管理成為了PaaS産品經理工作中非常重要的一環。對于PaaS而言，需求往往分為兩部分：産品能力、産品易用性。

其中産品能力包含PaaS産品可以實現的功能有哪些，比如IM SDK能夠支持點對點的私信也可以支持多人群聊，這些都是産品功能；還包含性能指标有多高，如IM SDK内群聊能夠支持百人級别還是千人級别還是萬人級别？一條消息發出是否能保證百分百必達？多久能收到？延遲有多少？

産品易用性是指客戶接入過程中是否方便，是否可以保證在能力實現的基礎上快速接入。

因為PaaS本身是一個開發程序包或API接口，因此使用者多為程序員，不同的行業、不同的産品規模、不同的技能儲備都會影響客戶接入的整體流程。

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

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

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

三、PaaS産品的需求策劃

PaaS産品的需求文檔在主體方向上與其他産品并無二緻，但其展現的形式卻大有不同。

首先PaaS産品一般是不需要原型圖的，隻需要把需求通過文字表達清楚即可。

其次部分PaaS産品需求文檔會存在開發級别的接口内容（包括接口調用邏輯、接口名稱、接口限制等），這也就意味說産品經理不僅需要對産品需求有完善的準備與輸出，對于技術内容、性能指标也需要有明确的說明。

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

當然了，PaaS産品終究也隻是芸芸衆生的一種産品類型，需求文檔還是需要回歸産品。

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

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

PaaS産品還有一個很大的特點是覆蓋面廣，一個即時通訊能力可以用在娛樂社交的陌生人一對一聊天内、可以用在購物直播間的彈幕裡、也可以用在企業協同的組織群内，不同的行業都可以是PaaS功能的使用方，因此在設計需求時一定要考慮需求的使用範圍、可複用性，可覆蓋全行業的需求往往是優先級最高也最複雜的需求。

四、PaaS産品的推廣

需求文檔搞定了，評審也通過了，看上去産品的工作告一段落了，然而PaaS産品經理的工作其實才剛剛進行到一半。

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

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

那麼當産品有輸出後，産品經理往往需要同步輸出信息給到團隊的所有人。如提供給銷售、售前解決方案人員以産品的報價、優勢兩點，與市場部門做前期的推廣策略溝通，以及給技術支持部門做相應的培訓。

隻有把所有的這些事情做完，PaaS産品策劃整流程才算真正的跑完。最後附錄一份PaaS大廠内部的需求文檔模闆，僅供參考~

五、附錄：PaaS産品的文檔模闆

1. 需求概述

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

2. 背景介紹

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

3. 價值描述

解決的問題、滿足的場景訴求，對自身的産品價值。

4. 需求詳情

1. 需求目标：清晰描述需求的目标。
2. 産品方案：清楚描述産品場景，方案，功能設計、數據埋點設計、向下兼容設計、價格方案設計等。

5. 需求驗收标準

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

6. 競品對比

1. 競品方案：調研競品的功能方案、使用流程。
2. 競品價格：調研競品的價格設計、收費模式。
3. 競品差異對比：對比與競品的差異，當前的産品優勢。

本文由 @碌碌無為的阿栓 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部