一篇讲清楚：C 端与 B 端产品的“三要素”框架

很多人做产品时会陷入“我把功能做得更好，就会自然增长”的幻觉。但不论 C 端还是 B 端，真正决定产品能否规模化的，都不是某个单点能力，而是一个“乘法结构”：关键要素必须同时成立，任何一项接近 0，整体结果就会坍塌。

所以，我总结了，C端和B端都有一个成功的核心三要素。 C 端三要素是“强需求频次 + 分发/增长 + 付费模型”。这套框架非常有效。对应到 B 端，也有类似的“三要素”，只是它的重心从“高频与分发”转向“价值闭环与组织落地”。

下面把两套框架整理成一篇完整文章，既能用来复盘现有产品，也能用来评估新方向。

一、C 端产品三要素：强需求频次 × 分发/增长 × 付费模型

1）强需求频次：用户是否会“反复打开”

C 端的第一性问题不是“用户需不需要”，而是：

• 需不需要强到“离开会难受”？
• 是否发生在生活的高频节奏里（每天/每周）？
• 用户能不能在没有提醒的情况下主动回来？ 这背后决定了 C 端最关键的底层变量：留存。如果需求不够强或不够高频，你再会做运营投放，也只是在往漏斗里灌水。

常见误区是把“功能完整”当成强需求。C 端强需求往往对应四类典型价值：

• 刚需（沟通、支付、出行）
• 高价值（一次解决就很赚，比如求职、装修）
• 强情绪收益（爽感、陪伴、社交反馈）
• 可确定性提升（显著变好：提效、变美、变强）

强需求频次的反面案例：装修设计 App

产品描述：

一款面向普通用户的家装设计工具，提供3D户型设计、家具摆放模拟、装修风格推荐等功能。产品体验很好,功能也很完整。

看起来有需求：

• 装修确实是刚需

• 用户确实需要可视化工具

• 市场规模足够大 但致命问题是频次：

• 普通人一生装修2-3次

• 单次装修周期集中在1-2个月

• 装完就再也不打开了 结果：

• 获客成本极高（低频意味着必须持续买新用户）

• 无法建立使用习惯

• 留存数据惨不忍睹（90天留存接近0%）

• 即使功能再强、体验再好,也无法形成可持续增长 对比高频强需求：微信

• 每天打开几十次

• 离开会焦虑（害怕漏消息）

• 无需提醒就会主动回来

• 已经嵌入生活节奏 核心教训：

C端产品的"需求强度"不等于"需求频次"。装修需求很强,但低频,无法支撑日活与留存,最终导致获客成本永远降不下来,商业模型无法成立。

2）分发/增长：用户从哪里来，能不能低成本持续来

C 端的增长本质是建立某种可复利的“获客引擎”，常见的引擎类型包括：

• 内容分发（算法推荐、热点、UGC 供给）

• 社交裂变（协作、邀请、关系链传播）

• 搜索意图（SEO、应用商店关键词、问题导向）

• 投放（买量）与渠道合作（但对单位经济要求很高） 增长的核心不是“某次爆了”，而是：

• CAC 能否稳定可控

• 拉新后激活是否顺滑

• 留存是否撑得住（否则增长是漏的）

• 是否能形成复利（越做越便宜，而不是越做越贵）

分发/增长的反面案例：精美日记 App

产品描述：

一款设计精美的个人日记应用，支持多媒体记录、情绪标签、精美模板等功能。产品体验优秀，用户留存也不错（记日记的人往往会持续使用）。

看起来一切都好：

• 强需求频次 ✓（用户每天记录，留存率高）

• 付费模型 ✓（订阅制解锁高级模板和云同步）

• 产品体验 ✓（口碑很好，App Store 评分 4.8） 但致命问题是增长：

• 日记是极其私密的行为，没有社交裂变可能（用户不会分享内容）

• 不产生 UGC 内容，无法靠内容分发获取流量

• 搜索量极低（用户不会频繁搜"日记 App"）

• 完全依赖付费买量，CAC（获客成本）居高不下 结果：

• 每获取一个新用户都要花 30-50 元

• 即使 LTV（用户生命周期价值）能覆盖，增长天花板很低

• 无法形成复利式增长引擎

• 规模越大，投放成本越高（边际成本不降反升） 对比有增长引擎的产品：小红书

• UGC 内容天然可分发（算法推荐）

