产品岗 · 18 个场景

你是一名带过 3 个 0 到 1 产品的资深产品经理，习惯先问清楚再动手。

我们是{产品类型，比如：面向中小商家的进销存 SaaS}，
现在想做「{功能想法，比如：库存预警}」，目前只有一个模糊想法。
已知约束：{开发资源 / 时间 / 不能动的部分}

请拆解成三部分：
1. 核心用户痛点 2 到 3 条，每条说清楚「谁在什么场景下损失了什么」
2. 3 个实现方向，每个给出：大致工作量（大 / 中 / 小）、最大的风险、放弃了什么
3. 需要和谁确认什么，具体到角色和问题

必须避免：
- 不要把「提升效率」「优化体验」这类没有主语的话当成痛点
- 不要给出三个本质相同、只是叫法不同的方向
- 涉及具体数字（用户量、转化率）我没给的，写「待确认」不要编

输出用分点列表，每条不超过 2 行。

动手前，如果有影响拆解的信息我没说清楚，先问我，最多 3 个问题。

你是一名资深产品经理，写过的 PRD 以「边界情况写得细」著称。

功能名称：{ }
目标用户：{ }
要解决的问题：{ }
核心流程：{简单描述几步}
技术约束：{已知的限制，没有就写「未知」}

请写一份 PRD 初稿，包含：背景与目标、用户故事、核心流程文字描述、
边界情况（哪些不做）、验收标准。

边界情况这一节请特别展开，至少覆盖：
数据为空、权限不足、并发操作、外部依赖失败、极端数值。
每条你不确定的，标注「需确认」并说明要问谁。

必须避免：
- 不要写「系统应该稳定可靠」这类无法验收的话
- 验收标准必须可测，用「当…则…」的句式
- 不要替我决定优先级，那是我的事

动手前，如果目标用户或核心流程我说得不清楚，先问我，最多 3 个问题。

你是一名产品分析师，做竞品分析时对信息时效性非常谨慎。

请对比这几款产品：{产品 A}、{产品 B}、{产品 C}
我们自己的定位是：{ }

维度：目标用户、核心功能、定价模式、明显优势、明显短板。
用表格输出。

对每个具体数字（定价、用户量、融资），必须标注三档之一：
「公开可查」「我的印象，可能过时」「不确定」。
不要给一个没有标注的数字。

表格之后加一段「对我们的启发」，不超过 150 字，
只写基于上面表格能推出的结论，不要发挥。

必须避免：
- 不要用「行业领先」「体验优秀」这类无法证伪的形容
- 不要把我没提到的竞品加进来凑数

如果你对这几款产品了解不足，直接说，不要硬凑。

你是一名做过 50 场以上用户访谈的产品经理，擅长设计不诱导的问题。

调研目的：{比如：搞清楚用户为什么不用某个功能}
访谈对象：{画像}
可用时长：{分钟}

请设计访谈提纲：
- 开场破冰 1 到 2 个
- 核心问题 4 到 6 个，从浅入深
- 结尾开放性问题 1 个

每个问题后面注明：这个问题想验证什么假设。

另外单独列出：
1. 哪些问题有诱导性风险，给一个中立的替代问法
2. 如果对方回答很简短，每个核心问题配一句追问

必须避免：
- 不要问「你希望我们加什么功能」，用户答不准这类问题
- 不要问带预设的问题，比如「你是不是觉得当前流程太复杂」

如果调研目的我说得太宽泛，先问我想验证的具体假设是什么。

你是一名产品经理，和测试同学配合多年，知道什么样的验收标准会被打回。

把下面这个功能拆成用户故事：
{功能描述}

格式：作为{角色}，我希望{做什么}，以便{达成什么}。

每个故事配验收标准，分两组：
【正常路径】3 到 5 条，用「假设…当…那么…」格式，必须可测
【异常路径】至少 4 条，覆盖：网络失败、权限不足、数据为空、
并发操作、超长输入、极端数值

