---

name: skills-si-product-manager-workflow description: 面向互联网、软件与智能硬件产品经理的协作工作流，用于在需求澄清、用户访谈、优先级排序、PRD、竞品分析、路线图、上线及复盘场景产出可编辑的结构化材料；当需要把零散信息转为可审阅产品文档时触发。仅基于已提供或已核验材料工作，不替代用户研究、数据分析、法务、隐私、安全、医疗、金融或其他执业判断。 license: MIT metadata: publisher: Skills-SI origin: original-ai-assisted version: 1.0.0 runtime-tested: false language: zh-CN

产品经理协作工作流

本站原创（Skills-SI）｜AI辅助起草｜待独立人工专业复核｜未在任何客户AI宿主中实机执行。 不冒充第三方、平台、监管机构或官方；本包为可编辑协作规范，不是执业意见或成果证明。

协作前置与模式选择

先确认本轮目标、现有材料、交付对象、截止时间与决策人。

一次最多追问 3 个阻塞问题，优先问目标用户、业务结果和已有证据。

材料缺失时用【待提供】标注，不把推测写成事实。

未能追溯来源、日期或样本的方法与结论用【待核验】标注。

先区分探索模式、定义模式、交付模式和复盘模式，再选择模板。

探索模式用于问题发现、访谈与假设清单，不承诺方案可行。

定义模式用于优先级、PRD 和验收口径，要求明确决策人。

交付模式用于路线图、上线清单与跨团队同步，要求列明依赖和风险。

复盘模式用于从事实、数据和反馈中复查，不把结果倒推成单一原因。

不要把访谈偏好、内部意见或竞品宣传直接等同于用户需求。

不要为填满文档编造用户数量、转化率、市场规模、成本、工期或效果。

适用与边界

适用于互联网产品、企业软件、开发者工具、移动应用和智能硬件的产品协作。

适用于需求池治理、问题定义、访谈归纳、方案说明、发布准备和项目复盘。

适用于已有访谈纪要、工单、行为数据摘要、设计稿说明或技术约束的整理。

不替代真实用户研究、可用性测试、统计分析、代码评审、信息安全测试或运营执行。

不将 RICE、MoSCoW 或竞品矩阵当成自动决策器；评分依据应能被复查。

不把公开资料、竞争产品界面或客户文件复制为己方成果；保留来源和授权状态。

涉及个人信息、设备标识、位置、音视频、生物识别或未成年人信息时，先做最小化收集评估。

涉及隐私、数据跨境、数据保留、算法决策、可访问性、安全或合同义务时，与法务、隐私、安全及相关执业人员确认。

法律、医疗、金融、合规、造价、建筑等高风险场景不构成执业意见，须由持证或执业人员复核。

拒绝规避监管、刷单刷量、虚假宣传、侵权复制、歧视性设计、隐瞒实益拥有人或其他违法请求，并改为提供合规替代路径。

先读取的配套资源

需求信息不足或需发起协作时，读取 需求简报模板。

需要直接形成访谈、优先级或 PRD 初稿时，读取 输出模板。

进入评审、跨团队协作或发布前，读取 检查清单。

需要理解从模糊输入到结构化交付的写法时，读取 虚构演示。

许可证与归属信息见 LICENSE 和 来源与版本。

触发判断

当用户说“梳理需求”“写 PRD”“排优先级”“做访谈”“看竞品”“排版本”“准备上线”或“做复盘”时使用。

当信息散落在会议纪要、工单、表格或聊天记录且需要形成共同口径时使用。

当需要比较多项候选需求、明确范围或把验收条件写得可测试时使用。

当用户只需一句产品文案、单个功能命名或纯视觉产出时，通常不使用本工作流。

当用户要求臆造市场数据、访谈结论、合规结论或承诺业务结果时，不使用臆造方式；改为列证据缺口与验证计划。

当用户要求输出法律、医疗、金融等专业结论时，仅整理材料并提示由相应执业人员复核。

核心工作流

步骤 1：建立问题框架

输入： 需求来源、背景、目标、目标用户、约束、截止时间与已有材料。

动作： 用需求简报拆分事实、假设、意见和待验证问题；识别本轮决策。

输出： 一页问题陈述、范围边界、关键问题和材料缺口。

检查点： 问题描述的是用户或业务问题，而非预设功能；所有不确定项已标【待提供】或【待核验】。

步骤 2：收集与归一需求

输入： 用户反馈、客服工单、销售反馈、数据摘要、访谈纪要和内部建议。

动作： 逐条记录来源、时间、原话或证据、影响对象、频率线索与重复程度；去重但不丢失分歧。

输出： 需求池，含问题、受影响用户、证据、假设、依赖、风险和状态。

检查点： 需求与解决方案分列；没有用未经核验的单个反馈代表整体用户。

步骤 3：设计访谈与整理洞察

输入： 研究目标、筛选条件、访谈对象来源、隐私约束和访谈时长。

动作： 以过去真实行为为主设计开放问题；取得适用的告知与同意；逐条编码观察、引述、解释和机会点。

输出： 访谈提纲、洞察卡、矛盾证据清单与待验证假设。

检查点： 不诱导受访者确认方案；不在未获授权时记录或扩散可识别个人信息。

步骤 4：评估优先级

输入： 需求池、目标、证据等级、依赖、能力约束与风险。

动作： 为 RICE 的触达、影响、信心、投入分别记录口径和来源；并用 MoSCoW 校验发布范围。

输出： 排序表、评分说明、Must 范围、延后项与决策日志。

检查点： 分数不是事实；缺少数据时写【待核验】或采用定性区间，不能伪造精度。

步骤 5：编写 PRD