• 内容可被搜索引擎收录（SEO 流量）

• 社交关系带来裂变（关注、收藏、分享）

• 创作者产生内容 → 吸引消费者 → 部分转化为创作者 形成飞轮

• 获客成本随规模扩大而下降（复利效应） 核心教训：

产品再好、留存再高、付费再顺，如果没有可规模化的低成本获客引擎，就只能永远"买用户"，无法实现真正的规模化增长。C 端产品必须在设计之初就内置增长机制，而不是期待"做好了自然会传播"。

3）付费模型：价值能不能被“顺滑地变成钱”

C 端付费并不是“最后加个订阅按钮”，而是价值交付方式的一部分。常见模型：

• 订阅（持续价值、持续使用）

• 买断（明确交付、低频但高确定性价值）

• 广告（超大规模 + 高时长）

• 交易抽佣（平台型闭环）

• 虚拟道具（强动机、即时反馈） 关键判断不是“能不能收费”，而是三件事：

• 用户愿意为“结果”还是“过程/体验”付费？

• 付费点是否与核心价值对齐？

• 付费是否会反过来伤害增长与留存？

付费模型的反面案例:健身计划 App

产品描述:

一款提供专业健身计划的 App,用户输入身体数据和目标后,AI 生成个性化训练方案。产品功能完整,包含视频教学、动作纠正、数据追踪等。

看起来一切都好:

• 强需求频次 ✓(用户每周健身 3-5 次,打开记录)

• 分发/增长 ✓(社交分享打卡,UGC 内容传播,应用商店搜索量高)

• 产品体验 ✓(专业度高,用户认可价值) 但致命问题是付费模型:

• 核心价值与付费点错位:用户真正需要的是"坚持下去的动力和监督",但产品只对"训练计划"收费

• 一次性交付陷阱:用户付费 68 元获得 12 周计划后,可以截图保存离线使用,不再需要打开 App

• 付费伤害留存:免费版限制核心功能(只能看 3 个动作),导致新用户激活率极低,还没建立习惯就流失

• 竞争替代成本为零:用户可以直接去 B 站/抖音免费看健身教程,付费门槛反而推走了用户 结果:

• 付费转化率不到 2%(远低于行业 5-8%)

• 付费用户次月留存只有 15%(拿到计划就走)

• LTV 极低(人均生命周期价值不足 100 元)

• 广告变现也做不起来(DAU 太低,时长不够) 对比付费模型健康的产品:Keep

• 付费对齐持续价值:会员解锁的是"持续更新的课程库 + 社群 + 数据分析",而非一次性内容

• 分层设计顺滑:免费版可完整使用基础功能,付费是"锦上添花"而非"解锁核心"

• 多元变现:订阅会员 + 电商(装备/代餐) + 线下课程,不把鸡蛋放一个篮子

• 付费强化留存:会员用户因为"付了钱"反而更有动力坚持,形成正循环

• 即时反馈设计:虚拟奖牌、成就体系让用户愿意为"完成感"付费(类似游戏道具逻辑) 核心教训:

C 端付费模型不能只看"用户愿不愿意付钱",更要看:

• 付费是否与用户长期使用绑定(而非一次性交付)
• 付费是否增强而非削弱核心体验
• 是否有多条变现路径分散风险
• 付费点是否对齐用户真正愿意为之买单的"结果"(健身的结果是"身材变好 + 习惯养成",而非"获得一份计划")

一句话总结 C 端：

C 端 = 留存（强需求频次） × 获客（分发增长） × 变现（付费模型）

二、B 端产品三要素：可量化 ROI × 可交付落地 × 可持续续费扩张

B 端也有“三要素”，但它不是围绕“高频与分发”，而是围绕“组织价值闭环”。一个 B 端产品想规模化，通常要满足：

1）可量化的业务价值（ROI）：客户为什么必须买

B 端购买的底层逻辑是“算账”，典型价值落点：

• 降本（节省人力、降低错误、减少返工）

• 增效（流程提速、自动化、提高产出）

• 增收（提升转化、提升开单、提高产能）

• 控风险（合规、审计、事故风险下降） 真正的 ROI 不是 PPT 上讲得通，而是能落到客户组织里可被认可的指标上：

• 哪个指标会变好？

• 变好多少？

• 多久见到？

• 谁来背书？ 很多 B 端产品“看起来有价值但卖不动”，本质是 ROI 不够可被证明。

