Agent Skills
返回列表
机会解决方案树

机会解决方案树

企业运营 更新于 2026.08.29

将以下提示词粘贴到你的 AI 对话框中:

请根据 https://skillhub.cn/install/skillhub.md,将 @user_fccf428b/opportunity-solution-tree 技能安装到 AI 助手。

技能介绍

为什么需要机会解决方案树?

很多产品团队的通病是"跳步解题"——看到业务目标(比如"提升7天留存")后,直接开始想"要加什么功能",却没先搞清楚用户留存低的真实原因:是新用户找不到核心价值?还是中途流程太复杂?或者是需求没被满足?这种"从解决方案倒推需求"的方式,往往导致功能上线后数据没起色,团队陷入"改功能—没效果—再改功能"的循环。

机会解决方案树(Opportunity Solution Tree)的作用,就是强制团队先回到"用户问题"本身:先明确要解决的业务结果,再拆解用户的真实机会,最后才推导解决方案——相当于给产品发现加一道"慢思考"的过滤器。

这个技能如何帮你构建OST?

技能会按照四层结构和六步流程,帮你把零散的研究数据变成可落地的树:

1. 锁定单个可衡量的目标

第一步是确认或帮你明确唯一的、可量化的业务结果,比如"将新用户的7天留存从30%提升至40%"(而不是"提升留存"这种模糊目标)。这个目标要来自OKR或产品战略,是树的"根"。

2. 从研究里"挖"机会

接下来,技能会从你提供的用户访谈、问卷或分析数据中,提取3-7个用户视角的机会——用"我总是无法快速找到收藏的文章"(痛点)或"我希望在离线时也能查看最近浏览的内容"(需求)这样的句式表达,而不是"需要加离线缓存功能"(解决方案)。

3. 给机会排序

用机会分数(机会分数 = 重要性 × (1 - 满意度),其中重要性和满意度都标准化为0-1)对机会排序,聚焦前2-3个最值得解决的问题。比如某个机会的"重要性"是0.8(用户非常需要),"满意度"是0.2(现有方案让用户很不满意),分数就是0.8×(1-0.2)=0.64,优先级会很高。

4. 生成多个解决方案

针对每个高优先级机会,技能会引导产品三重奏(产品经理+设计师+工程师)一起发散——要求每个机会至少生成3个解决方案,避免"第一个想法就拍板"的陷阱。比如针对"用户无法快速找到收藏文章"的机会,可能想到"增加收藏夹置顶""优化搜索的关键词匹配""在首页加'最近收藏'入口"。

5. 设计验证实验

对最有潜力的解决方案,技能会帮你设计快速、低成本的实验,并明确四个要素:假设("如果加'最近收藏'入口,用户找收藏文章的时间会减少50%")、方法(可用性测试,让用户完成"找上周收藏的文章"的任务)、指标(任务完成时间、步骤数)、成功阈值(80%用户在3步内完成,且7天留存提升5%)。优先选"有切身利益"的实验(比如真实用户行为测试),而不是"问别人觉得好不好用"的意见验证。

6. 可视化呈现树

最后,技能会把目标、机会、解决方案、实验整理成清晰的层级树,让团队一眼看到"每个方案对应哪个用户问题,每个实验验证哪个假设"——相当于把抽象的发现过程变成可追踪的"路线图"。

适用边界与注意事项

  • 必须有输入才能工作:需要你提供业务目标(比如要优化的指标)和用户研究数据(访谈、问卷、分析等),不能凭空生成内容;
  • 一次只处理一个目标:如果同时想提升留存和降低流失,建议拆成两棵树——分散精力会让每个机会的分析都不深入;
  • 机会≠功能:别把"用户需要的功能"当成机会(比如"用户需要离线缓存"不是机会,"用户希望离线时能看内容"才是),否则会回到"跳步解题"的老路;
  • 实验失败要回溯:如果实验没达到阈值,不要硬推方案——技能会引导你回到机会层,重新想其他解决方案,或者调整机会的优先级;
  • 持续更新,不是一次性:树是"活"的,每周要根据新的用户访谈、分析数据或实验结果调整——比如某个实验成功后,可以把对应的机会标记为"已解决",或者补充新的机会。

使用场景

  • 收到一批用户访谈记录后,需要梳理出用户真正的痛点,而不是直接列出要开发的功能
  • 产品季度规划时,要对多个候选需求排序,需要先明确每个需求对应的用户机会和优先级
  • 设计方案评审前,需要为每个备选方案设计验证实验,判断它是否真的解决了用户问题
  • 功能上线后数据没有起色,需要回溯到用户机会层重新分析,而不是继续叠加新功能

适合人员

  • 产品经理,要在OKR周期内把业务目标拆解成用户机会和方案,并向团队展示优先级依据
  • 产品设计师,要在设计方案前确认用户痛点的真实性,避免基于假设做设计
  • 研发工程师,要参与方案发散阶段,提供技术可行性视角,避免陷入'第一个想法'陷阱
  • 创业公司创始人,资源有限时需要快速验证用户需求,避免开发出没人用的功能