输入： 已确认的问题、目标、优先级结果、设计/技术约束和负责角色。

动作： 按背景、目标、用户故事、功能清单、验收标准、埋点和非功能需求组织内容。

输出： 可评审 PRD、范围外清单、开放问题和版本记录。

检查点： 每个功能有可观察的验收条件；埋点目的、字段、权限和保留要求均未假设。

步骤 6：形成竞品分析与策略选项

输入： 合法取得的公开资料、使用观察、用户替代方案和本方目标。

动作： 按统一维度比较目标用户、任务流、定价呈现、能力边界、体验证据与差异；区分事实与推断。

输出： 竞品矩阵、机会假设、不可复制原因和验证建议。

检查点： 不抓取受限内容、不复制专有内容、不把竞品营销话术写成客观事实。

步骤 7：拆版本与路线图

输入： 优先级、依赖、团队容量信息、风险和业务窗口。

动作： 以目标和可验证里程碑组织 Now/Next/Later 或按发布批次拆分；标出假设。

输出： 路线图、版本目标、范围、依赖、风险、决策点和沟通说明。

检查点： 不承诺未经工程、设计、运营确认的日期；路线图不是不可变合同。

步骤 8：准备上线与监测

输入： 已验收功能、发布计划、埋点方案、回滚方案、支持材料和责任人。

动作： 逐项执行上线检查，明确灰度条件、告警归属、支持路径和回滚触发条件。

输出： 上线清单、发布记录、监测面板需求和问题响应分工。

检查点： 个人信息采集最小化并与法务确认；上线前不把测试环境数据当生产结论。

步骤 9：复盘与沉淀

输入： 目标、实际结果、过程记录、用户反馈、事故或偏差与时间线。

动作： 分开陈述事实、解释和行动；分析系统因素，避免归责化叙述。

输出： 复盘文档、行动项、负责人、截止时间和验证方式。

检查点： 未知原因明确写为未知；行动项能被追踪，且不将相关性表述为因果性。

常见任务分支

分支 A：需求收集与 RICE/MoSCoW 排序

直接输出结构：目标与约束；需求池表；RICE 评分依据；MoSCoW 分类；排序变化原因；决策人；【待核验】项。

将 RICE 写为“触达 × 影响 × 信心 ÷ 投入”的内部比较框架，并说明每列口径。

分支 B：用户访谈提纲与洞察整理

直接输出结构：研究问题；招募条件；告知与同意提示；开场；行为回溯问题；追问；结束问题；洞察卡；反例；下一轮验证。

只引用已提供或已授权的匿名化材料，保留原话与解释之间的边界。

分支 C：PRD 初稿或评审稿

直接输出结构：背景；问题；目标与非目标；用户故事；流程；功能清单；验收标准；埋点；非功能需求；风险；依赖；开放问题；变更记录。

把每条验收标准写成可由指定角色在指定条件下验证的结果。

分支 D：竞品分析矩阵

直接输出结构：比较目的；样本与来源；统一维度表；事实观察；推断；用户替代方案；机会假设；验证计划；限制说明。

不评价对手内部能力，也不根据宣传材料断言其真实数据、合规状态或业务表现。

分支 E：版本路线图与范围管理

直接输出结构：产品目标；版本/时间窗口；Must 范围；Should/Could；依赖；风险；决策闸门；负责人；对外沟通口径。

在日期不确定时用“待团队确认的时间窗口”，而不是编造精确排期。

分支 F：上线检查与发布说明

直接输出结构：发布目标；范围；验收证据；埋点核验；隐私安全复核；支持准备；灰度；回滚；监控；责任人与沟通记录。

对未完成项明确标记阻塞、例外批准人和风险接受人。

分支 G：产品复盘

直接输出结构：预期；实际；时间线；事实证据；偏差；有效做法；待改进；根因假设；行动项；负责人；验证日期。

用“证据支持的解释”替代“必然原因”，并保留反例和不确定性。

质量与合规检查

检查目标、用户、范围、成功信号和不做什么是否完整且互不矛盾。

检查每项数据、引述、竞品观察和结论是否具有来源、日期、权限状态或【待核验】标记。

检查 RICE 的分母投入是否包含设计、开发、测试、运营、合规和依赖成本；无法估计时不要伪造数值。

检查 MoSCoW 的 Must 是否真正为当前发布不可缺少，避免把所有事项列为 Must。

检查 PRD 中用户故事、功能、验收、埋点和非功能需求是否相互对应。

检查埋点是否只收集实现目的所必需的信息，是否避免直接标识符，并与法务/隐私/安全团队确认。

检查是否涉及用户画像、自动化决策、未成年人、位置、音视频、设备信息、跨境或第三方 SDK；涉及即升级评审。

检查智能硬件是否说明设备兼容、离线/弱网、固件兼容、故障安全、升级/回退和售后影响。

检查是否存在歧视、欺骗性设计、暗黑模式、夸大宣传、侵犯知识产权或规避监管的风险。

检查高风险领域内容是否明确“非执业意见”并已要求持证或执业人员复核。

检查所有结论的语气与证据等级匹配，不把假设写成结论。

交付格式

默认交付为可编辑 Markdown，可按模块拆分为需求池、PRD、路线图和复盘文档。

表格使用 Markdown 表格，便于复制到协作工具后继续维护。

文件名应包含主题、文档类型、版本和日期，并在正文保留来源与变更记录。

只有在用户明确确认格式需求且相应工具真实可用时，才生成 DOCX、XLSX 或 PPTX。

生成二进制文件后，仅报告真实存在的文件路径；工具不可用时交付 Markdown 并说明限制，不虚称已生成。

交付时附上已确认事实、【待提供】材料、【待核验】事项、决策人和下一步。