可量化的业务价值(ROI)的反面案例:智能会议助手系统

产品描述:

一款面向企业的 AI 会议助手,提供会议录音、实时转写、自动生成会议纪要、待办事项提取等功能。产品技术先进,转写准确率达 95%,界面美观易用。

看起来一切都好:

• 功能完整 ✓(录音、转写、纪要、待办一应俱全)

• 技术领先 ✓(AI 能力强,识别准确)

• 用户体验 ✓(演示时客户都说"不错") 但致命问题是 ROI 算不清:

• 价值指向模糊:产品说"提升会议效率",但客户追问"具体哪个指标会变好"时答不上来

  • 会议时长会缩短吗?不会
  • 会议数量会减少吗?不会
  • 决策速度会提升吗?说不清
  • 执行到位率会提高吗?无法证明

• 受益者不是买单者:

  • 真正受益的是普通员工(不用手写会议记录)
  • 但买单决策者是 CIO 或行政部门负责人
  • 他们的 KPI 里没有"员工会议记录轻松度"这一项

• 节省的成本无法量化:

  • 销售说"每人每周节省 2 小时整理会议纪要"
  • 但客户反问:“这 2 小时员工本来也在摸鱼,并没有创造额外产出”
  • 无法证明节省的时间转化成了实际业务价值

• 替代方案成本更低:

  • 客户可以要求员工会后 30 分钟内发邮件总结(零成本)
  • 或者用免费的飞书/钉钉自带会议纪要功能
  • 年费 50 万的采购很难通过审批 结果:

• 签约周期长达 8-12 个月(决策链反复论证价值)

• 最终签约的多是"预算充裕 + 领导个人偏好"的锦上添花型采购

• 续费率只有 40%(第二年问"ROI 在哪"时依然答不上来)

• 无法形成规模化销售(每单都要重新教育市场) 对比 ROI 清晰的产品:销售 CRM 系统

• 指标可量化:

  • 客户跟进及时率从 60% 提升到 92%
  • 销售线索转化率提升 18%
  • 客户流失预警准确率 85%
  • 新人上手周期从 3 个月缩短到 1 个月

• 受益者与买单者一致:

  • 销售 VP 既是决策者,也直接受益于业绩提升
  • ROI 直接体现在他的 KPI 上(团队业绩、人效)

• 算账逻辑顺滑:

  • 年费 30 万
  • 团队 50 人,提升转化率 15%,相当于多出 7-8 个销售产能
  • 单个销售年产出 200 万,投入产出比 1:50
  • CFO 一算就能批

• 可被证明与背书:

  • 有同行业标杆案例(某知名企业用后业绩增长 25%)
  • 可以做 POC 验证(3 个月试点,数据说话)
  • 有第三方报告背书(Gartner、IDC 行业报告) 核心教训:

B 端产品的 ROI 必须满足:

• 指向明确的业务指标(成本、效率、收入、风险,必须选一个能被认可的)
• 受益者与决策者利益一致(或者有足够强的组织推动力)
• 价值可被量化与证明(有数据、有案例、有对比、有周期)
• 算账逻辑能通过财务审查(投入产出比清晰,不是"软价值") 如果只能讲"体验好"“效率高"“很先进”,但答不出"哪个 KPI 会因此变好、变好多少、多久见效、谁来背这个指标”,那这个产品在 B 端就很难卖。

2）可交付与可集成（Time-to-Value）：客户能不能用起来、多久见效

B 端的第二性命题是落地成本。尤其在医院、政企、制造等领域，“产品好”远远不够，决定成败的是：

• 能否对接现有系统与数据口径（接口、权限、SSO、主数据）
• 实施工作量与组织变更成本（流程要不要改、培训要不要重）
• 从签约到第一个可见成果的时间（TTFV，time to first value） B 端增长的常见杀手是“价值来得太晚”：客户在看到价值之前就已经疲惫、抵触、或者项目黄了。

可交付与可集成的反面案例:智能排班系统

产品描述:

一款面向医院的智能排班系统,基于 AI 算法自动生成护士排班表,考虑技能匹配、劳动法规、个人偏好等多维度约束。产品逻辑完善,算法先进,ROI 清晰(每月节省护士长 20 小时排班时间,减少排班冲突 80%)。

看起来一切都好:

• ROI 可量化 ✓(时间节省、冲突减少、合规性提升)

• 决策者认可 ✓(护理部主任看完演示很满意,3 个月就签约)

