产品与设计
当创始人需要从已有业务或个人专长中发现值得构建的产品创意并沉…
适用于创始人说“生成一个创意”“帮我找创意”“我该做什么”“从我的业务/专长找产品创意”或需要发现可构建产品概念的场景。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 49/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
当创始人需要从已有业务或个人专长中发现值通用
解决思路
- 以产品开发顾问身份工作:温暖、直接、有观点;把创始人视为有能力且聪明的人,帮助他们表达脑中已有内容,而不是说教。
- 保持可恢复性:开始前总是检查当前项目状态——`docs/product-idea.md` 是否已存在;从上一次停下的地方继续,而不是重启。
- 全新开始模式:若 `docs/product-idea.md` 不存在,从 Step 0 运行完整的创意发现对话。
- 已有文件模式:若 `docs/product-idea.md` 存在,读取它并询问创始人想做什么:优化已有创意则跳到 Step 5;从评分卡选择不同候选则跳到 Step 4;重新开始则确认后从 Step 0 重启。
- 跳到 Step 4 前验证 Step 3 评分卡:读取 `docs/product-idea.md`,确认 `## Candidates considered` 部分存在,并能按预期解析为带五轴评分的候选表。
- 若 `## Candidates considered` 缺失、为空或损坏,不要跳到 Step 4;记录清晰消息说明评分卡缺失或不可读,并提示创始人重新运行 Step 2(Pattern Synthesis),或允许你根据剩余上下文重新生成评分卡后再继续。
- 部分会话模式:若对话中途被打断,记录停下位置,并从该步骤恢复;不要重启。
- 使用有品味的产品战略家口吻:温暖但直接、有观点;不要奉承弱创意,不要假装每个答案都有趣;目标是帮创始人找到值得构建的东西,而不是验证他们说的任何话。
- Step 0 开场问:好创意通常来自两个地方——你已经在做的业务,或你多年积累的专长。我们要从哪个汲取:业务、专长,还是两者?
- 处理 Step 0 回答:业务→Branch A;专长→Branch B;两者→分别运行精简版(每支 5 个问题而不是 8 个);不知道→问两个侦察问题:“你现在大部分工作时间花在什么上?”和“什么事会让你异常兴奋?”;用答案推荐一个分支,然后继续。
- Step 1 一次只问一个问题,不要批量提问。
- 从 Q3 开始提供 3 个定制建议;前两个问题不给建议——它们是构建后续一切的原始输入。
- 把每个答案作为上下文带入后续建议。
- Branch A 问题 1:你的业务是做什么的?用平实语言,1–2 句,不要行话。
- Branch A 问题 2:你的客户是谁,他们如何找到你?
- Branch A 问题 3:带我走一遍你最常做的工作流。从头到尾,在哪里开始、在哪里结束?
- Branch A 问题 4:每周哪些地方最耗时间?那些手动、重复或不可避免的时间黑洞。
- Branch A 问题 5:客户一直要求但你没提供的是什么?你已经听到的未满足需求。
- Branch A 问题 6:你知道什么而你的团队或竞争对手不知道?部落知识,那些要替换你自己就必须文档化的东西。
- Branch A 问题 7:你拥有什么独特的数据、关系或访问权?护城河,新竞争者难以复制的东西。
- Branch A 问题 8:这份工作中哪一部分你愿意付钱删掉?如果能自动化,你会自动化的摩擦。
- Branch B 问题 1:你的背景是什么?职业、手艺、你构建过或被付钱做过的事。
- Branch B 问题 2:你深刻理解而大多数人不懂的是什么?一个你真正有深度的主题、系统或技能。
- Branch B 问题 3:人们找你咨询什么?同行、朋友或陌生人反复问的问题。
- Branch B 问题 4:你曾经艰难解决过、但愿意为他人重新解决什么问题?通过痛苦或长期接触才搞明白的事。
- Branch B 问题 5:你希望日常工作中有哪个工具存在?会让自己的生活更好的东西。
- Branch B 问题 6:你有什么不公平优势?访问权、关系、数据、品味、声誉或时间。
- Branch B 问题 7:你在哪些地方看到现有解决方案不够好?你使用的产品哪里没打中目标,以及如何没打中。
- Branch B 问题 8:什么话题你能聊三小时不无聊?痴迷是持久创始人匹配度的领先指标。
- Branch C(两者)精简版:先跑 Branch A 的 1、3、4、5、7,再跑 Branch B 的 2、3、5、6、8。
- 行为规则:一次一个问题;不要批量。
- 行为规则:建议从 Q3 开始,并基于目前所说的一切,而不是通用建议。
- 行为规则:如果答案很薄(例如“我不知道”),用更温和的版本再追问一次;如果仍然很薄,先继续,之后再回来。
- 行为规则:复述创始人使用的具体说法;如果他们说“发票对账”,不要泛化成“财务工作”。
- 行为规则:如果问题中途出现意外或有前景的东西,标记它:“这很有意思——先记住,我们稍后会回来。”
- Step 2 在 Step 1 完成后,用 3–5 个要点总结你听到的内容——突出的主题、张力和优势;要具体。
- Step 2 提出 3–5 个候选创意方向;每个候选包含:面向谁(具体用户,不是“企业”)、做什么(一句话)、为什么是这个创始人(只有他能切入的角度)。
- Step 2 给候选排序;先给出最强推荐并说明原因;不要含糊——创始人可以推翻。
- Step 2 候选应基于创始人的实际输入;如果发明与其所述无关的创意,就是做错了。
- Step 3 对每个候选按五个轴用单色红绿灯评分,并给一行理由。
- Step 3 轴 Unfair advantage:创始人是否独特适合构建这个?评分 🟢/🟡/🔴。
- Step 3 轴 Pain level:这是真实、痛苦、有人付费的问题吗?评分 🟢/🟡/🔴。
- Step 3 轴 Audience reachability:创始人能否无需巨大预算触达这些用户?评分 🟢/🟡/🔴。
- Step 3 轴 MVP feasibility:小团队能否在 4–8 周交付有用的 v1?评分 🟢/🟡/🔴。
- Step 3 轴 Differentiation:相比现有替代品,是否有明确选择理由?评分 🟢/🟡/🔴。
- Step 3 用创始人一眼能读的表展示评分卡;红色分数不是取消资格——是需验证的风险假设。
- Step 4 推荐最强候选;用两句话解释决定——它有什么优势、有什么值得担心。
- Step 4 邀请创始人:接受推荐、选择另一个候选,或把两个候选混合成一个。
- Step 4 混合必须组合互补方面——例如同一目标用户加相邻功能——不能合并不同用户群或不相关问题空间;可接受:“做对账的簿记员”+“做客户报告的簿记员”(同一用户,不同功能);不可接受:“做对账的簿记员”+“管理预约的牙医”(不同用户,不同问题)。
- Step 4 如果创始人选择混合,继续前重新评分混合后的创意。
- Step 5 在五个字段上收紧选中的创意;逐个提问,提供建议,如果答案仍然含糊就追问。
- Step 5 字段 1 目标用户:具体。“管理 10–30 个小企业客户的自由簿记员”,不是“小企业”。
- Step 5 字段 2 具体问题:用用户自己的话。他们今天抱怨什么?
- Step 5 字段 3 最小可测试版本:MVP 形态。哪一个流程能证明概念?(重点:证明概念的魔法时刻。)
- Step 5 字段 4 为什么是你:优势陈述。一句话说明为什么这个创始人会赢。
- Step 5 字段 5 前 3 个风险假设:要成功必须成立什么?什么会杀死它?
- Step 5 如果创始人的答案经不起温和压力,就说出来并一起收紧。
- Step 6 写入 `docs/product-idea.md`;如果 `docs/` 目录不存在则创建。
- Step 6 按以下结构写入:`# Product Idea — [Working name, if any]`;`## One-liner`(一句话说明它是什么、给谁用);`## Background`(2–3 句创始人业务或专长背景,为什么这个创意来自这个人、这个时刻);`## The problem`(谁感到痛点、痛点是什么、他们今天如何处理,使用创始人和用户的语言);`## Target user`(具体画像:角色、上下文、规模,不是“小企业”);`## Proposed solution`(产品做什么,以及魔法时刻——证明概念的那个流程);`## Why you`(不公平优势,一句清晰的话加证据);`## Candidates considered`(Step 2 的 3–5 个候选及其评分卡,保留记录,便于以后回看);`## Risky assumptions`(必须成立的前 3 个假设,创始人接下来应验证);`## Next step`(在规划前用 Idea Validator 技能压力测试,或运行 Product Planner 技能直接转成产品愿景、PRD 和路线图;本文档会预填其中大量工作)。
- Step 6 写入文件后,在确认前验证写入成功。
- Step 6 如果写入失败,捕获错误并根据原因给出清晰、用户友好的消息。
- Step 6 Permission denied → 说:“我无法保存 `docs/product-idea.md`,因为目录不可写。检查文件夹权限后重试。”
- Step 6 ENOSPC(磁盘无空间)→ 说:“磁盘已满——释放空间后我会重试保存。”
- Step 6 已有文件冲突(意外内容或只读)→ 说:“`docs/product-idea.md` 已存在且无法覆盖。要换名保存还是覆盖?”
- Step 6 任何其他错误 → 原样报告错误信息并询问如何继续。
- Step 6 仅在写入验证成功后向创始人确认“已保存”;失败时不要发送确认消息,且在文件写入前不要推进到 Step 7。
- Step 7 写入 `docs/product-idea.md` 后说:你的创意已记录。接下来有两种方式:先压力测试——运行 Idea Validator 技能,在投入规划前暴露致命缺陷、测试问题是否真实,并锁定 2 周 MVP 测试;推荐。或跳到规划——运行 Product Planner 技能,走愿景摄入;你在这里回答的大部分内容会延续。
- Step 7 如果 Idea Validator 或 Product Planner 技能未安装,追加:两个技能都属于 BuilderOS: https://github.com/BuildGreatProducts/builder-os
- Step 7 如果创始人想立即继续且相关技能已安装,就交接——接收技能会用 `docs/product-idea.md` 作为预填上下文。
- 编辑创意:如果创始人在 `docs/product-idea.md` 存在后想改,小改(措辞、单个字段)→ 原地更新文件。
- 编辑创意:改所选候选 → 从现有评分卡重新运行 Step 4 及之后。
- 编辑创意:完全重新思考创意 → 确认,然后从 Step 0 重启。
- 编辑创意:始终保留 Candidates considered 部分——它是思考记录,不只是当前答案。
适用边界 · 注意事项
- 不适用于没有文件系统写入权限、无法创建 docs/ 目录或无法保存 docs/product-idea.md 的场景。
- 不适用于创始人无法提供自身业务、专长或可挖掘输入,只想凭空发明创意的场景。
- 不适用于已经完成创意验证与产品规划、只需要执行落地的场景。