朴素产品法（上）

朴素产品法（上）

作者介绍

@完结

游走B端尝试toC产品人；

寻找复杂问题简单化处理思路方式；

“数据人创作者联盟”成员。

朴素产品，只做现阶段需要的内容，能少则省，只传达有效信息，不附带干扰。

产品设计规划时经常会面临诸如“功能完整与拆分迭代，缩短路径与加层跳转，简洁排布与充分利用”之间的矛盾，而这系列矛盾也不是简单的非此即彼，相互关联而又相互制衡。

拆分迭代更有利于产品验证，而产品的最终目标还是演化至趋于完整，只是阶段不同，追求完整还不算是一个最主要的内容；减少操作次数，缩短行为路径是一个至关重要的设计理念，但也需要兼顾页面内容元素，一个页面只传递一个核心信息，一个页面只有一个视觉焦点，在秉承这一核心要求的前提下，有时增多层级跳转反而是一个更合理的选择；页面简洁不等于简单、元素少，而是传递信息的直接有效，更需要考虑的是用户在页面所保留的注意力，在保持有高注意力的页面一次性展示更多内容，更有利于增强产品可用性，提高使用效率。

产品设计规划时常就是一个进退两难，不断抉择的复杂过程，需要时刻秉承着追求“朴素”的心态，适可而止，效用为先。

01 朴素功能选型

“如无必要，勿增实体”，简单有效原理。大多数情况下我们也都知道要注意保持简单易用，而经常遇到的是一开始就已经将问题复杂化，容易只从充分性的角度来考虑，导致忽略了需求的必要性，也就很可能导致需求蔓延和镀金需求的增多。过于追求“细枝末节”，过于执着“用户体验”，有时更需要保持“有限理性”，适可而止。确定阶段性功能，定义功能方向及阶段系统边界，形成阶段性聚焦，适当放弃部分现阶段暂时还无需关注的内容。

1.1 定义最需解决问题

用户所面临的问题大多数情况下都是多方面的，期待的解决方案也可能是最理想化的，此时需要寻找出最需解决的问题，集中力量资源解决核心问题，更高效精准地取得用户满意。如果解决了这个问题，用户的处境就会有最大程度的改变，这就是用户现阶段最需解决的问题。同时考虑哪些限制条件会影响到用户的流程环节过渡，是否存在可保留的旧体验，从而确定当前版本的系统功能边界。拆分出终级效果和阶段性目标，可降低问题处理复杂度。

案例：对于线下门店优惠券派发线上化，目的是想通过电子化更便捷地派发，分析衡量出不同优惠券的具体效果，更科学地实现降本增效。面对这一目标我们很容易一开始就陷入如何精准地做出效果评估，“推送-曝光-查看-使用”等环节的流程转化，通过费效比分析得出哪种券类型、券组合表现更优，但这在一定程度上只是弥补了线下记录操作繁琐，数据记录不全的的缺陷，是在维持原有或改变不大的派发效果基础上进行的分析，侧重于事后的后见性分析。

1.2 寻找最简解决方案

在明确了现阶段最需解决的问题之后，依然会面临诸多不确定因素，需实行最小可行产品形态推进验证，寻找最简解决方案，减少投入成本的沉没流失，加快产品的落地使用、市场占有。

简化产品方案思考框架

1）不做这一步会有什么后果？

2）如果不这么做都是怎么做？

3）别人没按照你的意思去做，反而采用了其他方式，会有什么效果？

4）如果按照所说的去做了，效果不好，大概率是哪个环节出了问题？

（借用自《得到品控手册7.0》得到主编采访课程专栏老师完善内容质量的问题技巧框架）

案例：对于线上商超便利店平台初期推广阶段，重点在于验证平台是否能拥有预期用户流量，需快速招揽店家入驻完成验证。商品上架作为线上开店不可或缺的功能，涉及扫码识别、规格价格设置、商品分类管理、商品描述等多个方面，且不同子模块间相互关联难以精减，如果初期压根就没有商品上架功能呢？

1）不做这一步会有什么后果？

店家不可手动自主上架商品，全部调用平台商品库商品，店家仅可售卖常见商品，非常见非标商品暂不支持售卖。店家上架自家特有商品是为能体现出自家商品种类齐全，与周边商家的差异化，提供配送上门服务更好服务于周边客户。

· 对于前期阶段，一定区域内不会出现太多的试点店家，商品的差异化竞争因素可暂不考虑；

