PaaS产品的设计非常依赖于技术和开发的方案，因此PaaS产品经理常常比较被动，会陷入枯燥且没有动力的困境。那么，作为一个PaaS产品经理，又该如何体现自身的价值、做出用户喜爱的产品呢？
PaaS产品通常是以提供SDK和API的方式帮助开发者快速实现业务需求，而SDK和openAPI的设计又偏偏非常依赖技术能力与开发方案。也因如此，PaaS产品经理的工作往往被吐槽为被动、枯燥乃至传声筒，甚至有部分PaaS团队直接由开发负责人来牵设计落地。那么，作为一个PaaS产品经理，又该如何体现自身的价值、做出用户喜爱的产品呢？
直面用户，是一个解决问题的好答案。相信所有的公司、所有的产品团队，都会把“用户第一”放置在相当重要的地位。而对于PaaS产品经理而言，这尤其重要，甚至到达了决定生死存亡的地步。本文将通过PaaS本身与PaaS产品岗的特性进行介绍。
PaaS属于B端产品，其商业化的属性天然流淌在产品血液里的。而帮助用户提升业务指标或达到降本增效的目的，并以此获取相应的报酬，是PaaS产品的基础商业逻辑。
因此，想要真正把PaaS产品做好，用户需要什么、用户的痛点哪里、用户的付费意愿与付费能力这些都需要产品经理了然于心，仅靠开发提供技术方案是远远不够的。
因为没有直面用户，我们就在一个产品定价问题上栽了跟头。这是一个全新的产品模块，其特性会导致产品的成本相较其他模块在同等规模下会有大幅的提升，因此针对该模块设置了独立的付费模式，同时为了防止体量过大，我们又增设了一个认为仅用来兜底的全新收费项。
而这一方案完全没有与任何用户沟通，也并未在一个用户上预估，导致该计价方案一经上线，在第一个用户身上就翻车了。该用户在使用了产品新模块后，月账单整整比之前高出了2000%，而实际观测到的成本仅比上月增加了20%，结果也可想而知，用户对于该月费用金额并不认可，我们也只能通过折扣、免额的方式快速修正账单，不仅没有提升收入，反而降低了用户对我们的好感度和信任值。
如果我们可以更早一些的直面用户，了解用户对于新模块的付费意愿程度、了解用户的使用场景，相信我们一定可以设计出更合适、准确、高效获客的定价机制。
另外，不论何时，产品经理的介入可以让用户感受到重视，同时增加对产品和服务的好感度，在同质化以及竞争如此激烈的当下，真诚的确可以增加新客签约、老客增值或续费的成功率。
除了商业化，产品的功能、易用性也是PaaS产品的关键点。相较于SaaS，PaaS大大提升了产品多元化、定制化的能力，用户只需考虑如何创建最佳用户体验即可。因此PaaS产品的用户除了购买产品的“客户”外、还有真正使用产品的开发者。
对于开发者而言，他的任务是对接PaaS平台，并基于PaaS平台的能力实现自身的产品需求。在对接过程中，最关心的无非两个点：功能是否满足、接入是否易用。这其中接入的易用性往往容易被人忽略，却也往往成为产品成功的关键因素。
C端或SaaS产品是否易用往往体现在应用界面、交互体验上，而PaaS产品的易用重心主要在开发文档与开发接口上。而接口则代表着工具本身的易用与否，接口的功能完善程度、个性化扩展能力、多端统一方案甚至是代码的简洁优雅性，决定着开发者接入时的易用程度；开发文档就像是工具的说明书，是否简单易懂又是否完整准确，同样是影响开发者接入的重要因素。
作为PaaS产品经理，时常能听到开发者对这两项的吐槽和建议，而一般产品经理并不会完全接手这两部分的工作，往往由开发和文档工程师提供相应的内容输出，作为产品的领航者，产品经理能做的就是直面客户、直面真实场景下的产品使用效果。
在没有直面用户前，永远不会知道究竟是什么原因导致开发者的吐槽。即便开发者用户吐槽的内容非常的具体（如多端接口不统一），产品经理也同样无法做到感同身受。但当你真正与开发者进行沟通甚至面对面看开发者敲代码时，所有问题与压力如沙尘暴一般负面而来。这时候你才知道原来接口不统一会给应用开发带去多大的麻烦；文档介绍不清晰、场景功能文档散落各地能让人多抓狂；即便接口文档没有任何问题，产品概念的特殊性也会让开发无从下手。
通过直面开发者用户，可以了解到接口对齐的重要性，在后续需求迭代过程中增加接口一致性、技术方案统一评审的流程；可以了解到不同产品&场景下的使用情况、量级、频控等，可基于场景输出最佳实践方案；可以了解到接入的开发者中大多不具备自主开发能力、大部分项目也没有过多的时间与人力资源，在产品提供的形式上增加simple code、demo甚至uikit（组件式接入）的形式，提升产品的整体易用性
前面一部分，讲的都是PaaS产品本身特性引发的直面用户的重要性，作为PaaS产品经理，其本身工作的岗位也有不少特性是需要通过直面用户而实现的。
作为PaaS产品经理，虽然不需要做很多原型设计的工作，但负责的全链路产品策划并不比C端产品简单。
从前期的价值评估、种子客户寻找、产品设计、产品验证、产品包装、产品定价，到发布后的材料准备、客户对接、产品迭代，再到稳步发展时的竞品对比、用户回访、产品创新等等，每一步都需要产品经理踩下夯实的脚步，而想要做到夯实，直面客户是最基础的。
在产品设计之初，同时也是产品的调研阶段，直面用户可以帮助产品经理快速定位商业的价值点、定义MVP版本的需求范围。火如钉钉，在创立之初直接派团队成员驻扎在种子用户公司，观察、体验办公流程等一些列直面行为完成MVP版本发布。
MVP版本上线后，是验证产品核心价值的关键阶段。在这一阶段里，明确产品的下一步规划进展，包括产品功能的迭代、产品问题的修复、产品包装的策略、新品定价等，基本包含了全链路的产品基础要素。而这些都需要产品经理直面种子用户，并基于用户的使用情况、反馈内容以及付费意愿等作出相应的判断。可以说，该阶段的产品经理除了本职工作外，还是新品的销售、方案沟通师、售后对接人等等。
而在产品完成灰度或稳步增长后，一旦有新用户的接入或咨询，产品经理通过直面了解用户场景，结合产品自身的特点主动给用户提供相应解决方案，也是产品成功获客的关键一步。
直面用户可以帮助产品经理快速、明确的了解用户场景，减少因信息传输链路过长、前向成员表达错误等因素造成的信息不对齐、方案偏差。相信作为B端产品经理，经常能够听到一些来自客户或前向的“指导”：我想要一个XXX的功能、客户需要在这里加一个字段、那里的效果能不能改成XXX…..
这一类诉求往往是基于现状或已有认知提出的具体解决方案，至于这个方案是否能完全解决问题？作为PaaS平台最看重的延展性，该方案是否对其他用户适用？在产品经理未做细致了解与分析前均无法判断，如果这时候贸然接手并开发交付，不仅会浪费人力、机器资源，甚至有丢失客户的风险。
以IM产品（即时通讯聊天）举例，相信现在大家对于直播间的实时弹幕已经习以为常了，其本质就是多人互动聊天，若基于早期的IM产品提供支持，用户会提出“我想要一个无上限的群聊功能”，但作为IM PaaS产品经理，如果直接把需求做转述并要求开发设计技术方案，那就真的成为了需求的传声筒，甚至连需求分析师都称不上。
真正的做法应该是了解直播弹幕的场景以及基于该场景下的特殊需求：当前火爆的直播现状，无论是购物直播还是秀场直播，观看直播的人数往往可以突破百万千万，靠普通的群聊能力的确是完全无法支撑；但同时直播间往往没有复杂的人员管理逻辑、进入直播间的成员也不会有长期留存的打算，一旦直播结束或切换直播间就会离开，因此从产品形态上完全没有必要用到复杂的群聊管理能力与群聊维护能力。有了对直播场景的深入了解后产品经理就可以针对场景设计全新的轻盈的产品模式，既不需要做所谓“无上限群聊”的高难度需求，也可以通过产品经理的能力去提升PaaS产品本身的竞争力。
如引言所说，在PaaS这类如此偏技术倾向性的领域里，产品经理所占据的地位话语权往往高不到哪去。用户想要在线上会议里使用十级美颜，开发说实现不了，产品瞬间没招，只能忍痛拒绝客户；用户希望说希望一次同步可以获得全量信息返回，开发说只能返回200个，产品仍然毫无办法；开发者频繁吐槽产品不好用，接入很麻烦，产品听着确实一头雾水，不知如何下笔。
其中，大部分的原因在于产品经理的技术支持储备有限，对于技术方案可干涉程度也没有那么高，即便是原开发转的产品，在一段时间不接触代码后对产品技术方案的熟悉程度也会逐渐下降。因此开发对产品在技术知识储备维度的降维打击在PaaS领域内尤为显著。
这也是作为PaaS产品更应该直面用户、接近用户的一大原因，和开发正面硬刚研发能力毫无胜算、强迫通过技术方案（如200人群升级为百万人群）既浪费资源又体现不出价值，只有做到真正从用户中来，到用户中去，做到心中有用户、脑中有场景、笔下有方案，才能真正坐稳、坐好PaaS产品经理之位。
本文由 @碌碌无为的阿栓 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。