产品小感

以前觉得做产品，就是解决一个问题，把这个问题拆分成一堆需求，需求、功能之间不论有无相关性，其代码实现凑在一起了，代码量变庞大之后，量变到质变，就成为了一个真正意义上的大产品。

这样的想法比较幼稚，产品并不是单一要素的产物，毕竟除了技术实现外，它往往包含了一系列的调研、设计、策略、抉择，除了肉眼可见的代码，背后还有很多不为人知的细节、理念、历史。如果看产品只从技术角度来看，从实现的难易来衡量，是本末倒置的。产品生而解决问题，首先要发现问题，其次是找到解决方案，最后一步才是代码实现。可能在日常中接触到产品的形态更多是一个可用的实体软件程序，而不是一行行代码，代码实现上的神秘会催生这种代码唯上的片面思维，嗯，要戒掉。

PM的工作是技术含量的，可能平时我们看啥产品发布会，产品布道者会在公众场合发表定性的观点，它具有概括性、逻辑演绎和思辨色彩，他说一个产品怎么怎么好，是听他描绘的画面，是靠人自己去感受，当然这种【可感觉出来的好】，一般是产品真的好，才会给人这样的感受。对于PM，产品分析不是一个定性的任务，而是要定量的，好与不好，用户不一定在感官上体会到，而在数据下就能发先指标正向还是负向（不能直接用数字刻划的，还可以做访谈，做横向对比等）。这种正向在若干的迭代的update之后会被慢慢放大，最后大众可能突然觉得【哇，这产品是真的好】，特别是长久不升级的用户，从旧版突然更新到新版，一个跳板级的新体验，是 critical hit。

很多时候产品也会憋大招，比如apple每年更新一次的macOS或者iOS系统，每次更新总会使人眼前一亮，这里牵扯到操作系统层面的更新，有点庞大；可以看看微信的更新频率，以月甚至双月为单位，每次都会掀起一阵小高潮，这种更新频率是在于这个产品已经被认可并且难以替代的前提下才会有的，正如张小龙说每天有上1亿人教他做产品，反过来反映了微信的不可或缺。

技术壁垒是产品护城河，应用生态也是产品护城河，点子是产品生命力。

为什么强调提高交付效率，完善质量保障体系，这就是在建立自己的技术壁垒，技术壁垒除了在代码实现难度上比别人高使得别人抄不了外，还可以通过交付效率、质量保障进行压制。想想看，同样的功能，我比你提前三天发布，我就先赢得了一大批用户，赢在了起跑线；同样的功能，我的产品做出来bug free，你的产品就各种闪退发烫耗电烧流量，高下立判。

至于应用生态，那就是产品布局，从小的角度来说，我们希望把app里探索验证后反响好的功能拆分出来孵化成一个独立app，一部分原因是抢夺下沉市场份额，因为单一产品一直做下去就会有产品的惯性，也就出现了枷锁，新点子不一定适合在当前产品框架上做，比如资讯类的头条app去做小说阅读器。这种时候，会在原先app上试验这个点子，如果ok，就把功能抽离出来做成一个app，新app可以脱离原有产品框架形态、交互模式、代码实现的束缚，去走它自己的风格，做好深度用户体验；另一部分原因也是丰富应用生态，从大的角度来说，以小米为例子，雷军除了做手机，还要贴牌家电，整得像个杂货铺一样，但是假如一个用户真的用上了小米全套，那他脱离这个生态的成本将会非常大以至于在可以忍受的前提下依然苟在里面不肯出来，因为生态与生态之间互不兼容（不知未来会不会继续各家割裂）。

好产品有它自己的短期中期长期规划，细到单个迭代要做什么功能，然后中期要给一个什么会心一击的大招，再到长期产品彻底完善后我希望它及周边是一个什么样子，用户习惯是如何如何。这还是一个目标往下拆分的过程，所做的一切最终都是为了更靠近目标。字节跳动，群众喜欢叫它app工厂，这样的称呼听起来似乎公司就是app流水线，快速看结果、快速试错、快速占领市场。这样的风格更贴切当前的社会节奏，人们每天接触这么多产品，经历有限的情况下如何在竞品中脱颖而出，靠的是求变。反过来看，技术人也应该求变，技术更新迭代，我们要跟上步伐，掌握核心原理的前提下多方拓展，打出竞争力来！