· 尽管商品没有上架完全，但对于以服务老客为主的零售便利店而言（主要推广方式以客户到店后再向其介绍线上订单服务），前期客户如有其它需求，可在订单中进行备注说明，尽管会造成销售库存数据不同步，但小需求商品可先由人工校对调整。

2）如果不这么做都是怎么做？

平台商品库商品需要足够常见，适用于大多数店铺，在挑选种子样板店时需考虑经营业态、在售商品相似度较大的店铺，使能够涵盖店家的大多数商品，对于销量不大的长尾商品进行适当压缩，对于存在太多需要计量的非标商品店家可暂不考虑。

3）别人没按照你的意思去做，反而采用了其他方式，会有什么效果？

新平台初期为吸引店家，基本都是免费邀请或补贴入驻，而对商家而言是获得了一个新的订单来源途径，有胜于无。重点在于不能有太大的入驻门槛，店家不愿意为一个不确定的销售渠道投入太多精力资源。上架商品对店家而言就是一个繁琐的大工程，除非对平台有足够的引流信任，否则不会轻易就有商品上架意愿。在前期平台还无法取得店家信任时，降低门槛就变得至关重要，从这一方面来看直接商品库上架反而更有利于推广。

4）如果按照所说的去做了，效果不好，大概率是哪个环节出了问题？

假设按照以上做法推进，也可能因为该方案引出一些新的问题导致引流转化效果不理想、流量验证不准确。例如商品品类不够丰富、商品描述不准确、采用全平台统一但同一商品在不同店家间会存在质量差别等，需要有预留地进行调研验证。

小结

寻找最简解决方案目的在于以最低成本尽快测试想法，关键是验证需求是否有普遍性，能否引起用户共鸣，需要验证的风险是“用户会来我们平台上下单吗”而不是“我们如何做出一个线上下单平台”。明确哪些旧体验可以在初代版本中保留，哪些流程操作可以先由人工替代，采用专人接待式服务模式等。

追求简单的另一方面还在于避免因为某一功能的投入而引发出了其他新的关联需求。做不做一个功能，除了考虑现在所需花费的成本资源，还需要考虑可能激发出来的新需求，避免打开“潘多拉魔盒”必须持续投入资源不停增加。

1.3 兼顾拓展迁移成本

早期系统除了考虑简化产品解决方案外，还需要兼顾后续拓展可能性，可拓展一方面是保持系统底层结构的可复用，避免重构，另一方面是避免由于拓展造成过大的迁移成本导致用户流失。

案例：针对客户标签体系，前期就需要能够对标签数量级有一个预估，是否需要一开始就支持创建标签组，前期系统刚投入使用，不支持分组管理对用户不会有太大影响。但到了后期随着标签数量的增多，标签管理、查找就会变得繁琐，此时就会要求对标签进行分组。如果前期未能考虑到该扩展的可能性，此时再增加分组功能，就会导致整个标签的数据表结构发生较大变动，用户已创建的标签需手动迁移至新创建分组内，额外操作的工作量太大会让用户产生抗拒心理，即使很清楚分组后后续使用会更加方便，但过大的操作压力可能会导致用户犹豫不决，最终选择放弃使用系统。

1.4 分支下钻延伸迭代

完成核心验证，明晰了产品大体方向，后续演化迭代就是一个又一个“构建-衡量-学习”循环的过程。迭代重点在于只聚焦于核心模块的下钻延伸，不致于产品边界过于模糊扩散导致功能越积越多，但对产品价值没有太多实质性的提升。

爬山算法，增加高度/值方向上的连续移动，以找到山峰或最佳解决方案的方法。这一模型多运用于算法工程，但也同样适用于产品的迭代思路，分支下钻、精益求精，而不是去创建更多的分支。通过一点点改变某个变量，改动之后如果得到更好的解决方案，就再从这一新方案中再选择一个变量进行小幅改变，不断反复，直到解决方案无法进一步优化为止。优化一个指标获得的成效越来越小，就意味着达到了一个基准点，再去优化下一个重要指标。

1.5 小结

不只是产品从0到1要秉承最小可行原则，追求朴素，在任何时期的迭代落地都要遵从该理念，如无必要，勿增实体，保持有限理性，在一个更小、更容易触及的目标市场、特定场景中持续培养更多具有黏性的高活跃用户。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。