定位：入门→中级→高级产品，自学知识库+速查+背诵手册
结构总览
产品基础认知（1～40）
用户研究与需求分析（41～90）
产品设计与原型交互（91～160）
产品文档体系（161～200）
迭代管理与跨团队协作（201～240）
数据分析与指标体系（241～280）
B端产品专项（281～320）
C端产品专项（321～360）
商业、增长与运营联动（361～390）
线上故障、风控合规（391～420）
AI产品能力（421～440）
项目复盘、行业与竞品分析（441～470）
大高频（471～500）
一、产品基础认知（1～40）
-
1、产品经理是什么？ 连接用户、业务、研发、运营，负责发现问题、定义方案、推动落地、衡量业务结果的岗位。
-
2、产品经理不做什么 不写业务代码、不输出UI视觉稿、不负责测试执行，不直接管理团队人员。
-
3、产品经理与项目经理区别 产品确定做什么、为什么做；项目经理管控排期、资源、风险，保障按时交付。
-
4、三类主流产品岗位 C端面向普通消费者；B端面向企业/商户；G端面向政务机构。
-
5、C端产品核心目标 用户体验、用户规模、用户粘性、用户增长、口碑传播。
-
6、B端产品核心目标 业务闭环、降本增效、流程标准化、数据准确、系统稳定。
-
7、G端产品核心目标 政策合规、数据安全、可追溯、流程标准化、运维稳定。
-
8、AI产品经理核心定位 不需要深度钻研算法底层，重点做场景挖掘、模型封装、业务落地、价值衡量。
-
9、产品决策三角模型 用户价值、商业价值、技术可行性，所有需求必须三者权衡取舍。
-
10、用户价值含义 解决用户真实痛点，降低用户操作成本，提升用户使用意愿。
-
11、商业价值含义 营收增收、运营降本、用户沉淀、构建壁垒、完成战略卡位。
-
12、技术可行性评估要点 现有架构能力、研发人力成本、改造风险、迭代周期。
-
13、MVP最小可行产品定义 使用最少的核心功能验证业务假设，不等于粗制滥造半成品。
-
14、PMF产品市场匹配 产品能力匹配市场真实需求，用户自发留存、复购、主动传播。
-
15、KANO卡诺模型5类需求 基本型需求、期望型需求、兴奋型需求、无差异需求、反向需求。
-
16、基本型需求特征 用户刚需底线，缺失会产生差评，优化升级不会提升满意度。
-
17、期望型需求特征 常规业务需求，功能越完善，用户满意度越高。
-
18、兴奋型需求特征 用户不会主动提出，上线后大幅提升好感，缺失不会引发不满。
-
19、用户画像作用 抽象目标用户集合，用于统一团队对目标用户的认知。
-
20、用户旅程地图作用 完整还原用户全流程行为，定位体验卡点与机会点。
-
21、痛点定义 用户真实存在，愿意付出时间、金钱、精力去解决的问题。
-
22、伪需求定义 用户直接给出的解决方案，并不是背后真正要解决的问题。
-
23、爽点定义 用户诉求被满足之后，获得即时愉悦感受。
-
24、痒点定义 用户内心向往，但不属于刚需，用来提升体验好感。
-
25、产品护城河类型 网络效应、数据壁垒、品牌壁垒、成本壁垒、专利壁垒。
-
26、网络效应含义 用户规模越大，产品整体价值越高，社交类产品典型壁垒。
-
27、SWOT分析用法 优势、劣势、机会、威胁，用于产品竞争格局分析。
-
28、PEST分析用法 政策、经济、社会、技术，用于宏观行业环境研判。
-
29、北极星指标 产品唯一最核心指标，所有迭代工作围绕该指标进行优化。
-
30、OKR与KPI区别 OKR用来定方向目标；KPI用于结果考核，二者不能互相替代。
-
31、ROI投入产出比 判断需求要不要投入资源的重要参考依据。
-
32、同理心的含义 同时站在用户、业务方、研发、设计多方视角思考问题。
-
33、取舍能力的重要性 资源永远有限，拒绝需求比承接需求更考验产品能力。
-
34、沟通的本质 对齐各方认知、达成共识，不是辩论和说服对方服从自己。
-
35、沉没成本误区 已经投入的人力时间，不能作为继续推进错误需求的理由。
-
36、幸存者偏差 不能用少量活跃用户反馈，代表全部用户群体诉求。
-
37、现象和根因区分 现象是表面问题，产品需要挖掘并解决根因而非只处理表象。
-
38、产品认知闭环 提出假设→落地实现→获取结果→复盘迭代。
-
39、产品成长4个层级 执行交付、定义问题、方案决策、战略布局。
-
40、人人都是产品经理 属于思维理念，不等于岗位没有门槛，人人都可以直接上岗。
二、用户研究与需求分析（41～90）
-
41、需求的六大来源 用户反馈、业务方提报、数据异常、竞品参考、战略拆解、内部员工建议。
-
42、常见用户反馈渠道 客服工单、应用商店评论、社群、用户访谈、问卷、行为埋点数据。
-
43、业务方提交的是诉求，不是成品需求 产品需要做翻译、甄别，转化为可落地产品需求。
-
44、竞品功能不能直接照搬 竞品做了某功能，要结合自身业务目标判断是否需要做。
-
45、数据异常只是现象，不等于需求 需要深挖背后业务根因再输出方案。
-
46、内部员工的使用感受仅作参考 不能直接等同于普通用户真实诉求。
-
47、战略需求处理方式 自上而下拆解，拆成可落地、可量化的产品功能。
-
48、需求收集不等于全盘接收 需要做过滤、去重、真伪甄别。
-
49、两类痛点处理策略 高频小痛点优先迭代；低频大痛点做专项版本处理。
-
50、付费用户反馈权重更高，但不能只服务付费用户 需要兼顾存量免费用户。
-
51、常见伪需求场景 用户直接告诉产品“我想要XX按钮”，却没有说明要解决什么问题。
-
52、同一个诉求背后可以有多组真实需求 需要结合使用场景区分。
-
53、批量突发用户反馈 优先区分是个别bug还是普遍性体验问题。
-
54、存量用户与新用户需求经常冲突 需要做权衡取舍。
-
55、需求具备时效性 业务、用户、外部环境变化，需求也会随之改变。
-
56、定性研究特点 小样本，挖掘用户动机原因；代表手段：用户访谈、现场观察。
-
57、定量研究特点 大样本统计，看占比、规模；代表手段：问卷、行为数据分析。
-
58、用户访谈样本数量 一般8‑12人即可达到信息饱和，不需要海量样本。
-
59、用户访谈原则 多问为什么，避免引导式提问，不要替用户回答问题。
-
60、可用性测试 让用户操作原型，重点记录卡顿、犹豫、放弃操作的节点。
-
61、问卷调研注意事项 问卷不宜过长，规避引导性问题，选项完整无遗漏。
-
62、焦点小组优缺点 适合收集群体态度，容易产生从众偏差。
-
63、现场观察法 B端产品非常高效，实地观察用户真实工作场景。
-
64、行为数据优先级高于口头反馈 用户实际行为比口头描述更加真实可信。
-
65、NPS净推荐值 衡量用户向他人推荐产品的意愿，反映产品口碑。
-
66、CSAT用户满意度 衡量单次使用体验的满意程度。
-
67、CES用户费力指数 衡量用户完成任务需要付出的操作成本。
-
68、定性结论需要定量做验证 小样本调研结论，不能直接全量推广。
-
69、访谈用户需要分层 覆盖新用户、活跃、沉睡、流失、付费不同群体。
-
70、场景三要素 用户角色、所处环境、要达成的业务目标。
-
71、脱离真实场景设计出来的功能，大概率是自嗨。
-
72、用户故事标准模板 作为【角色】，我希望【操作】，以便【获得什么价值】。
-
73、流失用户访谈价值很高，但触达难度大，可通过问卷激励召回。
-
74、竞品分析不是罗列功能清单，核心是拆解对方业务目标与取舍逻辑。
-
75、竞品的三类划分 直接竞品、间接竞品、潜在竞品。
-
76、竞品分析输出重点 机会点、风险点、我方差异化策略。
-
77、竞品对比要对齐版本与目标用户，禁止跨维度对比。
-
78、警惕竞品表面效果 很多上线功能后台数据很差，只是前端展示好看。
-
79、行业报告用来看大趋势，不能直接拿来当做产品方案。
-
80、需求筛选三问 是否真实、是否高频、是否具备业务价值。
-
81、无效需求典型特征 频次极低、受众小众、开发成本高、业务收益小。
-
82、需求优先级四象限 重要紧急、重要不紧急、紧急不重要、不紧急不重要。
-
83、线上bug修复优先级高于新增业务功能。
-
84、合规类需求优先级最高，不允许降级延后。
-
85、大需求拆解原则 大拆小、复杂拆简单，一次性做不完就分多迭代落地。
-
86、严防需求蔓延、镀金，控制迭代范围。
-
87、迭代中期开启需求冻结，不随意接纳临时新增需求。
-
88、小众个性化需求，不要做成通用功能，优先配置化、白名单实现。
-
89、所有需求落地前，要明确验收标准与衡量指标。
-
90、需求分析最终目的：做对的事，而不是把事情做对。
三、产品设计与原型交互（91～160）
-
91、原型核心作用 可视化业务逻辑，对齐团队认知，降低沟通成本。
-
92、低保真原型适用场景 需求初期梳理流程、内部评审讨论方案。
-
93、高保真原型适用场景 交付UI、测试、研发，还原交互细节。
-
94、原型绘制原则：逻辑优先，流程闭环，表达清晰。
-
95、页面通用5种状态 初始态、加载态、空数据态、正常数据态、异常报错态。
-
96、任何用户操作必须给到反馈：成功、失败、加载、报错。
-
97、禁止无返回、无提示、无兜底的裸奔交互逻辑。
-
98、弹窗设计要点 用途单一、操作简单、支持关闭、不要遮挡核心业务内容。
-
99、表单设计核心要点 必填项标识清晰、输入限制、实时校验、错误文案通俗易懂。
-
100、高危操作必须增加二次确认 删除、注销、退款、解绑、批量清空。
-
101、列表页面必备要素 分页、筛选、排序、搜索、刷新、空状态。
-
102、详情页设计要点 数据完整、业务状态清晰、操作入口位置合理。
-
103、步骤流程页面 步骤展示、进度可视、支持回退，允许中途暂停。
-
104、权限控制设计 不同角色看到不同菜单、按钮、业务数据。
-
105、敏感数据脱敏 手机号、身份证、银行卡号展示脱敏处理。
-
106、页面跳转必须闭环：进得去，出得来，回得去。
-
107、新手引导原则：轻量化，不强制打扰用户。
-
108、功能入口排布逻辑：高频外露，低频收起收纳。
-
109、C端交互设计侧重点 操作极简，降低用户学习成本，注重情感化反馈。
-
110、B端交互设计侧重点 操作效率，支持批量操作、快捷键，严谨校验防误操作。
-
111、按钮4种层级区分 主按钮、次按钮、文字按钮、禁用按钮，层级不能混乱。
-
112、隐藏元素的三种方案 display:none完全移除；visibility:hidden占位隐藏；opacity:0透明可交互。
-
113、移动端设计注意 按钮尺寸足够，避免误触，适配横竖屏。
-
114、后台系统页面 适配多分辨率，表格自适应，字段完整展示。
-
115、时间展示规范 统一年月日时分秒，统一相对时间格式。
-
116、业务状态标签样式、文案全产品保持统一。
-
117、避免重复入口、冗余页面、无效跳转链路。
-
118、千人千面概念（C端） 根据用户特征展示差异化内容。
-
119、标准化概念（B端） 统一流程规则，全员使用同一套业务逻辑。
-
120、C端埋点侧重 用户点击、停留、转化、行为路径。
-
121、B端埋点侧重 操作耗时、错误率、流程办结效率。
-
122、C端迭代特点：小步快跑，快速试错。
-
123、B端迭代特点：优先稳定，流程闭环，谨慎变更。
-
124、C端页面跳转层级尽量控制在3级以内，减少用户路径。
-
125、B端允许更深层级，优先保证业务流程完整准确。
-
126、C端文案：通俗口语化，规避专业术语。
-
127、B端文案：专业精准，无歧义，贴合业务规范。
-
128、C端适度使用动画过渡，提升体验感知。
-
129、B端弱化动画效果，优先加载速度和操作效率。
-
130、多角色产品一定要梳理清楚每个角色的权限与操作边界。
-
131、分支流程不能遗漏，尤其异常、失败、回退场景。
-
132、删除业务数据设计：优先软删除，保留记录，支持恢复，谨慎硬删除。
-
133、导入导出功能设计：大小限制、格式模板、进度提示、失败明细。
-
134、搜索功能设计：关键词联想、历史搜索、模糊匹配、无结果兜底页面。
-
135、筛选条件设计：默认值、多选、清除全部、记忆用户筛选状态。
-
136、分页两种模式：页码分页、滚动无限下拉，业务场景区分选用。
-
137、数据量巨大场景，禁止一次性全量加载，做分页/分批加载。
-
138、编辑页面：区分新增与编辑，默认回填原有数据。
-
139、未保存提示：用户输入内容未保存，跳转/关闭时弹出提醒。
-
140、国际化多语言产品：文案全部抽离，不硬编码，注意日期货币单位适配。
-
141、灰度、白名单功能设计：支持按用户、按群体开启关闭功能。
-
142、功能开关设计：业务功能可远程启停，应对线上突发问题。
-
143、过期、下线功能处理：入口隐藏，给出提示，引导替代方案。
-
144、权限粒度划分：菜单权限、操作按钮权限、行数据权限、字段权限。
-
145、无权限页面兜底：提示无权限，不要空白页面或者直接报错。
-
146、第三方对接场景：对接失败、超时、回调异常的兜底逻辑必须设计。
-
147、表单防重复提交：点击后按钮置灰，防止用户多次点击重复提交。
-
148、文件上传：大小、格式限制，进度条，上传失败重试。
-
149、下载功能：权限校验，大文件异步下载，生成任务记录。
-
150、消息通知区分：站内信、弹窗提示、推送通知，不同等级消息选择对应渠道。
-
151、消息已读未读逻辑、全部已读、消息红点清零逻辑完整闭环。
-
152、日历、选择器组件：时区问题，跨时区业务一定要统一服务端时间。
-
153、金额类字段：保留小数位数，单位统一，防止精度丢失。
-
154、编码ID类字段：禁止用户修改，后端强校验。
-
155、列表排序：支持按时间、按数量，记住用户排序选择。
-
156、复制功能：一键复制，复制成功提示。
-
157、二维码展示：支持长按/保存图片，适配不同尺寸。
-
158、预览功能：图片、文件在线预览，无法预览给出提示。
-
159、产品设计自查清单：正向流程、分支流程、异常流程、边界数据、权限、空状态。
-
160、原型交付一定要附带文字备注，写明特殊交互与业务规则。
四、产品文档体系（161～200）
-
161、PRD产品需求文档 产品最核心交付物，定义功能、业务逻辑、全部规则。
-
162、BRD商业需求文档 面向管理层，讲市场背景、商业目标、投入收益。
-
163、MRD市场需求文档 分析市场环境、用户、竞品，论证需求来源。
-
164、简易需求说明书 小型迭代小功能，替代完整版PRD。
-
165、版本迭代说明文档 记录每个迭代新增、变更、修复内容，同步团队。
-
166、复盘文档 记录项目问题、根因、经验、后续优化方案。
-
167、埋点文档 定义埋点事件、触发时机、上报参数，给数据开发使用。
-
168、权限设计文档 角色、菜单、按钮、数据权限完整规则。
-
169、业务流程文档 主流程、分支、异常流程的流程图与文字说明。
-
170、风控规则文档 拦截、审核、处罚、告警全套业务规则。
-
171、运营规则文档 活动、积分、权益、优惠券、奖励发放逻辑。
-
172、接口需求说明 前后端交互字段、入参、出参、错误码规则。
-
173、用户操作手册 面向业务人员、客服，教如何操作系统功能。
-
174、测试需求说明 给到测试同学，明确重点场景与测试范围。
-
175、上线通告文档 同步客服、运营、业务方，告知新版本变更点。
-
176、故障记录文档 记录线上故障现象、根因、修复方案、预防措施。
-
177、调研报告文档 用户调研、市场调研输出的结论文档。
-
178、竞品分析文档 竞品拆解、机会点、风险、差异化建议。
-
179、PRD开篇版本记录 记录版本号、修改人、修改时间、变更内容。
-
180、PRD需求背景 当前现状、现存痛点，说明为什么要做这个需求。
-
181、PRD需求目标 业务目标、数据目标、用户价值目标，可量化。
-
182、PRD适用范围 哪些用户、哪些端、哪些业务场景会生效。
-
183、PRD角色说明 涉及哪些用户角色，每个角色权限范围。
-
184、PRD业务流程图 主流程、分支、异常流程全部画出来。
-
185、PRD字段规则 每个字段含义、默认值、输入限制、校验规则。
-
186、PRD状态流转 所有业务状态的切换条件，不能出现死状态。
-
187、PRD异常场景 网络异常、无数据、权限不足、第三方失败。
-
188、PRD验收标准 功能、数据、体验的可落地验收条件。
-
189、PRD风险备注 潜在风险、待定事项、特殊说明。
-
190、文档写作核心原则：无歧义、无遗漏、无矛盾、可落地、可验收。
-
191、文档禁止模糊词汇：大概、尽量、可能、差不多。
-
192、全文业务术语、字段、状态名称必须保持统一。
-
193、图文结合，多用表格、流程图降低阅读理解成本。
-
194、边界场景是bug高发区，文档必须写清楚边界条件。
-
195、文档版本管理，每次修改留痕，可追溯变更历史。
-
196、评审结束之后必须及时更新文档，保证文档与最终方案一致。
-
197、线上发生需求变更，必须同步更新对应文档，保持时效性。
-
198、文档不是个人草稿，属于团队公共资产，需要归档分类。
-
199、写文档要站在读者视角，考虑研发、测试、运营能不能看懂。
-
200、一份高质量文档可以减少大量重复沟通成本。
五、迭代管理与跨团队协作（201～240）
-
201、标准产品迭代全流程 需求收集→筛选评审→方案设计→文档原型→开发→测试→灰度→全量上线→复盘。
-
202、迭代周期参考 C端一般2周一个迭代；B端业务复杂，常使用4周迭代周期。
-
203、迭代启动会：确认迭代目标、迭代范围、资源与时间节点。
-
204、需求评审参与人员：产品、前后端研发、测试、UI、运营、业务方关键人。
-
205、需求评审目的：查漏补缺，统一所有人认知，提前识别风险点。
-
206、评审前必须输出完成的原型与文档，禁止裸评审。
-
207、评审提出的问题全部记录，会后更新方案和文档。
-
208、需求评审通过之后，进入需求锁定阶段，迭代内不随意改需求。
-
209、开发阶段，产品及时答疑，尽量集中答疑，减少碎片化打断研发。
-
210、需求变更处理：评估影响范围，同步全部相关人，更新文档原型。
-
211、提测准入条件：开发完成，产品内部走通主流程，文档原型齐全。
-
212、Bug分级定义：致命bug、严重bug、一般bug、轻微优化建议。
-
213、致命bug上线前必须全部修复，没有例外。
-
214、bug修复完成，要做回归测试，防止产生次生bug。
-
215、灰度发布：小部分用户放量，观察报错、数据、反馈，降低上线风险。
-
216、灰度验证无问题，再逐步放量走向全量上线。
-
217、上线之后同步客服、运营、业务方，告知功能变更与注意事项。
-
218、上线后监控重点：接口报错率、崩溃、业务数据、用户反馈。
-
219、迭代复盘：回顾目标，分析进度、问题、风险，输出后续改进动作。
-
220、每轮迭代聚焦1‑2个核心目标，不要迭代塞满大量无关功能。
-
221、紧急需求插队：评估对原有迭代的影响，各方确认之后再插队。
-
222、排期要尊重研发评估，不要强行压缩工期赶进度。
-
223、进度出现滞后，要提前向上预警，及时调整范围或者排期。
-
224、历史遗留问题，每轮迭代适量消化，不要无限堆积。
-
225、迭代质量优先级高于迭代速度，带病上线后患无穷。
-
226、产品与研发协作：尊重技术成本，正视技术难点，不要强制硬推高成本低收益方案。
-
227、研发提出技术阻碍，产品评估是否降级方案或者拆分到后续迭代。
-
228、产品和UI协作：对齐交互规范，统一组件库，减少重复设计。
-
229、产品和测试协作：明确验收标准，重视测试提出的异常场景问题。
-
230、产品与运营协作：对齐迭代目标，提前同步上线节奏，让运营可以配套活动。
-
231、产品与客服协作：新功能提前同步话术，客服高频反馈要回流需求池。
-
232、产品与业务方协作：倾听业务痛点，但不能完全听从业务拍脑袋诉求。
-
233、跨团队冲突处理：对事不对人，优先保障业务价值和线上稳定性。
-
234、开会原则：提前发议程，控制时长，会后输出明确结论与行动项。
-
235、能文档同步就不要开会，减少无效会议消耗团队精力。
-
236、重要决策全部留痕，避免事后认知不一致互相扯皮。
-
237、遇到卡点，自己无法推动时，及时向上求助，不要硬扛内耗。
-
238、资源不足的情况下，优先保住核心价值，裁剪次要功能。
-
239、跨部门协作最大难点是各方目标不一致，产品负责对齐统一目标。
-
240、优秀产品是团队润滑剂，不是指挥者，靠逻辑与价值获得支持。
六、数据分析与指标体系（241～280）
-
241、数据分析核心目的：发现问题、定位根因、识别机会、验证假设。
-
242、数据只能展示现象，不能直接给出解决方案，需要产品做解读。
-
243、数据分析拆解思路：总指标→拆分维度→细分场景→定位根因。
-
244、C端核心指标：DAU日活、MAU月活、新增用户、留存、转化率、时长、GMV、NPS。
-
245、DAU日活跃：单日独立用户打开使用产品的数量。
-
246、MAU月活跃：月度活跃用户，反映产品稳定用户盘子大小。
-
247、次日留存：新增用户第二天再次使用产品的占比，代表产品基础吸引力。
-
248、7日留存、30日留存：衡量产品中长期留人能力。
-
249、用户时长：单用户平均使用时长，代表产品用户粘性。
-
250、转化率：曝光‑点击‑参与‑付费逐层漏斗转化。
-
251、跳出率：进入页面立刻退出的用户占比，评估页面质量。
-
252、崩溃率、接口报错率，衡量产品整体稳定性。
-
253、B端核心指标：业务办结率、单条业务处理时长、操作出错率、流转效率。
-
254、B端重点关注人力成本下降、合规率提升。
-
255、北极星指标要求唯一，避免多个核心指标分散迭代方向。
-
256、辅助指标用来做参考，不能替代北极星指标做决策。
-
257、指标口径必须全局统一，统计逻辑变更要同步全部团队成员。
-
258、流量类指标：曝光、点击、访问、跳转、页面停留。
-
259、转化类指标：注册、授权、下单、支付、复购。
-
260、留存类指标：按渠道、按新老用户分层看留存数据。
-
261、商业指标：客单价、复购率、毛利率、投入产出ROI。
-
262、体验类指标：报错、卡顿、任务放弃率、操作耗时。
-
263、渠道指标：渠道新增数量、渠道留存、渠道转化效果，评估渠道质量。
-
264、功能指标：功能使用率、访问频次、操作成功率，评估功能价值。
-
265、看到数据异常排查顺序：确认统计口径→检查埋点是否异常→版本变更→bug问题→业务本身波动。
-
266、单日短期波动不等于长期趋势，需要看一段时间周期的数据。
-
267、同比：本期对比去年同期，消除季节周期带来的干扰。
-
268、环比：本期对比上一个周期，看短期变化趋势。
-
269、建立数据基线，知道正常数值区间，快速识别异常波动。
-
270、所有需求上线前就要定义好可量化的数据目标。
-
271、埋点设计原则：不要过度埋点，只埋业务需要分析的事件。
-
272、埋点三要素：事件名称、触发条件、上报参数。
-
273、区分事件埋点和页面浏览埋点，不要混淆。
-
274、A/B测试：同一群体分两组，不同方案对比数据，验证方案好坏。
-
275、A/B测试注意样本量要足够，运行足够周期，不要过早下结论。
-
276、不要拿小样本A/B测试结果直接全量推广。
-
277、区分相关性和因果关系：数据一起变化，不代表二者存在因果。
-
278、数据不能替代用户真实感受，数据和用户反馈要结合起来看。
-
279、需求上线后要做效果复盘，核对是否达成预设指标目标。
-
280、没有数据衡量价值的需求，需要谨慎评估是否要落地。
七、B端产品专项（281～320）
-
281、B端产品服务对象是组织、企业、商户，不是个人普通消费者。
-
282、B端存在决策者、使用者、付费者三者角色分离，要分别识别诉求。
-
283、决策者关心：降本、增收、风险、管控；使用者关心：操作简单，减少工作量。
-
284、B端产品第一优先级是业务闭环与稳定性，其次才是体验美观。
-
285、B端业务复杂，多角色、多部门参与，要理清各部门权责边界。
-
286、B端要高度重视权限体系：数据权限是B端最核心设计之一。
-
287、B端重视可追溯：关键操作日志，记录谁在什么时间做了什么操作。
-
288、B端高频操作优先做批量处理、导入导出，提升工作人员效率。
-
289、B端误操作代价高，删除、修改数据要强校验、留痕、可回滚。
-
290、B端业务流程经常存在分支、异常、审批流转，不能只设计理想主流程。
-
291、审批流设计要点：审批节点、审批人、驳回、转审、加签、会签、审批超时处理。
-
292、B端报表设计：筛选、导出、时间维度，支持多维度统计，满足业务对账。
-
293、B端看板：核心业务指标、待办任务、告警信息优先展示。
-
294、B端要兼容老业务历史数据，系统迭代不能破坏存量历史业务。
-
295、B端配置化思维：尽量做成后台可配置，减少频繁发版本改规则。
-
296、B端调研优先现场观察，到业务工位看真实工作流程，不要只听口头描述。
-
297、B端常见坑：过度定制化，每个客户一套逻辑，后期维护成本爆炸。
-
298、标准化与定制化平衡：通用逻辑产品内置，个性化用配置实现，尽量少硬编码定制。
-
299、SaaS产品B端：多租户隔离，租户之间数据互相隔离。
-
300、SaaS权限：租户管理员、普通成员、超级平台管理员三层权限区分。
-
301、B端接口重点关注幂等性，防止重复请求生成重复业务单据。
-
302、单据状态流转是B端核心，状态不能出现死循环、死数据。
-
303、B端对账逻辑：业务数据、财务数据要可以核对，差异要有差异报表。
-
304、B端告警机制：业务异常、超时、数量超限，推送告警给业务负责人。
-
305、B端删除业务记录优先软删除，保留数据，便于审计排查问题。
-
306、B端导入功能：模板下载、数据校验、错误行明细、部分成功部分失败处理。
-
307、B端导出大文件，不实时同步返回，改为异步任务，生成后下载。
-
308、B端不要追求极致极简，业务必要字段不能为了页面好看随意删减。
-
309、B端产品验收，要业务实际操作人员参与验收，不能只给领导评审。
-
310、B端迭代变更风险高，变更前评估存量业务影响，必要灰度小商户验证。
-
311、B端版本升级，需要做好旧功能兼容，不强制业务立刻切换新流程。
-
312、B端文档非常重要，业务规则复杂，文档要给到业务、运维、实施人员查阅。
-
313、B端实施交付：要考虑初始化配置、数据迁移、人员培训、上线切换方案。
-
314、B端要思考异常业务如何处理：业务失败、中途暂停、中途换人接手。
-
315、B端的报表不要只看总数，要支持下钻，定位明细数据。
-
316、B端表单：字段多是常态，做好分组折叠，必填非必填明确区分。
-
317、B端产品经理要懂基础业务领域知识，不用成为业务专家，但要看得懂业务单据。
-
318、B端客户需求区分：普遍客户需求纳入产品；个别客户需求走定制项目。
-
319、B端核心价值衡量：人均处理单据数量、平均处理时长、错误率下降幅度。
-
320、B端产品成长重点：理解业务流程、理解组织权责、把控配置与标准化平衡。
八、C端产品专项（321～360）
-
321、C端产品面向个体普通用户，付费决策者、使用者一般是同一个人。
-
322、C端用户没有耐心，核心路径尽量短，减少操作步骤。
-
323、C端重视用户感知体验，视觉、文案、动画反馈都会影响用户主观感受。
-
324、C端新用户是重点，做好新手引导，降低首次使用门槛。
-
325、C端拉新：渠道投放、分享裂变、广告、内容引流，带来新增用户。
-
326、C端留存：解决用户真实刚需，让用户愿意持续回来使用产品。
-
327、C端变现模式：广告、会员订阅、电商交易、虚拟道具增值服务。
-
328、C端裂变核心：用户愿意分享，需要给分享者和被分享者双向激励。
-
329、C端首页设计：突出核心功能、优质内容、重要活动入口。
-
330、C端注册登录：支持多种登录方式，降低注册门槛，游客模式可浏览部分内容。
-
331、C端个人中心：账号信息、设置、订单、权益、客服、退出登录完整链路。
-
332、C端内容类产品：信息流、推荐算法、内容审核、评论互动、举报。
-
333、C端交易电商类：商品、购物车、下单、支付、订单、售后退款、物流。
-
334、C端要做好弱网、网络错误的友好提示，不要直接抛出技术报错。
-
335、C端权限申请：定位、相册、通知推送，不要一打开APP就索要全部权限。
-
336、推送消息：区分营销推送与重要通知，提供推送开关，避免过度骚扰用户。
-
337、C端防沉迷、隐私合规：用户隐私协议，个人信息保护，未成年人模式。
-
338、C端分享能力：分享到微信、朋友圈等，做好分享卡片、分享兜底。
-
339、C端活动设计：规则要简单易懂，用户看得懂；奖励发放逻辑闭环，防薅羊毛。
-
340、C端活动风险：防刷、风控，防止黑产批量薅取平台奖励。
-
341、C端弹窗慎用，不要频繁弹窗打扰用户，非必要不弹强弹窗。
-
342、C端表单尽量少输入，多用选择、勾选，减少键盘输入。
-
343、C端账号体系：手机号登录，找回密码，换绑手机号，注销账号完整流程。
-
344、账号注销要符合法规，完成数据清理，解绑第三方账号。
-
345、C端评价系统：打分、文字评价、图片视频，评价展示、举报恶意评价。
-
346、C端搜索：联想词、热搜、纠错、无结果推荐相关内容。
-
347、C端个人隐私：头像昵称修改，个人信息查看与删除。
-
348、C端缓存策略：本地缓存浏览记录，同时提供清除缓存入口。
-
349、C端夜间模式、字体大小设置，适配不同用户使用习惯。
-
350、C端性能体验重点：启动速度、页面加载速度、滑动流畅度。
-
351、C端灰度策略：按百分比放量，按城市、用户标签灰度，控制风险。
-
352、C端版本兼容：要兼容旧版本APP，旧版本不能直接完全不可用。
-
353、C端分享拉新注意风控，识别机器账号，避免虚假新增数据。
-
354、C端用户分层：新用户、活跃、沉睡、流失，不同分层做不同运营策略。
-
355、C端流失召回：push推送、短信、红包权益，召回沉睡用户。
-
356、C端不要过度做功能堆砌，功能越多不代表产品越好。
-
357、C端要重视应用商店评论，高频差评问题要纳入迭代优化。
-
358、C端做增长功能，要评估对老用户体验会不会造成伤害。
-
359、C端指标陷阱：只看DAU，忽略留存，大量羊毛用户会虚高DAU。
-
360、C端产品核心：抓住用户核心痛点，把主体验打磨到位，再叠加次要功能。
九、商业、增长与运营联动（361～390）
-
361、增长AARRR模型：获取、激活、留存、变现、传播裂变。
-
362、获取Acquisition：通过各个渠道把新用户带到产品内部。
-
363、激活Activation：新用户完成核心行为，感受到产品价值。
-
364、留存Retention：用户持续回来使用产品，留存是增长的基石。
-
365、变现Revenue：将用户价值转化为商业收入。
-
366、传播Referral：老用户带来新用户，裂变传播。
-
367、LTV用户生命周期价值：一个用户从注册到流失一共给平台带来的收入。
-
368、CAC用户获取成本：获取一个新用户投入的成本；LTV要大于CAC业务才健康。
-
369、产品和运营的边界：产品负责提供工具与能力；运营负责使用工具做活动、做用户运营。
-
370、产品做功能前，提前对齐运营的使用场景，避免功能上线运营无法使用。
-
371、商业化要平衡：不能一味追求收入而严重伤害用户体验。
-
372、会员产品设计：会员权益要真实有价值，区分免费与付费的差异。
-
373、优惠券体系：满减、折扣、无门槛券；发放、领取、使用、过期、退回逻辑闭环。
-
374、积分体系：积分获取渠道、消耗渠道、过期规则、防刷风控。
-
375、付费转化链路：曝光‑介绍权益‑引导付费‑支付成功‑权益到账完整链路。
-
376、商业化要设计退款、取消订阅流程，符合法规要求。
-
377、渠道适配：不同渠道来的用户，落地页、新用户权益可以差异化。
-
378、裂变玩法三要素：诱因、传播载体、落地承接页。
-
379、做裂变必须配套风控，防止黑产刷奖励，造成资损。
-
380、用户分层运营：不同价值用户给到不同策略，高价值重点维护。
-
381、私域联动：产品提供加企微、社群入口，运营承接私域用户。
-
382、活动后台配置能力：运营可以自主配置活动，减少产品迭代排期消耗。
-
383、活动降级开关：线上活动出问题，可以一键关停，避免资损扩大。
-
384、资损风险评估：凡是涉及发钱、发券、积分的需求，第一评估资损风险。
-
385、ROI评估：增长活动看投入多少钱，带来多少用户多少收入，判断是否持续投入。
-
386、不要迷信增长玩法，没有产品价值，任何增长手段只能短期带来流量，留不住人。
-
387、商业化常见误区：过早商业化，产品还没有解决用户痛点就开始强行变现。
-
388、增长迭代之后要区分自然增长和活动带来的增长，不要误判产品本身效果。
-
389、运营侧反馈的问题，产品要区分是运营操作问题还是产品本身缺陷。
-
390、产品与运营配合目标：产品提供武器，运营打仗，共同完成业务目标。
十、线上故障、风控合规（391～420）
-
391、线上故障定义：功能不可用、数据错乱、资损、大面积报错、业务中断。
-
392、故障等级：P0致命故障，业务全量不可用；P1严重故障；P2一般故障；P3轻微问题。
-
393、故障处理原则：先止损恢复业务，再定位根因，最后复盘优化。
-
394、止损常见手段：功能开关关闭、版本回滚、切流量、降级非核心功能。
-
395、故障发生产品要参与：确认业务现象，同步业务方、客服，评估业务影响范围。
-
396、故障复盘三问：是什么原因、为什么发生、后续如何避免再次发生。
-
397、风控产品目标：对抗恶意用户、黑产，保护平台、普通用户，避免资损。
-
398、风控策略类型：事前拦截、事中校验告警、事后处罚。
-
399、事前风控：注册、登录、活动参与环节前置规则拦截恶意账号。
-
400、事中风控：操作实时校验，异常行为告警，限制操作权限。
-
401、事后风控：冻结账号、回收不当获取的权益、处罚记录留存。
-
402、风控不能一刀切，要避免误伤正常真实用户，提供申诉入口。
-
403、举报功能设计：举报类型、提交证据、后台审核、处理结果反馈给举报人。
-
404、内容审核：机器初审+人工复审，违规内容处理、下架、账号处罚。
-
405、合规重点：个人信息保护、隐私政策、用户协议、未成年人保护、数据安全。
-
406、收集用户个人信息要遵循最小必要原则，不收集无关信息。
-
407、用户有权查询、导出、删除自己的个人信息，产品要提供对应能力。
-
408、注销账号流程合规，不能设置重重障碍阻碍用户注销。
-
409、敏感业务需要实名认证，按照法规要求对接实名能力。
-
410、数据留存：业务数据按照法规要求设置留存周期，到期清理。
-
411、数据权限管控：内部员工不能随意导出用户敏感数据，操作留审计日志。
-
412、第三方SDK合规：接入第三方SDK，要明确收集哪些用户信息，告知用户。
-
413、弹窗隐私协议：首次打开APP，完整展示用户协议隐私政策，用户确认同意之后再使用产品。
-
414、业务变更如果涉及用户权益、隐私，要做告知公示。
-
415、资损类风险，需求评审阶段就要做风险评估，设计兜底止损开关。
-
416、大促、重大活动，提前做故障预案，明确降级、止损方案。
-
417、灰度、开关能力是产品重要防护手段，高危业务尽量配套远程开关。
-
418、线上不允许直接硬改数据库数据；必须改，要有审批、记录、核对校验。
-
419、客服收到大量同类报错，要第一时间警觉，排查是否出现线上故障。
-
420、敬畏线上环境，所有需求上线都要思考最坏情况如何止损。
十一、AI产品能力（421～440）
-
421、AI产品经理核心不是调算法参数，而是把大模型能力包装成业务可用功能。
-
422、大模型能力边界：会幻觉，会输出错误信息，不能完全信任模型输出结果。
-
423、幻觉应对策略：增加事实引用来源、人工审核、输出结果校验、提示词优化。
-
424、Prompt提示词工程：明确角色、任务、输出格式、约束条件，引导模型输出符合预期结果。
-
425、RAG检索增强生成：把私有知识库给到模型，减少幻觉，让模型使用企业自有数据回答问题。
-
426、Agent智能代理：大模型调用外部工具、接口，完成复杂多步骤任务。
-
427、AI产品评估指标：业务效果指标，不只是单纯技术指标；要看能不能解决真实业务问题。
-
428、AI对话产品：会话历史记忆、上下文窗口限制、会话清空、会话导出。
-
429、AI输入输出安全：内容安全过滤，拦截违规提问与违规输出内容。
-
430、AI限流控制：防止大量调用消耗高额token成本，设置用户调用频次上限。
-
431、成本评估：token消耗直接等于调用成本，AI需求评审要评估成本量级。
-
432、人机协作定位：AI做辅助，人做最终审核决策，高风险业务不能完全交给AI自动处理。
-
433、AI生成内容的版权合规，区分模型训练数据版权、输出内容版权归属。
-
434、AI产品的兜底策略：模型调用失败、超时，要有友好错误提示，降级方案。
-
435、微调Fine‑tuning：用业务数据集训练模型，适配垂直业务场景，需要足量高质量标注数据。
-
436、AI功能灰度放量：小流量验证效果，观察输出质量、成本、报错率，再逐步扩大范围。
-
437、AI埋点重点：用户提问内容、模型返回结果、用户采纳/否定结果、调用耗时、失败率。
-
438、AI产品常见坑：高估大模型能力，把demo效果直接当成生产可用能力。
-
439、区分AI体验demo和线上生产系统，生产环境要考虑性能、成本、安全、异常。
-
440、AI产品成功关键：找对真实业务场景，不要为了AI而AI，不能脱离业务价值。
十二、项目复盘、行业与竞品分析（441～470）
-
441、复盘不等于批斗会，复盘目的是沉淀经验，避免未来重复踩坑。
-
442、复盘四步：回顾目标、评估结果、分析得失、输出后续行动项。
-
443、回顾目标：当初版本、需求、项目预设的业务目标是什么。
-
444、评估结果：实际达成了什么，哪些完成，哪些没有完成，差距多大。
-
445、分析得失：做得好的地方是什么；出现问题的根因是什么，区分人、流程、需求、外部因素。
-
446、输出行动项：具体可执行，有负责人，有时间，不要空泛口号。
-
447、项目成功要复盘，项目失败更要复盘；迭代结束、重大项目上线都建议复盘。
-
448、竞品分析目的：看清行业，找到我方机会，不是抄对方功能。
-
449、竞品分析第一步，明确分析目标，不要漫无目的浏览竞品页面。
-
450、竞品要区分直接竞品、间接竞品、潜在竞品，分别关注不同侧重点。
-
451、分析竞品需要搞懂竞品目标用户、商业目标，不能只看表面UI功能。
-
452、竞品分析输出内容：现状总结、优势劣势、风险提示、我方机会点、可借鉴点、不适合我方的点。
-
453、不要迷信竞品，很多竞品功能上线之后数据效果很差，只是前端看得见。
-
454、行业报告用来看宏观趋势，不要直接拿报告结论直接当做产品方案。
-
455、行业分析重点：行业规模、用户变化、政策影响、主流玩家、未来趋势。
-
456、用户访谈复盘：访谈结束整理用户原话，区分事实和主观感受。
-
457、需求池管理：统一收纳全部需求，定期清理，分为紧急修复、当期迭代、规划池、废弃池。
-
458、定期做需求池复盘，淘汰长期没有资源、价值低的需求。
-
459、历史需求复盘：曾经做过的功能，现在效果如何，哪些做对哪些做错。
-
460、失败需求复盘：为什么失败，是假设错误？场景不对？还是执行落地问题。
-
461、版本上线效果复盘：核对当初预设指标，达到/未达到的根因分析。
-
462、跨团队协作复盘：本次迭代协作卡点，后续流程如何优化。
-
463、风险复盘：本次迭代出现哪些风险，哪些提前识别，哪些遗漏，后续如何提前识别同类风险。
-
464、复盘文档要归档，团队可以查阅，沉淀组织经验。
-
465、做竞品分析不要只截图罗列页面，要有自己的判断与业务推导。
-
466、警惕幸存者偏差，只看头部竞品，忽略大量失败竞品。
-
467、做行业分析要区分数据来源，甄别报告数据真实性。
-
468、不要把别人的成功路径直接复制到自己产品，外部环境、用户基础不一样。
-
469、复盘行动项要跟进闭环，只写文档不去落地，复盘等于无效。
-
470、产品持续成长方式：持续复盘、持续看行业、持续拆解竞品、持续理解真实用户。
十三、大高频（471～500）
-
471、产品经理面试核心考察：问题分析能力、需求判断、逻辑思维、项目经验、业务理解、沟通协作。
-
472、STAR面试讲述项目方法：S场景、T任务、A行动、R结果。
-
473、讲项目不能只讲做了什么功能，重点讲为什么做，遇到什么问题，如何决策，拿到什么结果。
-
474、遇到矛盾冲突类面试题：对事不对人，讲清楚背景、分析、沟通过程、最终方案结果。
-
475、估算类问题（费米估算）：拆解思路比最终数字更重要，展示拆解逻辑。
-
476、产品设计类面试题：先确认目标用户、核心目标，再拆解痛点，输出方案，评估风险，衡量指标。
-
477、遇到线上故障面试题：优先止损恢复业务，再定位根因，复盘预防。
-
478、需求优先级面试答题框架：价值、成本、风险、业务目标，多维度权衡。
-
479、区分初级、中级、高级产品经理考察侧重点：初级看执行文档原型；中级看需求分析方案设计；高级看业务判断、取舍、战略。
-
480、初级产品常见短板：只会接收需求，不会质疑需求，缺少取舍意识。
-
481、中级产品常见短板：方案做得很好，但缺少商业视角，只看功能不看收益风险。
-
482、高级产品核心能力：在信息不全的情况下做高质量决策，定义方向，平衡多方利益。
-
483、产品经理需要懂技术，但不需要会写代码；重点是理解技术成本、技术约束，看懂技术方案。
-
484、产品经理需要懂数据，看得懂指标，知道指标背后业务含义，不被数字欺骗。
-
485、职业发展三大方向：业务产品专家、产品管理管理者、转业务/创业。
-
486、B端与C端能力差异：B端重流程、权限、组织业务理解；C端重用户体验、增长、用户心理。
-
487、跳槽选择产品岗位关注点：业务赛道、团队成熟度、产品权责、是否有完整项目机会。
-
488、不要频繁跳槽，每一段工作尽量要有完整项目沉淀，形成自己的项目案例。
-
489、日常自我提升方法：拆解产品、阅读行业报告、做复盘、积累项目思考笔记。
-
490、产品经理要警惕自我感动：不要陶醉自己输出的文档原型，最终看业务结果。
-
491、向上管理：同步信息，同步风险，对齐目标，寻求资源，不是溜须拍马。
-
492、向下对齐（如果带团队）：明确目标，给成员成长空间，做好决策兜底。
-
493、产品经理常见思维陷阱：把自己当成目标用户、追求功能完美、过度依赖竞品、只看短期收益。
-
494、遇到多方意见冲突：回归业务目标与用户价值，用事实数据做判断依据。
-
495、产品经理的自我修养：保持好奇心、同理心、批判性思考，保持空杯心态。
-
496、学会接受不完美方案，现实中大部分业务都是取舍出来的折中方案，不存在完美方案。
-
497、遇到项目失败，不要一味甩锅，先分析根因，思考自己可以改进的部分。
-
498、沉淀自己的方法论，不是照搬网上模板，从真实项目里面总结适合自己的思考框架。
-
499、区分手段和目的：原型、PRD、迭代都是手段；真正目的是解决业务问题，拿到业务结果。
-
500、产品经理的终极能力：在复杂不确定环境中，识别真正重要的问题，做出正确的取舍，推动团队拿到有价值的业务结果。
标签：#产品经理 #产品速查手册 #产品知识点 #B端C端产品 #面试产品
扫一扫
714
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
