Feature Teardown
一个功能想法或一句用户抱怨进来,五步之内给出结论:抄谁 / 我们已经有了改入口就行 / 换个解法 / 真得做。
边界
管:单个功能级别的对比。别人怎么做、为什么做、我们有没有、还能怎么做。
不管:
- 完整竞品简报(公司定位、pricing、win/loss、battle cards、market trend)→ 装有 product-management 插件时用其 competitive-brief,否则不在本 skill 范围
- 这个需求值不值得做的 KANO/RICE 结论 → requirement-eval(本套件内)
- 方向还没定、要发散多个方向 → 推荐上游 addyosmani/agent-skills 的 idea-refine
- 开源库/能抄的代码 → prior-art(本套件内)
当前产品从上下文解析,不预设
第 4 步要盘点"我们现有能力","我们"指哪个产品每次都要确认:用户当场说的、项目文档、 项目根配置、对话上文。没有默认产品,也不要沿用其它会话或其它任务里出现过的产品。 缺就问一句,不猜。
如果这轮压根没有"我们"(纯个人新项目,还没有存量产品),第 4 步跳过并说明跳过了。
五步
1. 谁做过
分三层,别只看直接竞品:
- 直接 —— 同类产品的同一功能
- 间接 —— 用完全不同的形态解决同一个问题
- 替代 —— 不用软件怎么解决:Excel、手工流程、雇个人、或者干脆啥也不做
"啥也不做"是最容易漏的一个选项,也经常是真实答案。
2. 用户路径几步
不要停在"他们有这个功能"。写出从触发到拿到结果的完整步骤:
- 入口在哪(用户怎么发现的)
- 中间几步、每步要用户做什么决定
- 什么时候能看到结果、失败了怎么办
步数和入口位置本身就是结论。 同一个功能藏在三级菜单里和挂在首屏,是两个产品决策。
3. 为什么做(反推,不是事实)
从可查的东西倒推动机:改版记录 / 发布说明 / 帮助中心措辞 / 应用商店更新日志 / 社区和评论区吐槽 / 招聘 JD。
回答两个问题:他们在服务哪类人、解决这类人的什么问题。
这一步的产出全部标成推断,不能当事实用。 写「推测:…,依据:…」, 依据拿不出来就写「动机不明」,不要编一个合理的故事。
4. 自查:我们是不是已经有了 ⟵ 早退出闸门
先把需求升维:这个功能在第一性原理上解决的是什么问题("要收藏功能" → "高频内容会被历史清理冲掉")。 拿这个问题、而不是功能名,去核当前产品——同一个问题常常已经被另一个形态的功能解决了,按功能名查永远查不到。
核对必须有证据来源,按优先级:
- 产品知识库:按 PRODUCT-CONTEXT 协议登记过知识库的, 先去知识库里查现有能力和历史方案,再下结论
- 拿升维后的问题反问用户:"现在用户遇到这个问题时是怎么解决的?有没有部分解决它的功能?"
- 两者都没有 → 明确写「现状能力未核实」,不许凭空回答下面三问
有了证据再对着第 2 步的用户路径逐步核:
- 这条路径我们能不能走通?
- 能走通的话,是能力问题还是发现路径问题——用户不知道有、找不到、还是用了但不认为解决了?
- 不能走通的话,缺的是哪一步?
结论是「已经有了,是入口/认知问题」就到此为止,不要往下走第 5 步、不要交给 requirement-eval、更不要写 PRD。 直接给改入口/改文案/加引导的建议,这轮就结束了。
这一步是整个 skill 最值钱的地方。跳过它的代价是白做一个功能。
5. 别的解法
只有第 4 步没早退时才做。不做这个功能,同一个问题还能怎么解决—— 改现有功能、换交互形态、改默认值、加引导、或者判定这个问题不值得解。
输出
只写最终态。不写调研过程,不列否掉的候选,除非否掉的理由本身是结论。
## 结论
<一句话,四选一:抄 X 的做法 / 我们已经有了,改的是入口 / 换 Y 解法 / 真得做,做 Z>
## 别人怎么做的
| 产品 | 类型(直接/间接/替代) | 用户路径 | 入口位置 | 访问日期 |
|---|---|---|---|---|
## 动机推断
- <产品>:推测服务 <人群> 的 <问题>;依据:<可查来源>
## 我们现在的状态
- 路径能否走通:
- 缺的是能力还是发现路径:
- 证据:
## 建议
<具体到做什么,不是"建议进一步调研">
反模式
- 只写"竞品 A 有这个功能",不写路径几步、入口在哪
- 动机推断没标成推断,写得像事实
- 跳过第 4 步直接说"该做" —— 这是这个 skill 存在的唯一理由
- 漏掉"替代方案"层,尤其是"啥也不做"
- 结论写成"各有优劣,供参考",不给推荐
- 表里没有访问日期 —— 产品一改版整张表就过期了
- 越界去做 pricing、市场规模、win/loss