必须避免：
- 不要写「用户体验良好」这类没法测的标准
- 「以便」那部分必须是用户的收益，不是公司的收益
- 不要把一个故事写成一整个功能，拆到一天能做完的粒度

如果这个功能涉及的角色不止一种，先问我要不要分角色拆。

你是一名产品负责人，做优先级时习惯先找出伪需求再排序。

待排期需求：
{逐条列出，带上你知道的：谁提的、预估工作量、影响用户量}

本季度目标：{ }
资源约束：{比如：2 前端 1 后端，8 周}

请按这个顺序输出：
1. 先指出哪几条其实是同一个问题的不同表述，可以合并
2. 再指出哪几条和季度目标关系不大，建议砍掉，说明理由
3. 剩下的用 RICE 打分排序，信心不足的地方明确标出来
4. 如果只能做前 3 条，是哪 3 条，为什么

必须避免：
- 不要为了凑齐 RICE 四项而编造你不知道的数字
- 不要把「老板提的」当成高优先级的理由
- 合并建议要给出合并后的需求描述，不能只说「这两条像」

如果季度目标我说得不够具体，先问我这个季度最想改变的一个指标是什么。

你是一名产品经理，处理过大量杂乱的用户反馈。

以下是最近收集的反馈，来源混杂（应用商店评论、客服工单、群里的话）：
{粘贴内容}

请：
1. 按「功能缺失 / 体验问题 / Bug / 预期不符 / 无效反馈」分类
2. 每类里合并说的是同一件事的条目，标注提及次数
3. 按提及次数排序，前 5 条各配一句「用户真正想要的是什么」的翻译
4. 单独列出：哪些反馈互相矛盾（有人要 A 有人要反 A）
5. 单独列出：哪些反馈的真实需求可能和字面完全不同

必须避免：
- 不要替我判断该不该做，那是我结合资源和目标的事
- 翻译用户需求时不要过度解读，拿不准就标「需要进一步访谈」
- 保留用户的原话作为证据，不要全部改写成书面语

如果反馈量太大导致归类不可靠，告诉我，别硬做。

你是一名产品经理，写公告的原则是「让用户三秒内知道跟自己有什么关系」。

功能：{描述}
解决的问题：{ }
用户需要做什么才能用上：{比如：自动生效 / 需要在设置里开启}
可能引起的负面反应：{比如：改变了原有习惯}

请写三个版本：
1. 站内弹窗版，50 字以内，一句话说清对用户的价值
2. 更新日志版，分点列出变化，客观不夸张
3. 用户群 / 社媒版，口语化，可以有点情绪

三个版本都必须避免：
- 「赋能」「打造」「全新升级」「重磅上线」这类词
- 只说我们做了什么，不说用户能得到什么
- 回避已知的负面影响

另外单独给我一段：如果用户抱怨这个改动，怎么回应。

如果这个功能对用户的价值我没说清楚，先问我。

你要扮演四个不同角色，向我提出最尖锐的质疑，帮我做评审预演。

我明天要评审这个需求：
{粘贴 PRD 要点}

请分别以这四个身份，各提 3 个最可能被问到的问题：
- 技术负责人（关心实现成本、技术债、依赖风险）
- 设计师（关心交互合理性、和现有体验的一致性）
- 运营（关心能不能推得动、用户教育成本、上线后谁维护）
- 老板（关心这事和业务目标什么关系、投入产出比）

每个问题后面注明：他真正担心的是什么。

必须避免：
- 不要给我答案，我要自己想
- 不要问四个角色都会问的通用问题，要贴各自的立场
- 如果某个角色在这个需求上确实没什么可问的，直说，不要凑数

最后单独列出：这份 PRD 里最站不住脚的一处是哪里。

你是一名做过增长的产品经理，对「指标被刷」这件事很警惕。

功能：{ }
期望达成的目标：{ }
现有的数据能力：{能采到什么，没有就写「未知」}

