一、创业公司的产品问题诊断

近期接触了数家E轮创业公司，赛道模式均不一样，但共同问题都是：业务要增长，资源却因为各种原因无法扩大，如何做？

创业公司想尽办法定位瓶颈，寻找内外解决方案。

然而，自诊出来的“问题”，往往是不需要解决的问题：

一、因为解决的成本过高。很多创业公司都没有成本概念，产品、项目没有预算管理，开发运维运营的成云帆学社本结构不清楚，到E轮才发现业务越做越亏。比如创业公司A，产品是大厂商整体解决方案的一部分，实施却涉及面广，客户需求零散、周期拉得很长，希望与外部公司协同来解决，但一算成本，根本不会有人来接手。

二、因为解决的价值过低。我经常纠正产品设计中的一个概念，用户价值。用户价值不是产品设计者认为的“产品给用户带来的价值”，而是“用户给公司带来的价值”，前者叫“用户需求的满足程度”，即产品功能。

比如创业公司B，处于中小用户市场，用户价值已经很低，即使开发更多的产品功能，也很难创造更多的用户营收。创业公司的自诊，犹如路灯下找钥匙，局限于认知，并非朝着真正的目标！

如何定位“真正的问题”？一种简单的方式是应用问题云帆学社链，分析创业公司是如何一步一步“来到”这个问题的。

二、业务战略：市场、客户和价值

1. 市场现状决定了产品成本

E轮不仅意味着创业公司业务模式开始成熟，也意味着市场渗透率开始提升。这时候痛点往往不在研发，而在市场：

对已经有应用基础的用户来说，存在现有产品的替代成本；对没有应用基础的用户来说，存在现有环境切换、升级的启动成本。

两种情况下，创业公司的直接感受是：产品销售和实施的成本太高了。然后采取非黑即白的策略：要么为了利润，不做；要么为了营收，不计成本地做。

如何帮助创业公司进行问题链分析？

产品销售实施成本高—>客户转换成本高—>客户支付意愿不足以覆盖总成本—>产品总价值低于客户支付价格—>产品市场不云帆学社匹配。

因此，问题可能出现在：

没有定义出正确的用户；没有定义出正确的用户价值；没有定义出正确的产品价值主张。

我们来看看根据需求特征的市场划分方式。

如上图所示，创业公司的业务处于主流市场，还是小众市场？越接近于大众使用、高辨识度的需求，处于主流市场，特点：用户能够清楚地描述自身的需求，并已经有了解决措施。

但是否存在市场的关键在于：用户是否对现状不满。如果用户已经满足于现有解决方案，那他就不再属于顾客，如果主流市场上的用户都差不多已经满足，那市场就并不存在了，需要转而检查是否还存在小众市场。

上图也揭示了两种市场上均存在研发之外的额外成本。创业公司需要进一步确认：

客户如何定义问题被解决？客户为解决完整云帆学社问题愿意支付的费用？

从而，正确制定产品的完整价值主张，并确定成本结构：

2. 用户需求决定了产品价值

上述第二个痛点，客户的启动成本，并非创业公司的问题，而是创业公司的盲点：需要把用户的现状到目标的差距，转换为用户的需求。

资本市场热捧开源，使得很多创业公司或通过开源，或推出相关书籍，来预热市场，提升用户的需要（needs）。

但产品销量最终不取决于用户的需要，而取决于用户的支付能力。从宏观环境来看，当下的企业支付能力普遍下降了，因此，创业公司需要：

提升产品总价值，将更多的欲望（wants）转换为需求（demands）。

尤其是已经大量进入采购过程的产品，被内部评估流程否决的产品，应该重点思考产品价值，云帆学社而非扩大市场认知，因为客户采购的信号已经表明：市场进入成熟期，创业公司要快速识别和满足客户的全部需求。

三、战略实施：内部资源和流程

C轮之前，创业公司集中精力在产品打磨，部分管理组织问题已经出现，但并不被重视：

事实上，成功的公司一开始就在产品、架构、组织上设计出优秀的资源利用模型，比如Instagram利用云计算架构，早期9个人的团队支撑起了3000万用户和$10亿市值。

1. 资源成本

C端产品可用每千用户成本进行衡量，B端产品适用于客户成本分布，最终转换为创业公司的资源成本结构，以评估资源利用率。

建议在C轮阶段，创业公司就开始建立完善的产品/项目导向的管理会计制度，可以委托第三方财务公司按年或半云帆学社年制定报表。

2. 流程体系

技术公司的完整体系应包括组织、流程和系统，据观察，传统企业更擅长优化流程提升组织效率，而技术公司更擅长优化系统来提升运营效率。‍‍‍

技术公司变动组织结构的成本非常高，因为涉及到系统业务知识的移交。

看不见的成本：曾经对一支需求负荷极重的200人团队进行咨询调研，该团队需求积压按工作量评估，高达一年，换句话说，新进需求如果按照先进先出排期，需要一年后才能排期交付。

通过访谈，我发现团队的需求交接时间特别长，并且大量出现反复交接。进一步调查发现，该团队实行项目资源池管理，如果某个项目成员超过一定时间空载，就会进入资源池重新分配项目，往往这个空载时间就出现在需求交接期；BA将云帆学社需求完成第一轮讲解后，再找客户澄清，第二轮发现项目组的人已经变了，提出了更多新问题，再次澄清，回来发现又有一些人变了……最后接收需求的质量理解程度很差，完成的程度更可想而知。仅通过将组织结构调整为固定的特性团队，由BA之间协商需求工作量的分配，而不是重新调整成员所属的组，就将资源利用率（减少空载）提升了15%以上。

另一个常见的盲区是，技术公司往往欠缺跨部门的协同流程，以及覆盖整个公司运营的流程体系。因此，我们看到不少公司学习华为，具体去看他们在学什么，发现学的就是管理控制体系，通过流程把公司的业务活动、决策和资源全部连接起来。