|
|
PaaS产品的设计十分依赖于技术和开发的计划，因此PaaS产品经理经常对比主动，会堕入干燥且没有能源的窘境。那末，作为一个PaaS产品经理，又该如何体现本身的价值、做出用户喜欢的产品呢？
PaaS产品一般为以提供SDK和API的形式帮忙开发者疾速完成业务需要，而SDK和openAPI的设计又恰恰十分依赖技术才能与开发计划。也因如斯，PaaS产品经理的任务往往被吐槽为主动、干燥甚至传声筒，乃至有部份PaaS团队间接由开发担任人来牵设计落地。那末，作为一个PaaS产品经理，又该如何体现本身的价值、做出用户喜欢的产品呢？
直面用户，是一个解决问题的好谜底。置信一切的公司、一切的产品团队，都会把“用户第一”搁置在至关首要的位置。而关于PaaS产品经理而言，这尤为首要，乃至抵达了抉择生死存亡的境地。本文将经过PaaS自身与PaaS产品岗的特性进行引见。
一、产品的自身特性1. 直面用户是商业化的必定要求
PaaS属于B端产品，其商业化的属性自然流淌在产品血液里的。而帮忙用户晋升业务目标或达到降本增效的目的，并以此获得相应的人为，是PaaS产品的根底商业逻辑。
因此，想要真正把PaaS产品做好，用户需求甚么、用户的痛点哪里、用户的付费志愿与付费才能这些都需求产品经理了然于心，仅靠开发提供技术计划是远远不敷的。
由于没有直面用户，咱们就在一个产品定价问题上栽了跟头。这是一个全新的产品模块，其特性会致使产品的本钱相较其余模块在等同范围下会有大幅的晋升，因此针对该模块设置了独立的付费模式，同时为了避免体量过大，咱们又增设了一个以为仅用来兜底的全新免费项。
而这一计划彻底没有与任何用户沟通，也并未在一个用户上预估，致使该计价计划一经上线，在第一个用户身上就翻车了。该用户在使用了产品新模块后，月账单整整比以前高出了2000%，而实际观测到的本钱仅比上月减少了20%，后果也可想而知，用户关于该月费用金额其实不认可，咱们也只能经过折扣、免额的形式疾速修改账单，不只没有晋升支出，反而升高了用户对咱们的好感度和信赖值。
假如咱们能够更早一些的直面用户，理解用户关于新模块的付费志愿水平、理解用户的使用场景，置信咱们一定能够设计出更适合、精确、高效获客的定价机制。
此外，不管什么时候，产品经理的染指能够让用户感触到注重，同时减少对产品和办事的好感度，在同质化以及竞争如斯剧烈确当下，真挚确实能够减少新客签约、老客增值或续费的胜利率。
2. 只要直面用户能力知道问题在哪
除了商业化，产品的功用、易用性也是PaaS产品的症结点。相较于SaaS，PaaS大大晋升了产品多元化、定制化的才能，用户只需斟酌如何创立最好用户体验便可。因此PaaS产品的用户除了购买产品的“客户”外、还有真正使用产品的开发者。
关于开发者而言，他的工作是对接PaaS平台，并基于PaaS平台的才能完成本身的产品需要。在对接过程当中，最关怀的无非两个点：功用是不是知足、接入是不是易用。这其中接入的易用性往往容易被人疏忽，却也往往成为产品胜利的症结要素。
C端或SaaS产品是不是易用往往体当初运用界面、交互体验上，而PaaS产品的易用重心次要在开发文档与开发接口上。而接口则代表着工具自身的易用与否，接口的功用完美水平、共性化扩展才能、多端一致计划乃至是代码的简洁优雅性，抉择着开发者接入时的易用水平；开发文档就像是工具的仿单，是不是简略易懂又是不是残缺精确，一样是影响开发者接入的首要要素。
作为PaaS产品经理，时常能听到开发者对这两项的吐槽和倡议，而个别产品经理其实不会彻底接手这两部份的任务，往往由开发和文档工程师提供相应的内容输入，作为产品的领航者，产品经理能做的就是直面客户、直面实在场景下的产品使用成果。
在没有直面用户前，永久不会知道到底是甚么缘故致使开发者的吐槽。即使开发者用户吐槽的内容十分的详细（如多端接口不一致），产品经理也一样无奈做到感同身受。但当你真正与开发者进行沟通乃至面对面看开发者敲代码时，一切问题与压力如沙尘暴个别负面而来。这时候候你才知道原来接口不一致会给运用开发带去多大的费事；文档引见不明晰、场景功用文档散落各地能让人多抓狂；即使接口文档没有任何问题，产品概念的特殊性也会闪开发无从下手。
经过直面开发者用户，能够理解到接口对齐的首要性，在后续需要迭代过程当中减少接口统一性、技术计划一致评审的流程；能够理解到不同产品&场景下的使用状况、量级、频控等，可基于场景输入最好理论计划；能够理解到接入的开发者中大多不具备自主开发才能、大部份名目也没有过量的时间与人力资源，在产品提供的方式上减少simple code、demo乃至uikit（组件式接入）的方式，晋升产品的总体易用性
二、产品岗位的特性
后面一部份，讲的都是PaaS产品自身特性诱发的直面用户的首要性，作为PaaS产品经理，其自身任务的岗位也有不少特性是需求经过直面用户而完成的。
1. 产品经理担任的内容抉择着需求直面用户
作为PaaS产品经理，虽然不需求做得多原型设计的任务，但担任的全链路产品策动其实不比C端产品简略。
从后期的价值评价、种子客户寻觅、产品设计、产品验证、产品包装、产品定价，到公布后的资料筹备、客户对接、产品迭代，再到稳步开展时的竞品比较、用户回访、产品翻新等等，每一个步都需求产品经理踩下夯实的脚步，而想要做到夯实，直面客户是最根底的。
在产品设计之初，同时也是产品的调研阶段，直面用户能够帮忙产品经理疾速定位商业的价值点、定义MVP版本的需要规模。火如钉钉，在创建之初间接派团队成员驻扎在种子用户公司，视察、体验办公流程等一些列直面行动实现MVP版本公布。
MVP版本上线后，是验证产品中心价值的症结阶段。在这一阶段里，明白产品的下一步布局停顿，包罗产品功用的迭代、产品问题的修复、产品包装的战略、新品定价等，根本包孕了全链路的产品根底因素。而这些都需求产品经理直面种子用户，并基于用户的使用状况、反馈内容以及付费志愿等作出相应的判别。能够说，该阶段的产品经理除了本职任务外，仍是新品的销售、计划沟通师、售后对接人等等。 而在产品实现灰度或稳步增长后，一旦有新用户的接入或征询，产品经理经过直面理解用户场景，结合产品本身的特征被动给用户提供相应解决计划，也是产品胜利获客的症结一步。
2. 直面用户指点产品设计
直面用户能够帮忙产品经理疾速、明白的理解用户场景，增加因信息传输链途经长、前向成员表白过错等要素酿成的信息不合错误齐、计划偏差。置信作为B端产品经理，常常可以听到一些来自客户或前向的“指点”：我想要一个XXX的功用、客户需求在这里加一个字段、那里的成果能不克不及改为XXX…..
这一类诉求往往是基于现状或已有认知提出的详细解决计划，至于这个计划是不是能彻底解决问题？作为PaaS平台最看重的延展性，该计划是不是对其余用户合用？在产品经理未做粗疏理解与剖析前均无奈判别，假如这时候候冒然接手并开发交付，不只会挥霍人力、机器资源，乃至有丧失客户的危险。
以IM产品（即时通信聊天）举例，置信当初大家关于直播间的实时弹幕曾经司空见惯了，其实质就是多人互动聊天，若基于初期的IM产品提供反对，用户会提出“我想要一个无尚限的群聊功用”，但作为IM PaaS产品经理，假如间接把需要做转述并要求开发设计技术计划，那就真的成了需要的传声筒，乃至连需要剖析师都称不上。
真实的做法应该是理解直播弹幕的场景以及基于该场景下的特殊需要：以后火爆的直播现状，无论是购物直播仍是秀场直播，观看直播的人数往往能够冲破百万千万，靠普通的群聊才能确实是彻底无奈撑持；但同时直播间往往没有繁杂的人员办理逻辑、进入直播间的成员也不会有长时间留存的打算，一旦直播完结或切换直播间就会分开，因此从产品状态上彻底没有须要用到繁杂的群聊办理才能与群聊保护才能。有了对直播场景的深化理解后产品经理就能针对场景设计全新的轻快的产品模式，既不需求做所谓“无尚限群聊”的高难度需要，也能够经过产品经理的才能去晋升PaaS产品自身的竞争力。
3. 技术常识贮备欺压产品经理不能不直面用户
如引言所说，在PaaS这种如斯偏技术偏向性的畛域里，产品经理所占领的位置话语权往往高不到哪去。用户想要在线上会议里使用十级美颜，开发说完成不了，产品瞬间没招，只能忍痛回绝客户；用户但愿说但愿一次同步能够获取全量信息前往，开发说只能前往200个，产品依然毫无方法；开发者频繁吐槽产品欠好用，接入很费事，产品听着的确一头雾水，不知如何下笔。
其中，大部份的缘故在于产品经理的技术反对贮备无限，关于技术计划可干预水平也没有那末高，即使是原开发转的产品，在一段时间不接触代码后对产品技术计划的相熟水平也会逐步降落。因此开发对产品在技术常识贮备维度的降维打击在PaaS畛域内尤其明显。
这也是作为PaaS产品更应该直面用户、接近用户的一大缘故，和开发侧面硬刚研发才能毫无胜算、强制经过技术计划（如200人群降级为百万人群）既挥霍资源又体现不出价值，只要做到真正从用户中来，到用户中去，做到心中有用户、脑中有场景、笔下无方案，能力真正坐稳、坐好PaaS产品经理之位。
本文由 @无所作为的阿栓 原创公布于人人都是产品经理，未经许可，阻止转载
题图来自Unsplash，基于 CC0 协定
该文观念仅代表作者自己，人人都是产品经理平台仅提供信息存储空间办事。 |
|
中级会员