Product-Manager-Skills 实战案例解析：用 product-strategy-session 工作流为生命科学领域内部工具做产品战略决策
Product-Manager-Skills 实战案例解析：用 product-strategy-session 工作流为生命科学领域内部工具做产品战略决策
导读：本文基于 Product-Manager-Skills 仓库中 product-strategy-session 工作流的生命科学行业完整示例（sample-lifesciences.md），拆解一家生物科技公司将内部临床研究平台对外产品化的全过程。你将看到：内部工具遇到外部需求时如何做"要不要成为产品"的战略判断、如何在监管严苛的市场里用约束条件（而非偏好）淘汰细分市场、以及如何把一个"改变不了公司轨迹"的机会收敛为带书面退出条款的有限试点。读完你可以直接把这套四阶段打法（定位 → 问题框定 → 客户探索 → 路线图与决策）复用到自己的战略会议中。
一、先看工作流：product-strategy-session 是什么
在进入案例前，先明确支撑这个案例的方法论骨架。根据 skills/product-strategy-session/SKILL.md，product-strategy-session 是一个 workflow 类型的技能，它把定位（positioning）、问题框定（problem framing）、客户探索（discovery）、路线图规划（roadmap planning）等 15+ 个子技能编排成一个端到端流程，典型周期 2–4 周，包含 6 个阶段：
| 阶段 | 时间 | 核心活动 | 使用的子技能 |
|---|---|---|---|
| Phase 1 定位与市场背景 | 第 1 周 D1-2 | 定位工作坊、proto-persona、JTBD | positioning-workshop、proto-persona、jobs-to-be-done |
| Phase 2 问题框定与验证 | 第 1 周 D3-5 | Problem Framing Canvas、问题陈述 | problem-framing-canvas、problem-statement |
| Phase 3 解决方案探索 | 第 2 周 D1-3 | 机会-解决方案树、史诗假设 | opportunity-solution-tree、epic-hypothesis |
| Phase 4 优先级与路线图 | 第 2 周 D4-5 | 优先级框架、RICE 评分、季度排期 | prioritization-advisor、tam-sam-som-calculator |
| Phase 5 干系人对齐 | 第 3 周 | 愿景式新闻稿、战略汇报 | press-release |
| Phase 6 执行规划 | 第 4 周 | 史诗拆分、用户故事、冲刺规划 | epic-breakdown-advisor、user-story |
该工作流强调三个"不是"：不是功能头脑风暴（先框定问题而非罗列功能）、不是瀑布式规划（内置反馈循环与迭代）、不是 PM 单机练习（需要跨职能参与）。每个阶段后都有明确的决策点——例如 Phase 2 结束后问"问题是否已验证？"，答案是否就追加 5–10 场客户访谈。
值得注意：工作流本身还挂接了 workshop-facilitation 作为引导会话的交互协议（single-question 轮次、进度标签、决策点编号推荐等），而本案例文档记录的正是这套流程在生命科学领域的一次完整实战输出。
二、案例背景：一个"内部工具要不要成为产品"的战略问题
示例文档 sample-lifesciences.md 构造了一个极具行业代表性的场景：
- 公司：Brightwater Biologics（生物技术公司），运营多中心临床试验（multi-site clinical trials）。
- 产品：内部产品团队为协调员（coordinators）、监查员（monitors）和 CRO 合作伙伴打造的临床研究运营平台 Trialpath。
- 战略问题：两家 CRO 合作伙伴请求把 Trialpath 授权给与 Brightwater 无关的研究使用。一个内部工具，该不该变成对外产品？
文档点明了这个领域改变战略工作的三个底层事实，这是理解整个案例的钥匙：
- 收入落后于证据很多年（revenue arrives years after the evidence that justifies it）——医药/临床领域的付费周期极长；
- 买家很少是使用者（the buyer is rarely the user）——采购决策链与操作人员分离；
- 你对比的选项不是竞品，而是"把同一批工程产能继续花在真正的公司业务——疗法项目上"（keep spending that engineering capacity on the therapy program that is the actual company）。
这三条直接决定了后面所有决策的走向：这不是一个常规的"竞品分析"问题，而是一个内部资源配置与战略机会成本问题。
三、Phase 1——定位：用定位工作坊淘汰三个细分市场中的一个
案例的第一阶段运行了 positioning-workshop。根据该技能文档，定位工作坊是一个互动式流程：收集产品上下文 → 通过提问识别目标客户细分 → 用 JTBD 视角挖掘未被满足的需求 → 定义品类与收益 → 确立差异化 → 输出 Geoffrey Moore 式定位陈述。
案例中的实操记录如下：
- 首次尝试失败：最初瞄准"临床试验申办方（clinical trial sponsors）"，当场崩溃——40 人的生物技术小公司与全球性 CRO 的购买行为完全不同，无法作为一个细分市场存在。这正是定位工作坊"不是为所有人服务"原则的体现。
- 拆分为三个候选：① 没有平台的小型申办方；② 为他人运营研究的 CRO；③ 已在使用在位系统（incumbent systems）的大型申办方。
- 第三个细分当场被淘汰：替换一个已在验证（validated）的在位系统，意味着客户要重新做全套验证（re-validates everything）。没有人会为了一个功能优势去这样做。注意这里淘汰细分靠的是监管机制约束，而非需求强弱。
- 为存活的两个细分构建 proto-persona（原型人物，假设驱动、待验证的角色画像，见 proto-persona）：
- "First-Study Farrah"：小型申办方的运营负责人，正在运营自己的第一个多中心试验；
- "Margin-Watch Marcus"：CRO 运营总监，其经济模型建立在人员配比（staffing ratios）上。
- JTBD 迅速分化（JTBD 框架见 jobs-to-be-done，把客户需求拆为功能/社会/情感三类工作与痛点、收益）：
- Farrah 的诉求："帮我在不组建系统团队的情况下，把合规的研究跑起来。"
- Marcus 的诉求："帮我让每个协调员承接更多研究。"
阶段产出的定位陈述草稿（小型申办方细分）：
For clinical-stage sponsors running their first multi-site studies, who need a compliant trial platform without an internal systems team, Trialpath is a trial operations platform that ships preconfigured to the workflows a study actually runs on — unlike enterprise systems that assume a validation team you don't have.
（面向处于临床阶段、首次开展多中心研究、需要合规试验平台却又没有内部系统团队的申办方，Trialpath 是一款试验运营平台，按研究实际运行的流程预配置交付——不像企业级系统那样假设你有一个你没有的验证团队。）
这段定位陈述完整对应定位工作坊的输出格式：For（目标客户）→ that need（未满足需求）→ 产品 → is a（品类）→ that（关键收益），Unlike（对比对象）→ provides（差异化）。
四、Phase 2——问题框定：用 MITRE Canvas 重新框定"内部问题"
第二阶段运行了 problem-framing-canvas。这是 MITRE Innovation Toolkit 的框架，分三个区：Look Inward（向内看：自身假设与偏见）→ Look Outward（向外看：谁经历问题、谁被遗漏）→ Reframe（重构：产出问题陈述与 How Might We 问句）。
案例的关键操作是：对"内部问题"而非"客户问题"跑 Canvas。
- 向内看（Look Inward）：Trialpath 是为 Brightwater 自己的方案（protocols）构建的。两家 CRO 来问，不构成一个市场（Two CROs asking is not a market）。在它上面花的每一小时，都是从疗法项目上拿走的一小时。
- 向外看（Look Outward）：小型申办方确实缺乏好选项，而在位厂商按企业级定价（incumbents price for enterprise）。需求拉力是真实的。
- 重构（Reframe）：问题不是"有没有需求"，而是*"我们能不能在不拖累作为公司本体的疗法项目的前提下服务它？"（"can we serve it without taxing the program that is the actual company?"*）
- 直白地命名战略风险：Brightwater 是一家生物技术公司。一条软件产品线会与同一批稀缺的工程资源竞争，而它的收入节奏比它要资助的临床试验慢得多（revenue arrives on a slower clock than the trials it would fund）。
这一步展示了 MITRE Canvas 的威力：它没有默认"增长总是好的"，而是把战略机会成本显式化为问题的核心。
五、Phase 3——发现：六场访谈，杀死一个"披着软件外衣的服务业务"细分
第三阶段是客户探索（discovery），共完成 6 场访谈：4 位小型申办方运营负责人 + 2 位 CRO 总监。案例给出三组关键发现：
1. 小型申办方确认了痛点，也暴露了真正的拦路虎 他们需要已验证的系统（a validated system），而且 "验证文档"（validation documentation）是每场对话的第一个问题。Brightwater 是为自己的使用验证了 Trialpath——而不是作为供应商提供的系统（vendor-supplied system）验证的。这是后续所有决策的核心闸门。
2. CRO 想要的东西正好相反 CRO 需要按客户深度可配置（deep configurability per client）——这本质上是一个穿着软件外衣的服务业务（a services business wearing a software costume）。
3. CRO 细分被直接杀死 Marcus 的工作需要人员杠杆（staffing leverage），那是咨询业务，不是授权业务（that's consulting, not licensing）。
诚实测算市场规模：可触达的小型申方约 300 家，现实可达的覆盖率远低于此。结论是：这不是一个能改变 Brightwater 轨迹的业务（Not a business that changes Brightwater's trajectory）——最多是一个能养活一支团队的业务（Possibly one that funds a team）。
这个阶段演示了 product-strategy-session 工作流的核心纪律：访谈发现推翻假设 → 细分市场被约束条件（而非偏好）淘汰 → 市场规模被诚实量化。
六、Phase 4——路线图与决策：把判断收敛为一个带退出条款的试点
第四阶段运行了 roadmap-planning。该技能本身是一个编排工作流：收集输入（业务目标、客户问题、技术约束、干系人请求）→ 定义史诗假设 → 用优先级框架评分 → 按依赖排期 → 与干系人沟通。案例中，它被用于一个刻意收窄的下注：
- 决策：有限试点，而非产品线（a limited pilot, not a product line）。以成本价授权给 3 家小型申办方，期限 18 个月，并写明了退出路径（with a named exit）。
- 排期序列：厂商级验证文档（vendor-grade validation documentation）→ 多租户隔离（multi-tenant isolation）→ 为非 Brightwater 方案做配置（configuration for non-Brightwater protocols）。第一项是闸门——如果它失败，后两项都不重要。
- 动笔之前先写好终止标准（kill criterion）：如果厂商级验证文档耗时超过两个工程师季度（two engineer-quarters），就停止。因为那笔成本将开始拖累疗法项目。
- 显式非目标（non-goals）：不做 CRO 细分、不做在位系统替换、不招销售。
- 18 个月后的复盘只问一个问题："它有没有在不拖慢任何一项试验的前提下养活了自己？"（did this fund itself without slowing a trial?）
这是整个案例最值得借鉴的收尾动作：面对一个"不够大但真实存在"的机会，战略决策不是"做/不做"，而是"用多小的赌注、多长的时限、多清晰的退出条件去做"。
七、这个案例教会了 SaaS 案例教不了的东西
示例文档最后用一个对比小节总结了 5 条经验（可对照同一目录下的 SaaS 版示例 sample.md 理解差异）：
- 战略问题是内部问题，不是竞争问题。真正的替代方案不是对手平台，而是把同一批工程师花在药物上。Phase 2 明确命名了这一点，而不是默认增长总是好的。
- 一个细分死在监管机制上，而不是死在需求上。大型申办方想要它，但永远不会买——因为切换意味着重新验证。是约束条件，不是偏好，在一场会议里淘汰了这个细分。
- 验证文档就是整个闸门。每场小型申办方访谈都以它开场，它成为路线图第一项和终止标准。在受监管市场里，合规工件往往就是产品决策本身（the compliance artifact often is the product decision）。
- 一个细分因为"是伪装的服务"而被杀。CRO 的可配置性听起来像产品需求，行为却像咨询收入。尽早命名它，避免了为两个客户年复一年构建定制配置。
- 诚实的规模测算是"这改变不了我们的轨迹"。约 300 家可触达申办方。这没有阻止下注——而是把赌注量化为一个 18 个月的试点加书面退出，而不是一条带招聘计划的产品线。
这五条合起来，正是生命科学（以及一切受监管、长周期、买家与用户分离的行业）做产品战略的核心心法：用约束机制过滤市场、用合规工件做闸门、用机会成本做标尺、用试点规模对冲不确定性。
八、如何在本仓库中复现这套打法
如果你想把上面这套流程用起来，仓库提供了可直接使用的完整资产：
- 工作流定义：skills/product-strategy-session/SKILL.md——6 阶段编排、决策点、反模式（跳过问题验证、PM 单干、无高管赞助、无决策点、战略会议变成永久流程）与时间投入估算（最短 2 周 / 典型 3 周 / 最长 4–6 周）。
- 会话记录模板：skills/product-strategy-session/template.md——提供从"战略背景 → 目标客户 → 问题框定 → 机会 → 解决方案假设 → 优先级 → 路线图/排期 → 成功指标 → 下一步"的完整填写结构。
- SaaS 对照案例：skills/product-strategy-session/examples/sample.md——包含"好会话"（60% 引导流失改进）与"坏会话"（跳过发现阶段直接做移动 App，三个月后失败）两个对照示例，可与本文的生命科学案例互为参照。
- 支撑子技能（均可在仓库中找到独立 SKILL.md）：positioning-workshop（Geoffrey Moore 定位陈述输出格式与 5 个自适应问题）、problem-framing-canvas（Look Inward / Look Outward / Reframe 三区结构与 8 步引导问题）、proto-persona（假设驱动的原型角色）、jobs-to-be-done（工作/痛点/收益结构化拆解）、roadmap-planning（RICE 评分、按季度排期、Now/Next/Later 路线图格式）。
典型调用方式（在支持技能的 AI 编码代理/桌面对话中）是直接向 Agent 下达如 "Run a strategy session for Trialpath: two CROs want to license our internal trial platform, exec review in 4 weeks" 之类的指令，工作流会从定位阶段开始，逐个阶段推进并在每个决策点让你确认是否跳过或追加发现工作；如果你已经带上了定位草稿、访谈记录或路线图初稿，它会跳过已覆盖的部分直接前推。
结语：从案例到方法论的一句话总结
Trialpath 案例的可迁移价值在于它示范了一次教科书级的战略克制：用定位工作坊让"为所有人服务"的冲动当场破产，用 MITRE Canvas 把问题从"有没有需求"重构为"能不能不动摇公司本体地服务"，用 6 场访谈杀掉一个伪装成产品需求的服务业务，最后用"验证文档 = 闸门 + 两个工程师季度 = 终止标准 + 18 个月 = 试点时限"把机会压缩成可测量、可退出、可复盘的有限赌注。对于任何身处长周期、强监管行业的团队，这套"约束优先、闸门优先、机会成本优先"的打法，比追求增长叙事更能产出真正经得起执行检验的战略。