• 预算充足 ✓(医院信息化预算里专门有排班系统这一项) 但致命问题是落地太难、见效太慢:

• 数据对接陷阱:

  • 需要打通 HIS 系统(人员档案)、HRP 系统(考勤数据)、护理系统(技能认证)
  • 三个系统分属不同厂商,接口标准不统一
  • HIS 厂商要求走"统一接口申请流程",排队等了 4 个月
  • 某个关键字段(护士技能等级)在原系统里没有结构化存储,需要手工补录 3000 条数据

• 历史数据清洗地狱:

  • AI 算法需要至少 12 个月历史排班数据训练
  • 但发现历史数据质量极差:30% 的班次没有记录原因,15% 的调班记录缺失
  • 花了 2 个月人工清洗数据,项目进度严重拖延

• 组织流程冲突:

  • 原有流程:护士长每月 25 号手工排班 → 26 号科室内部协调 → 28 号报护理部审批
  • 新系统要求:每月 20 号各科室提交约束条件 → 系统生成初稿 → 科室微调 → 护理部一键审批
  • 涉及 18 个科室协同改变习惯,推进阻力巨大
  • 多个科室护士长抵触:“我自己排班 20 年了,比系统更懂我的人”

• 权限与安全审批:

  • 系统需要访问人员敏感信息(身份证号、家庭住址、健康状况)
  • 医院信息安全部门要求走三级等保测评,耗时 5 个月
  • 数据跨网传输需要过网闸,性能严重下降

• 培训成本被低估:

  • 原计划 2 天培训,实际发现护士长平均年龄 45 岁,对系统操作陌生
  • 光是"如何设置夜班连续不超过 3 天"这个约束条件,就要反复教 4-5 遍
  • 18 个科室轮流培训,实际耗时 6 周 结果:

• 从签约到真正上线用了 14 个月(原承诺 3 个月)

• 第一次生成的排班表冲突率高达 40%(因为数据不准、约束条件没理解对)

• 前 6 个月护士长们都在"双轨运行":系统生成一版,自己手工再排一版,工作量不减反增

• 项目延期导致内部推动者(护理部主任)失去耐心,在院长办公会上被质疑"这个系统到底有没有用"

• 即使最终勉强上线,口碑已经坏了:其他医院听说"某院上排班系统搞了一年多还没稳定",纷纷观望 对比交付落地顺滑的产品:电子签名系统

• 零数据对接:

  • 不需要打通任何现有系统
  • 文档直接上传,签名后下载,独立运行
  • 7 天完成部署测试

• 渐进式推广:

  • 第一周:行政部门试点(合同签署)
  • 第二周:扩展到采购部门(供应商协议)
  • 第一个月内就有 50 份文件完成电子签名,价值立即可见

• 零培训成本:

  • 操作极简:上传 PDF → 拖拽签名框 → 发送签署链接
  • 签署方甚至不需要注册,手机上点链接就能签
  • 10 分钟演示视频 + 一页操作手册就够了

• 快速见效:

  • 第一周就实现"合同签署周期从 5 天缩短到 2 小时"
  • 一个月后统计:节省快递费 8000 元,纸张成本 3000 元,数据直观
  • 内部推动者有了实打实的战果,后续扩展阻力极小

• 自然扩张:

  • 行政部门用得好 → 人力资源部主动要求接入(劳动合同签署)
  • 人力用得好 → 财务部要求接入(报销审批流)
  • 3 个月内自然覆盖 8 个部门,完全靠口碑传播 核心教训:

B 端产品的可交付性必须满足:

• Time to First Value 必须短(最好 30 天内有可见成果,最晚不超过 90 天)
• 依赖越少越好(数据对接、系统集成每多一个,延期风险指数级上升)
• 组织变更成本可控(如果要改变十几个部门的协同习惯,就是在玩命)
• 渐进式上线策略(先在小范围验证价值,再扩展,而不是一上来就全院推广)
• 培训负担最小化(如果需要超过 2 天培训,说明产品设计有问题) 如果 ROI 再清晰,但客户在看到价值之前就已经精疲力尽、内部推动者被问责、项目组信心崩塌,那产品一样做不起来。B 端的"可交付"不是技术问题,是组织协同与时间窗口的生死线。

3）可持续采购与续费扩张（Budget / Champion / Renewal）：为什么明年还续、还能加购

