别被增长曲线骗了:70%的初创企业死于“过早扩张”的数据幻觉

CIOAge
许多团队将扩张误认为成功的标志,但在产品和系统未充分就绪时盲目扩张,会导致架构崩溃、运营压力和团队疲惫。指标应作为镜子而非奖杯,金字塔化管理运营、行为和结果指标,避免被虚荣或代理指标误导。

“扩张”常被误认为是成功的标志,表明某事物行之有效,但实际上,增长不仅会给路线图带来压力,还会给架构、数据层、事件响应系统以及团队在负载下的运营能力带来压力。在早期阶段,那些看似“足够好”的服务水平协议(SLA)、服务水平目标(SLO)和延迟预算,在新的并发和流量模式下开始崩溃。我曾见过,健康的指标掩盖了脆弱的系统,直到某次功能发布导致一切崩溃。

• 过早扩张——在没有对齐指标和运营弹性的情况下——仍是产品失败的首要原因。

• 指标只有在基于特定情境时才有意义,而非借用基准。

• 工程就绪情况(DORA指标、错误预算、SLO)必须与产品增长同步发展,否则在负载下将面临失败风险。

过去十年里,我目睹过许多有前途的团队因追求虚荣指标而精疲力竭,也见证过产品因过早扩展而崩溃。事实上,70%的初创企业失败是因为他们在产品和平台真正准备好之前就试图增长。真正的挑战不在于如何更快增长,而在于如何在不使系统崩溃的情况下实现增长。这需要指标、产品成熟度和工程弹性之间的协调一致。

我学到的最早的一课是:指标不是奖杯,而是镜子。曾经,我们一味追求单一数字,如月活跃用户数,这让我们得到了令人印象深刻的图表,但业务却很薄弱。我们是在扩展虚荣,而非价值。如今,我不再关注通用的KPI,而是专注于4-6个特定于产品的指标——注册转化率、获客成本(CAC)、日活跃用户(DAU)与月活跃用户(MAU)之比、首次关键行动率、特定行动的留存率——这些指标反映了价值如何在系统中实际流动。指标应引导我们形成认知,而不仅仅是验证成功。正如古德哈特定律提醒我们的那样:一旦一个衡量标准成为目标,它就不再是一个好的衡量标准。

人们开始操纵数字,或以牺牲真实结果为代价对其进行优化。一个臭名昭著的例子是富国银行的销售丑闻——管理层沉迷于一个指标(每位客户的账户数量),并设定了如此激进的目标,以至于员工开始开设数百万个虚假账户,只是为了达到目标。这个指标在纸面上看起来很棒,但它破坏了客户信任,并导致了数十亿美元的罚款。教训是:不要让任何一个单一指标成为虚假的偶像。以更平衡的方式定义成功,这种成功要反映你为产品和用户创造的真实价值。

基准作为护栏

基准是有用的,但只有当它们被视为参考点而非命令时才有用,它们有助于发现异常情况(比如,异常低的转化率),但它们并不意味着要定义你的产品应该取得怎样的成功。早期,我犯了一个错误,将我们的“第二章”与别人的“第十章”进行比较。我看到另一家SaaS公司炫耀其第1天的留存率为50%,就惊慌失措,因为我们只有30%,却没有考虑到我们正在解决不同的问题,处于不同的发展阶段,拥有不同的用户群体。

这就是团队最终在自己不擅长的领域竞争的原因。每个产品都存在于自己的情境中——时机、预算、团队成熟度、市场复杂性。基准可以提供信息,但绝不应主导决策。将它们视为金科玉律可能会造成一种危险的客观性错觉,导致你忽视自己的实际限制,或追求那些从一开始就不属于你的指标。

在实践中,我使用基准的方式就像使用天气预报一样:它们告诉我应该期待什么样的条件,但并不决定路线。真正的工作是了解哪些指标真正反映了产品的价值,然后围绕这一点调整系统的其他部分。

运营就绪情况

无论指标看起来多么有前景,没有工程就绪情况的产品扩展就像在松软的地面上建造房屋。增长会给运营系统带来压力——部署管道、可观测性工具、延迟预算和发布节奏都会在实时中受到压力测试。这就是为什么我们将DORA指标(如部署频率和变更失败率)视为扩展能力的早期指标,而不仅仅是工程KPI。

在加大增长循环之前,我们会问:我们的事件响应流程是否具有弹性?我们是否制定了错误预算,并且是否得到遵守?性能退化是否能在早期足够明显地显现出来,以防止客户感到痛苦?

扩展不仅仅是为了获取更多用户,而是为了在不破坏信任或稳定性的情况下处理他们。技术债务可能不会阻碍你的下一次发布,但它会在压力下加剧。从这个意义上说,基础设施和平台健康状况是产品决策——因为它们决定了当增长真正到来时,你能以多快和多安全的速度前进。

但指标失败的原因不仅仅是因为基础设施糟糕,还因为我们如何解读它们。

数据质量管控

在任何重要的“结果审查”会议或增长更新之前,我的团队都知道我会宣布一个数据质量管控,这并不光鲜亮丽,但却至关重要。我们验证关键事件是否被正确跟踪,命名是否一致,漏斗是否反映了实际用户流程。这个习惯是在我们庆祝一次入职人数激增后形成的——后来才发现,这是由一个错误的事件过早触发导致的。那次事件让我明白了糟糕数据的代价:它创造了虚假的信心,并误导了决策。糟糕的数据创造了虚假的信心,而虚假的信心是所有错误中最昂贵的。

