PM OS｜产品经理个人系统

把会议纪要、用户反馈、指标、需求和临时待办，持续整理成一套有证据、能决策、会复盘的产品工作系统。

产品经理真正缺的通常不是另一份 PRD 模板，而是一个不会丢失上下文的工作闭环。

你可以直接把这些东西交给 PM OS：

• 一段混乱的会议记录
• 几条用户反馈和销售转述
• 一份口径可能有问题的数据结论
• 老板临时提出的功能想法
• 研发给出的工期与技术约束
• 已经堆成一团的待办列表

它不会把所有内容都变成“需求”。它会先区分事实、解释、方案、假设、决策、承诺和未知信息，再维护六个相互关联的产品视图。

flowchart LR
    A[工作碎片] --> B[可信证据]
    B --> C[用户机会]
    C --> D[产品赌注]
    D --> E[决策与推进]
    E --> F[结果与复盘]
    F --> B

Loading

它会维护什么

视图	解决的问题
Product Cockpit	现在最重要的结果、赌注、风险和未来七天是什么？
Evidence Ledger	这个判断来自用户、数据，还是某个人的意见？
Opportunity Map	我们要解决的到底是用户问题，还是别人提出的功能？
Product Bets	怎么用最小成本证明这个方案值得继续？
Decision Log	当时为什么这么选？什么信号出现时应该重开讨论？
Weekly Product Loop	整条产品链路目前真正堵在哪里？

一个具体区别

原始信息可能是：

三个客户都问导入以后下一步做什么。销售建议首页加 AI 助手。CEO 要求周五前给方案。首次产出率从 42% 降到 35%，但上个月改过埋点。

普通整理工具可能会生成：

需求：增加 AI 助手。待办：写 PRD、约评审、查数据。

PM OS 会把它拆成：

• 三次客户反馈是用户证据，但需要找到原始场景。
• AI 助手是销售提出的解决方案，不是已验证需求。
• 转化率下降暂时是低可信证据，因为数据口径变了。
• 当前机会是“用户完成导入后不知道如何获得第一次结果”。
• 最便宜的下一步可能是先测试固定路径引导，而不是直接开发操作型 Agent。
• 周五前的方案是一个有截止时间的对外承诺。

重点不是替产品经理做判断，而是让判断依据不再散落。

五种使用方式

• Bootstrap：从已有资料建立第一版 PM OS。
• Capture：把新的会议、反馈和指标更新进系统。
• Decide：基于现有证据生成一份决策简报。
• Review：完成周复盘，并找出唯一的主要瓶颈。
• Brief：针对一个产品问题给出带证据链的回答。

使用

将仓库作为 Skill 安装到支持 SKILL.md 的 Agent，或通过 RedSkill 获取后，尝试：

Use $build-pm-system to turn these meeting notes, user interviews,
metrics and tasks into a lightweight PM operating system.

也可以直接用中文：

用 $build-pm-system 整理这个项目。先读会议纪要、用户反馈和数据结论，
帮我建立 PM OS，并告诉我这周真正的瓶颈和下一个决策是什么。

默认在项目中创建 PM-OS/，持续维护六个 Markdown 文件。它不会覆盖原始资料，也不会编造用户原话、指标、负责人或截止日期。

设计原则

• 系统必须生产结果，而不是生产更多文档。
• 观点不是证据，职位高低也不提高证据质量。
• 机会先于功能，验证先于规模化开发。
• 每个重要判断都应能回到原始来源。
• 每周只找一个主要瓶颈和一个最小调整。
• AI 保存上下文、暴露矛盾、组织反馈；产品经理保留最终判断。

系统结构借鉴了 Ross Harkness 对“输入—过程—输出—反馈回路”的解释，以及 SVPG 关于 outcomes、product discovery 和 evidence 的产品工作原则。

• Business is hard until you build systems like this
• The Product Operating Model
• Build to Learn vs Build to Earn

License

MIT