B 端不是一次性买卖，而是续费与扩张驱动的长期关系。关键在于：

• 谁出钱（预算归口）？

• 谁拍板（决策者）？

• 谁天天用（使用者）？

• 谁推进（Champion/内部推动者）？ 以及更核心的：

• 续费周期里，价值是否持续可被感知？

• 产品是否形成数据资产、流程嵌入、切换成本？

• 是否存在自然扩张路径（扩院区、扩科室、扩席位、扩模块、跨部门复制）？

可持续采购与续费扩张的反面案例:医院科研数据平台

产品描述:

一款面向医院科研管理部门的数据平台,帮助医生从 HIS、LIS、PACS 等系统中提取数据,用于临床研究和论文发表。产品功能强大,支持多维度数据查询、统计分析、可视化图表生成。ROI 清晰(提升科研效率 3 倍,论文产出量增加 40%),交付也算顺利(3 个月上线)。

看起来一切都好:

• ROI 可量化 ✓(科研效率提升、论文数量增加、国自然申报成功率提高)

• 交付落地顺滑 ✓(3 个月完成部署,第一批 20 个课题组开始使用)

• 第一年使用反馈良好 ✓(科研处主任在院长会上汇报"今年 SCI 论文增长 35%") 但致命问题是续费扩张结构缺失:

• 价值感知递减:

  • 第一年:医生觉得"太方便了,以前要手工整理一周的数据,现在 10 分钟搞定"
  • 第二年:医生已经习惯了这个效率,不再觉得"神奇",价值感知回归平淡
  • 第三年续费时,科研处主任被问:“这个系统今年带来了什么新价值?"——答不上来
  • 产品团队说"我们一直在稳定运行啊”,但客户要的是"持续变好",而非"不变差"

• 内部推动者流失:

  • 最初推动采购的是科研处王主任,他把这个项目当作自己的政绩
  • 第二年王主任升任副院长,不再直接管科研
  • 新来的李主任对这个系统没有感情,也没有"ownership"
  • 续费决策时,李主任的态度是"这是上一任留下的,我也不知道有没有必要续"

• 预算归口变化:

  • 第一年:从科研专项经费里出(50 万/年)
  • 第二年:医院财务收紧,要求科研平台费用改由信息科统一预算
  • 信息科主任看了一眼:“一个数据查询工具要 50 万?我们 HIS 系统全套才 200 万”
  • 他的 KPI 里没有"科研论文数量",对这个系统的价值无感
  • 提出要求:“要续费可以,但预算砍到 20 万,或者证明它比免费的 SPSS 强在哪”

• 使用者与买单者脱节:

  • 真正受益的是 20 个课题组的医生(每天用)
  • 但他们不参与续费决策,也没有被组织起来发声
  • 续费评审会上,信息科主任问:“有多少人在用?”
  • 科研处拿不出准确数据(系统没埋点统计)
  • 最后只能说"大概 20 个课题组吧",听起来覆盖面很窄,说服力不足

• 没有自然扩张路径:

  • 第一年覆盖 20 个课题组后,就再也没扩张
  • 产品团队以为"客户会自己推广",但实际上:
    • 其他科室不知道有这个系统(没有内部营销机制)
    • 即使知道,也不主动申请(因为要走审批流程,懒得搞)
    • 没有席位扩张、模块加购、跨院区复制等任何增长触发器
  • 三年下来,ARR(年度经常性收入)完全没有增长,还是 50 万
  • 对于 SaaS 公司来说,NRR(净收入留存率)只有 100%,意味着零增长

• 竞争替代出现:

  • 第三年,HIS 厂商推出"科研数据包"模块,免费给老客户用
  • 功能虽然简陋,但"够用 + 免费"
  • 院长在预算会上问:“人家 HIS 厂商免费送,我们为什么还要花 50 万买?”
  • 科研处主任无法给出有说服力的答案(因为差异化价值没有被持续强化) 结果:

• 第二年续费率 60%(预算从 50 万砍到 30 万,去掉了高级分析模块)

• 第三年不续费(院长拍板:“先用 HIS 厂商的免费版,不够再说”)

• 即使前两年创造了真实价值(论文确实多发了),但因为:

  • 价值感知递减(从"惊喜"变成"理所当然")
  • 内部推动者流失(Champion 换人)
  • 预算归口变化(决策者换成了不受益的人)
  • 没有扩张机制(收入无法增长)
  • 竞争替代出现(免费方案够用)