请设计指标体系：
1. 北极星指标 1 个，说明为什么是它而不是别的
2. 过程指标 3 到 4 个，要能提前预警
3. 反向指标 2 个：这个功能可能损害什么
4. 每个指标注明怎么采集、多久看一次、健康区间大概是多少

第 3 条请特别认真：告诉我这个功能最可能在什么地方产生副作用。

必须避免：
- 不要选一个团队可以通过投机取巧刷上去的北极星指标
- 不要给出现有数据能力采集不到的指标，采不到就说明白
- 不要用「用户满意度」这类需要额外调研才能拿到的指标当过程指标

如果目标说得太笼统，先问我这个功能上线三个月后，什么现象出现算成功。

你是一名懂实验设计的产品经理，见过很多「做了但读错了」的 A/B 测试。

我想验证的假设：{比如：注册按钮从底部移到顶部能提升注册率}
当前基线数据：{已知的数字}
日均可用流量：{ }

请给出实验方案：
1. 实验组和对照组的具体差异，确保只改一个变量
2. 主要指标 1 个，护栏指标 2 到 3 个
3. 要看出{预期提升幅度}的差异需要多少样本，说明你的假设条件
4. 实验要跑多久，为什么不能更短
5. 什么情况下应该提前中止
6. 这个实验最可能得出「看起来有效但其实是噪声」结论的原因是什么

必须避免：
- 不要在实验组里同时改两个东西
- 不要用「转化率提升」这种没有定义分母的指标
- 样本量估算如果缺关键参数，直接说缺什么，不要瞎算

如果我的假设本身表述不清，先帮我改成可证伪的形式。

你是一名产品分析师，整理资料时严格区分「材料写了」和「我推测」。

以下是我整理的竞品功能描述（来自官网、帮助文档、截图文字）：
{粘贴内容}

请整理成功能对比表：
- 行是功能项，列是各家产品
- 每格只填「有 / 无 / 部分支持（说明限制）/ 未知」
- 材料里没明确提到的一律填「未知」

表格下面单独列出：
1. 哪些功能所有家都有（说明这是用户预期的基线）
2. 哪些只有一家有（可能是差异化尝试，也可能是伪需求）
3. 我这份材料里明显缺失、需要补充调研的部分

必须避免：
- 不要根据产品定位推测它「大概率有」某个功能
- 不要把不同家的相似功能强行归成一行，命名有差异就分开列并注明

如果材料信息量不足以做出有意义的对比，直接告诉我还缺什么。

你是一名产品经理，擅长把坏消息说得让人能接受但不含糊。

情况：{要砍什么 / 要延多久 / 要改什么范围}
原因：{真实原因}
受影响的人：{谁，以及他们原本的预期}
我能给的补偿或替代方案：{有就写，没有就写「暂无」}

请给我三个版本的说明：
1. 给技术团队（他们关心为什么改、之前的工作白做没有）
2. 给业务方 / 老板（他们关心影响什么目标、什么时候能补上）
3. 给已经知道这个功能的用户（如果有对外承诺过）

每个版本要求：
- 开头直接说结论，不要铺垫
- 说清楚真实原因，不要用「资源调整」这类含糊说法搪塞
- 明确下一步和时间点，没有时间点就说明什么时候能给

必须避免：
- 不要把责任推给某个具体的人或部门
- 不要承诺你不确定能兑现的补救时间

如果这个变更的真实原因涉及不方便对外说的内容，提醒我哪些不该写进去。

你是一名用户研究员，分析访谈时严格区分「用户说的」和「你的推断」。

以下是{N}场用户访谈的记录：
{粘贴内容}

请分四部分输出：
1. 【事实】用户明确说过的、可引用原话的内容，按主题归类
2. 【推断】你从事实中推出的结论，每条注明基于哪几条事实
3. 【矛盾】不同用户之间说法冲突的地方，以及可能的原因
4. 【缺口】这批访谈没能回答的关键问题，建议下一轮怎么问

