做产品这行的有个说法叫产品宿命论，就是说一款产品从它的诞生，它的命运就基本确定了。我是挺相信这种说法的，如果用产品的定位角度来看，所谓的宿命就是根据产品的定位而画出的产品边界。这事儿好像玄而又玄的很难说清楚，我从前隐隐约约觉得是企业的基因决定了产品的命运，比如有媒体基因的新浪微博，比如文艺气息浓到化不开的豆瓣。但是这样太形而上了，不能给人任何指导意义。直到最近看了纯银的10连发，从讲述自身产品来说明什么是产品模型，讲的特别好，自己做死的几款产品分析的有理有据，毫不吝啬的把自己的经验分享给大家，有种金庸小说里大侠的风范，侠之大者为国为民。
试着用产品模型的方式分析下曾经负责的APP产品，供大家讨论，一起思考，虽然只当了一年的后爹，还是希望这个产品好。PS:听云APP是款APM类产品（Application Performance Management）.
纯银提出的产品模型 = 商业模式+产品架构+运营体系
商业模式：听云APP是典型的工具类产品，赚钱分为两边，一边是销售主动去推销产品，把客户忽悠住拿钱回来，一边是saas平台的用户自己用这个产品，用爽了主动付费。
因为这款产品是以SDK的形式嵌入在客户的APP中采集各种数据，分析整理展示出来，帮助客户解决问题，这也就意味着有海量的数据需要处理和存储，云服务的成本较高，而且是随着业务扩展不断提高。
虽然不像to C的产品，需要去思考变现方式，但是天朝saas平台用户付费意愿低这是个普遍的现象。低到什么程度，低到赚钱分两边，一边可以忽略的程度。原因有很多，其中一条比较重要的是使用产品的saas核心用户并不是真正能决定是否掏钱的人。所以公司绝大部分收入都是各区销售跑一个个公司，签一个个单子赚回来的。
从商业模式上看，更像是一个传统的软件公司。
产品架构：是指产品设计上的框架与核心系统。直接上图，信息架构的草稿
听云APP报表信息架构
产品的核心系统其实是对APP性能数据的全面采集、整理、展示。
产品的信息架构设计方面没有难度，只要按照树形的逻辑结构，以功能为节点展开就可以。
对于一个工具类产品最重要的其实是它的稳定和高效，重中之重是研发是否给力，是否有强有力的技术团队保证抓取信息准确、稳定、高效，比如都是抓crash，我抓的又全又准性能消耗又少，你抓的总是漏两条，这就是差距。
其次是产品的健壮性和可用性。健壮性是如何在面对复杂的客户使用场景和需求时，设计出可行的业务逻辑；可用性说起来就长了，这部分以前写过“为什么大部分关于可用性的争论都是在浪费时间”，感兴趣的可以搜下。
运营体系：运营主要分为三个部分，内容运营、用户运营、推广运营。根据APM类产品的特性，重点其实是用户运营这方面。因为在大数据上来之前，内容没有运营的必要。而主要的收入来自于销售的前提下，推广运营也是事倍功半半半的，因为考核推广运营的KPI一般都是数量和质量，质量指的就是付费用户的转化率，在saas平台用户一年的收入还不够公司买水果的情况下，我只能对运营的同学表示深深的同情。
用户运营的重点和难点是如何提供持久而优质的服务。优质的服务包括使用初期的嵌码跟进、辅导、帮助；使用过程中的问题解答；在当前客户产品生命周期结束后对新产品的推进。这里的矛盾在于优质的服务和人力成本。
结论：产品的商业模式简单粗暴且有效，但是收入的增长在较长时间内（1~2年）根本指不上saas平台，这不是saas平台的问题，而是整个APM市场的问题。在已支持行业知名企业全覆盖之前，如果要增加收入，根据商业模式的分析，最直接的就是增加强有力的销售团队。
产品架构方面，远没有触及的产品的天花板，天地广阔大有可为，行业方面：直播、游戏、甚至VR/AR，功能方面：性能与用户行为分析的结合。但是产品可用性的坑太多了，走一步一崴脚的程度，这也直接导致了用户运营的难度和成本的激增（包括技术支持），
用户运营的重点和难点是如何提供持久而优质的服务，这个就不重复了。
其实我觉得最重要的是高层的决断，所谓的专注、极致没有明确的目标和资源倾斜就。。。。
虽然离开了，我还是爱这个产品的，今天只做产品模型分析，别的就不说了，欢迎对模型进行讨论。就这样，晚安。
网友评论