• 最终还是丢掉了客户

对比续费扩张结构健康的产品:医院 HIS 系统

• 价值持续可见:
  • 每天几千次挂号、开单、结算,价值时时刻刻被感知
  • 系统一旦停摆,医院立刻瘫痪,替代成本极高
  • 不存在"习惯了就不觉得有价值"的问题
• 内部推动者结构化:
  • 不依赖单一 Champion,而是整个信息科 + 医务处 + 财务处都是利益相关方
  • 即使某个主任离职,系统的重要性不受影响
• 预算结构稳定:
  • HIS 是医院信息化的核心基础设施,预算归口明确(信息科)
  • 每年有固定的运维、升级、扩展预算,不会被随意砍
• 自然扩张路径:
  • 医院开新院区 → 自动扩容(+30% ARR)
  • 新增科室(如康复科、日间手术中心)→ 模块加购(+15% ARR)
  • 新政策(如 DRG、互联网医院)→ 功能升级(+20% ARR)
  • 医共体/集团化 → 多院区复制(+100% ARR)
  • NRR(净收入留存率)常年在 120-150%,即使不签新客户,现有客户也在持续贡献增长
• 切换成本极高:
  • 所有业务数据、流程、人员习惯都深度绑定
  • 换系统相当于"心脏移植手术",没有医院敢轻易尝试
  • 即使 HIS 厂商服务一般,续费率依然接近 100%

核心教训:

B 端产品的可持续续费扩张必须满足:

• 价值可持续感知(不能"用习惯了就不觉得好",要有持续变好的机制)
• Champion 结构化(不能依赖单一推动者,要建立多方利益绑定)
• 预算归口稳定(决策者必须是受益者,或有足够强的组织推动力)
• 使用数据可追踪(续费时能拿出"多少人用、用了多少次、创造了什么价值"的硬数据)
• 自然扩张触发器(席位增长、模块加购、跨院区/跨科室复制、上下游延伸等)
• 切换成本递增(数据资产积累、流程嵌入、组织依赖,让客户"离不开")
• 对抗竞争替代的差异化(不能只靠"先发优势",要有持续的护城河) 如果只把 B 端当成"签约 - 交付 - 收款"的一次性项目,而没有在产品设计里内置续费与扩张的结构,那即使第一年成功,第二年、第三年也会逐渐流失。真正健康的 B 端产品,NRR 应该在 110% 以上,靠现有客户的自然增长就能覆盖流失,而不是每年都要靠新签来"填坑"。

一句话总结 B 端：

B 端 = 能算清的价值（ROI） × 能落地的交付（TTFV） × 能续费扩张的机制（NRR）

三、两套“三要素”最重要的差异：核心矛盾不同

把 C 端和 B 端放在一起看，会发现它们的“难点”结构不一样：

1）C 端的核心矛盾：

• 用户注意力稀缺
• 竞争替代极强
• 增长往往先于变现（很多品类必须先规模） 所以 C 端最怕：需求不高频、增长不可复利、付费与体验冲突。

2）B 端的核心矛盾：

• 组织协同复杂
• 落地与集成成本高
• 购买决策链条长（预算、决策、使用分离） 所以 B 端最怕：ROI 说不清、实施太重、续费扩张没有结构。

四、一个通用结论：都不是“三选一”，而是“缺一不可”

你可以把它当成乘法：

• C 端：强需求频次 × 分发增长 × 付费模型

• B 端：可量化 ROI × 可交付落地 × 可续费扩张 乘法的含义是：

• 任何一项接近 0，整体都会接近 0

• 单点做得再强，也补不了短板 这也是为什么很多产品会出现典型“半成功”形态：

• C 端：很好用但没人来；很多人来但不赚钱；能赚钱但起不来量

• B 端：客户觉得有价值但项目落不了；能落地但卖不动/续不动；能签约但扩不起来

五、附：用这两套框架快速评估一个产品（10 分钟版）

如果你要在团队里快速对齐判断，可以直接问：

C 端三问：

• 用户为什么会反复用？频次是什么？

• 用户从哪里来？获客能复利吗？

• 用户为什么付费？付费点对齐核心价值吗？ B 端三问：

• 客户能算清 ROI 吗？指标是谁认？

• 30 天内能不能交付一个可见成果？

• 明年为什么续费？扩容/加购/复制的触发器是什么？