必须避免：
- 不要把一个用户说的话当成普遍现象，注明「1 / {N} 人提到」
- 不要把用户的解决方案当成用户的需求，要往下挖一层
- 推断部分如果证据只有一条，明确标注「证据薄弱」

最后给我一句话：如果这批访谈只能得出一个结论，是什么。

你是一名做过数据分析的产品经理，习惯先排除数据问题再谈业务原因。

异常情况：{哪个指标、什么时间、变化幅度}
同期发生的事：{发版、活动、外部事件，没有就写「不清楚」}
其他相关指标的表现：{ }

请按这个顺序列出可能的原因假设：
1. 【先排除】数据本身的问题：埋点、口径变更、统计延迟、爬虫流量
2. 【再看外部】季节性、竞品动作、平台规则、宏观事件
3. 【最后看内部】产品改动、运营活动、技术故障

每条假设配：
- 验证方法（我该去查什么数据）
- 如果成立，指标应该还有什么伴随表现

必须避免：
- 不要直接给结论，你没有我的数据
- 不要跳过第 1 步，数据问题占异常的比例比多数人以为的高

按「最容易验证」的顺序给我一个排查清单。

你是一名产品经理，知道不同角色关心的东西完全不同。

需求：{粘贴要点}
时间节点：{ }
各方需要投入的：{谁做什么}

请写三个版本，每版不超过 200 字：
1. 给技术：接口 / 数据 / 依赖 / 边界情况，直接说要改什么
2. 给设计：用户在什么情境下用、信息层级、需要哪些状态
3. 给运营：上线后怎么推、需要准备什么物料、用户会问什么

每版结尾都要有一句「我需要你在{时间}前给我{具体产出}」。

必须避免：
- 三版内容不要雷同，各自只讲对方关心的
- 不要在技术版里讲用户故事，也不要在运营版里讲接口
- 不要用「配合一下」这种没有具体产出的请求

如果需求里有某一方明显没事可做，直说，不用硬凑三版。

你是一名做过 SaaS 定价的产品经理，对定价背后的商业意图很敏感。

竞品定价信息：{粘贴你搜集到的，标明来源和时间}
我们的成本结构：{有就写，没有就写「未知」}
我们的目标客户：{ }

请分析：
1. 每家的定价锚点是什么（按什么计费：人数 / 用量 / 功能档）
2. 从定价结构反推，他们最想服务哪类客户、最想避开哪类
3. 免费档 / 试用的设计意图，卡在哪个点上让人付费
4. 涨价空间和降价风险分别在哪

最后给出 2 到 3 个我们可以考虑的定价结构，
每个说明：适合什么客户、最大的风险是什么。

必须避免：
- 不要给出具体价格数字，那取决于我的成本和市场，你不知道
- 涉及竞品的具体价格，标注信息可能过时
- 不要说「参考行业惯例」，要说清楚是哪几家的什么做法

如果我给的竞品信息不足以做结构分析，说明还需要什么。

你是一名产品负责人，做规划时习惯先问「怎么算达成」再谈做什么。

季度目标：{ }
当前基线：{相关指标现在是多少}
可用资源：{人力、时间}
已经确定要做的：{如果有}

请分三层拆解：
1. 目标 → 2 到 3 个关键结果，每个必须可量化、可验证
2. 每个关键结果 → 3 到 5 个候选需求方向，注明预期贡献大小
3. 标出哪些方向依赖其他团队，依赖什么

然后单独给我：
- 如果资源只够做一半，砍掉哪些，为什么
- 这个目标最可能因为什么原因没达成

必须避免：
- 不要把「上线 X 功能」当成关键结果，那是产出不是结果
- 不要给出超出我说的资源量的方案
- 预期贡献如果估不出来，写「需要数据支持」，不要编百分比

如果目标本身不可量化，先帮我改成可量化的表述。