我现在对待指标质量管控就像对待修复关键软件错误一样认真,这不仅仅是我的怪癖,而是有更广泛的证据支持。调查显示,58%的商业领袖声称,关键决策往往基于不准确或不一致的数据。想象一下,超过一半的公司可能都在基于错误的数字下注,或者至少是不稳定的数字。从长远来看,数据质量不佳的成本是巨大的:Gartner的一项研究显示,数据质量不佳平均每年给组织造成1500万美元的损失。干净的指标不仅仅是技术卫生,它们是一种风险管理形式。在庆祝进步之前,请确保你的测量系统没有说谎。

警惕代理指标,增长的“盲点”

并非所有增长的数字都意味着你正在获胜。事实上,有些指标可能在显著增长的同时,掩盖了实际价值的停滞或下降。我将这些指标称为代理指标(有时也称为“盲目指标”),它们是那些给你成功错觉,而你的核心价值主张却在衰退的数字。典型的例子:应用程序下载量可能飙升,但活跃使用量可能持平。或者你网站上的页面浏览量可能很高(可能是由于点击诱饵营销),但转化为付费客户的比例仍然很低。在这种情况下,我们常常对指标视而不见:我们看到图表上升,但没有质疑它真正意味着什么。

为了保持脚踏实地,我用一个简单的层次结构来组织指标——某种意义上的指标金字塔。底层是运营指标(你可以直接控制或影响的日常数字:例如,销售电话数量、解决的错误或营销支出)。中间是行为或产品指标(这些指标显示用户行为和参与度:例如,日活跃用户、使用时间、功能采用率——它们由你的运营产生,但并不完全受你控制)。

顶层是结果指标,它们捕捉最终目标或“为什么”——通常是像收入、客户留存率或客户满意度等反映交付价值的事物。这个金字塔确保我们将战术指标与战略结果联系起来,这与许多团队使用的北极星框架类似,在这个框架中,一个顶级的指标由几个关键驱动因素支持,而这些驱动因素之下又有一大堆细粒度的指标。事实上,产品管理指南建议使用指标金字塔来提高清晰度:在顶层,你有一个北极星结果,在中间,是与你要采取的影响该结果的行动相关的指标,在底层,是帮助解决问题和指导决策的更精细的数据点。

当我看到“月度会话数”这样的指标上升时,我会强迫自己问:这是一个结果还是只是一个产出?如果会话数与结果(比如更高的收入或更好的留存率)相关联,那么更多的会话数可能意味着成功,但它也可能是一个代理指标——也许用户因为用户界面(UI)的改变而更频繁地打开应用程序,但并没有获得更多价值。通过金字塔结构来思考,我们提醒自己,底层的上升并不保证顶层的移动。

“产品-市场契合度”的神话

在初创企业的传说中,很少有概念比产品-市场契合度(PMF)更受推崇——那是万事万物都契合的神奇时刻:用户热爱产品,增长激增,你感觉自己已经“成功了”,但我对将PMF视为一次性的顿悟越来越持怀疑态度。实际上,契合度是一个移动的目标——一个持续的过程,而非一个里程碑。早期的吸引力并不能保证长期的契合度。客户需求会变化,竞争对手会回应,昨天的契合度可能明天就不适用了。这就是为什么我将PMF视为持续的校准,而非终点线。

因此,我不再追求一个神话般的时刻,而是关注趋势和轨迹。我不会宣称“我们已经有了PMF”,而是问:我们仍然在为真实的人解决实际问题吗——而且我们做得比替代方案更好吗?能够持续发展的团队不会只找到一次契合度——他们会不断改进它。

在快节奏的产品周期中,很容易从一个项目跳到另一个项目,而不停下来,但我已经养成了一个习惯,即在每次重大发布或增长实验后,我们都会举行一次反思会议。在这次会议上,我们问三个问题:

• 我们衡量了正确的事情吗?

• 哪些指标真正给了我们清晰的认识,哪些最终误导了我们或让我们视而不见?

• 我们的哪些增长假设被现实证明是错误的?

我注意到,接受这种反思实践的团队随着时间的推移会变得更加数据敏锐。指标不再是一张计分卡或大棒,而变成了一盏手电筒——照亮前进的道路。

最后的思考

如果有一条主题将所有这些教训联系在一起,那就是在增长中保持意识的重要性。框架和策略——北极星指标、增长循环、病毒系数、目标与关键成果法(OKR)——所有这些都是有用的工具,但只有在具备自我意识和情境意识的情况下才能发挥作用。我经常告诉自己和我的团队:当数字说一件事,而你的情境(你的直觉、用户研究、市场信号)说另一件事时,相信情境。

增长是结果,而非策略。如果我能给年轻时的自己一些建议,那就是:不要追逐趋势线,要追求理解。讽刺的是,当你真正了解你的用户和你的价值时,增长往往会自然而然地随之而来——而且它会更健康、更可持续。

责任编辑:姜华 来源: 企业网D1Net
相关推荐

2022-07-29 14:31:18

隐私计算

2025-11-03 02:45:00

2021-08-04 11:22:38

SaaS无代码平台云计算

2019-03-14 08:26:43

无线路由器WiFi网络

2015-07-08 17:39:10

公有云数据中心IT基础设施支出

2024-02-21 21:16:15

2020-07-03 16:58:19

人工智能AI初创企业

2025-08-11 09:07:00

2017-10-25 20:18:59

云计算数据初创公司

2015-08-26 10:46:16

大数据

2015-08-06 12:56:06

初创企业CEO谎言

2022-09-20 18:27:31

Kubernetes云服务

2013-07-09 10:14:01

初创企业创业企业融资

2014-01-13 09:35:13

创业企业

2024-09-21 11:35:40

2020-10-14 10:04:52

首席数据官首席信息官数据

2015-12-23 11:54:39

初创企业安全公司

2021-05-07 07:31:33

数据分析互联网运营大数据

2022-10-14 11:55:29

2021-09-14 10:01:39

云计算初创公司谷歌

51CTO技术栈公众号