编辑导语：产品经理行业可以细分为多个岗位，例如数据产品经理、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 协议