解决方案

从问题出发，而不是从服务出发。

多数人描述的是症状而不是类别——问题真正所属的领域，往往不是表面看起来的那个。这些是最常见的情形。

“广告投入在涨，客户数量没涨”
预算上去了，报表里的转化也跟着上去了，但银行账户跟两者都对不上。
增长
通常的真正原因
- 转化跟踪把不是客户的东西也算了进去
- 广告系列结构把钱花在了最不赚钱的产品上
- 落地页的转化率远低于流量应得的水平
- 在当前产品与价格下市场确实已经饱和
先核实测量，再看结构，再看转化漏斗。只有确认每一环都可靠，才增加预算——在任何一个问题之上加大投放，放大的是问题而不是收入。
“团队花在行政事务上的时间比正事还多”
信息被重复录入，审批在聊天里流转，报表每个月都靠手工拼出来。
构建规模化
通常的真正原因
- 系统之间互不相通
- 一张电子表格悄悄成了唯一的数据来源
- 流程长出了没人去删的多余步骤
- 软件是按小好几号的企业规模选的
在提出任何软件方案之前，先梳理信息从哪里进来、在哪里卡住。第一步往往是删掉步骤，而不是把它们自动化。
“需求增长的速度超过了我们的服务能力”
销售在涨，交付在拖，服务质量正在为增长买单。
规模化构建
通常的真正原因
- 产能规划还停留在更小的运营规模上
- 决策仍然要经过一两个人
- 手工流程只适应一半的业务量
- 在撞上瓶颈之前完全看不见它
找到真正的约束——它很少在表面上看起来的位置——然后先建立运营余量，再去增加需求。
“没人说得清一个客户到底花了多少钱”
平台报表、分析工具和财务账目各给出一个数字，于是每个扩张决策都成了拍脑袋。
增长构建
通常的真正原因
- 转化跟踪从未与真实收入核对过
- 归因在渠道之间重复计数
- 线下转化从未回流到数据里
- 对什么算作客户没有统一定义
端到端重建测量体系，并与企业实际入账核对。下游的一切都取决于这件事做对。
“我们要推出新东西，却不知道先后顺序”
品牌、网站、系统、人手、营销——似乎都得同时到位，而预算无法同时覆盖所有这些。
规模化构建增长
通常的真正原因
- 还没验证核心假设就先做完整版
- 还没有可卖的东西就先花钱做门面
- 没有一条端到端定义清楚的首个客户路径
- 顺序由让人兴奋的事决定，而不是由卡住的事决定
确定真正能验证假设的最小版本，界定第一天必须存在的与第六个月才需要的，然后按此安排支出顺序。
“网站看着不错，却什么都不产出”
流量来了，人走了，网站从未被当作一件商业工具来对待。
构建增长
通常的真正原因
- 几秒钟内看不出这家企业做什么、为谁服务
- 没有明显的下一步，或者互相竞争的下一步太多
- 手机上慢到一部分访客根本没看到页面
- 流量带着页面回应不了的意图而来
依据真实行为而非观点做诊断，然后按信息、结构、速度的顺序修复。改版往往不是答案。