有个现象值得注意：有些公司产品还不完善，但越推越好；有些公司产品功能很全，但推一家死一家。
差别在哪里？
前者在不完善但稳定的状态下推，后者在功能全但不稳的状态下推。
推得越快，死得越快——这句话不是反对拓展，是在说：产品不稳的时候硬推，是在加速自杀。
不完善和不稳定，是两回事
这是大多数公司搞混的第一件事。
不完善，意思是功能还不全，覆盖的场景不多。这很正常，没有什么产品一开始就是完整的。不完善可以靠快速迭代解决——先跑通核心场景，推给客户，收集反馈，下个版本补上。从用户中来到用户中去，这是最快的产品进化路径。
不稳定，意思是产品在客户真实环境里跑起来会出问题。蓝屏、卡顿、数据丢失、关键时刻掉链子——这些是质量问题，不是功能问题。
前者客户可以等，后者客户不能忍。
所以结论很清楚：产品不完善没问题，放心推；产品不稳定，千万别推。
稳不稳定，有两个判断标准
很多人觉得"稳"是个模糊感觉，其实有两个很具体的判断标准。
第一个：能不能跑通客户的最小闭环场景？
客户买你的产品，是为了完成某件具体的事。这件事从头到尾能不能跑通，就是最小闭环。比如客户用你的产品，核心需求就是那几件事——能正常启动、正常干活、数据不丢，这三件事能跑通，其他功能可以慢慢补。
如果最小闭环都跑不通，功能做得再多也没用。
第二个：在客户真实环境里能不能稳定运行？
不是演示环境里稳不稳，是在客户那边的网络、那边的硬件、那边的使用习惯下，稳不稳。
两个标准都满足，才算稳。可以推。
大多数公司的产品规划，站位错了
这是最隐蔽的问题，也是"产品不稳还硬推"的根本原因。
很多公司的产品规划是这么做的：研发说这个季度能做哪几个功能，排进路线图，按时发布。
问题是：客户最小闭环场景里还缺什么，不在这个优先考虑范围内。
客户提了需求，销售回去反馈，产品说"这个不在本季度规划里，后面再考虑"。然后客户转头找了竞争对手。
更严重的是——产品稳定性问题的优先级，还低于既定规划。 新功能要按时发布，稳定性问题"后面修"——但这个"后面"，客户等不了。
你按自己容易做的节奏在发布产品，不是在按客户需求在规划产品。这两个出发点，结局完全不同。
推得越快，死得越快
把前面说的串在一起，就是这个系列压轴要说的核心：
产品不稳的时候，每多推一家，就是在多制造一个负口碑。
负口碑的可怕之处在于，它传播的速度远比正面口碑快。你花了三个月拿下二十家客户，每家都出问题，这二十家会变成二十个负面传播源，在行业里传开。
后来产品稳定了，再想回去找这些客户——门都没有。他们不仅自己不用，还劝同行别用。
你要花十倍的成本，才能挽回一个因为产品不稳而失去的客户——如果还能挽回的话。
正确做法是什么
说回来，不是不让推，是要在"稳"的前提下推。
产品规划要以市场上的真实应用场景为输入，不是以研发觉得什么好做为导向。
客户最小闭环场景里缺的东西，优先级必须最高。稳定性问题，优先级必须最高。其他的，可以排后面。
功能可以少，但跑起来的那部分必须稳。
不完善，可以边做边改；不稳定，一次就能把牌子砸了。
EMOS方法论：产品稳定性是L0信任底座的核心——信任一旦破坏，L1-L5所有机制都无力回天。产品规划应来自市场输入端（L5的I层），不是研发输出端。
