产品经理 术语手册

负责产品从定义、规划到上线迭代全过程的角色：洞察用户需求、明确产品方向、协调研发设计运营等资源，并对产品结果负责，常被称为"产品的 CEO"。核心能力包括需求洞察、逻辑表达、数据分析与跨团队沟通。

大白话就是那个负责“产品到底做成什么样”的人：想清楚用户要什么，把想法变成能落地的功能，再拉着研发、设计一起把它做出来。

为解决用户问题、满足需求而设计并交付的功能、服务或解决方案，既包含有形功能，也包含体验、品牌与服务。产品是价值的载体，只有被真实使用才能创造价值。

大白话做出来给用户用的东西，可能是 App、网页，也可能是一个功能或服务。关键是有人真的用、真的解决问题，不然就是个摆设。

以用户价值为出发点，系统思考"为谁、解决什么问题、如何创造与传递价值"的思维方式。区别于功能思维，它强调目标导向、全局视角与持续迭代，而不是"有什么做什么"。

大白话不是“我能做什么”，而是“用户要什么、值不值得做”。先想清楚为谁解决什么问题，再想怎么做。

站在用户视角而非自我视角思考问题的习惯：理解用户的真实场景、动机与情绪，避免"我觉得"式的想当然判断。用户思维是一切产品决策的起点，也决定产品是否"自嗨"。

大白话别自己觉得好就行，要站在用户角度想：他什么时候用、怎么用、用起来爽不爽。一句话：少自嗨。

产品从引入期、成长期、成熟期到衰退期的演变过程。不同阶段的用户规模、增长重点与策略差异明显：引入期重在验证价值，成长期重在放大增长，成熟期重在留存与变现。

大白话产品像人一样有成长阶段：刚出生（验证）、快速长大（拉用户）、成熟（赚钱）、变老（衰退），不同阶段打法不一样。

以时间轴呈现的产品规划蓝图：按季度或里程碑列出即将建设的功能、目标与优先级，是向团队、管理层与投资人同步产品方向的重要工具。路线图不等于承诺，需随验证结果滚动更新。

大白话一张按时间排的产品计划表，告诉团队接下来几个月做什么、先做什么后做什么。

关于"做什么、不做什么、为什么做"的高层决策，包括目标用户、价值主张、差异化定位与竞争策略。策略决定路线图，路线图落地为版本计划，三者自上而下层层承接。

大白话大方向上的取舍：做给谁、凭啥比竞品强、哪些坚决不做。方向对了，后面才不会白忙。

用户在完成某项任务时遇到的不便、挫败或未被满足的需求，是产品机会的起点。"解决真痛点"比"锦上添花"更能创造用户价值，判断痛点是刚需还是伪需求是 PM 的基本功。

大白话用户用着不爽、心里憋屈的地方。痛点越真，产品越有戏；要是痛点是自己编的，做出来也没人用。

产品为用户带来的实际收益，通常表述为"用更低成本、更快或更好地完成某事"，如节省时间、降低难度、带来愉悦。每个功能都应能回答"它给用户带来了什么价值"。

大白话这个功能到底帮用户省了啥、得了啥好处。做任何功能前都问一句：用户图啥？

从获客、激活、留存、转化到复购与推荐形成自循环的完整业务链条，例如"更多用户→更多内容→更强的网络效应→吸引更多用户"。PM 常以"是否跑通闭环"判断产品模式是否成立。

大白话用户从进来、用上、付钱到再喊人来，整个链条能自己转起来，像滚雪球。转不起来，说明产品还没成。

以数据为依据做产品决策的文化与方法：用埋点、实验与指标监控代替主观判断，让"拍脑袋"变成"看数据说话"。同时需警惕唯数据论——数据要服务于用户价值判断。

大白话别拍脑袋，用数据说话。功能改没改对、用户买不买账，看数据就知道。

用户或业务方对产品的期望与诉求，本质是"用户想要解决什么问题"。需求不等于功能，PM 的核心工作是从表面诉求中挖掘背后的真实问题与价值，而不是直接照做。

大白话用户嘴上说的“我想要啥”，背后其实是“我想解决啥问题”。别照着字面做，要挖出真问题。

集中沉淀所有待处理需求的统一清单，记录来源、描述、价值、优先级与状态等信息，是需求管理的入口与"中转站"。需求入池后经过分析、筛选与排期，逐步进入开发。

大白话一个装下所有需求的大筐子，谁提的需求都先扔进来，记下来、排优先级，轮到谁谁再做。

对需求进行拆解、验证与设计的过程：判断真伪与价值、明确目标用户与场景、界定功能边界，最终转化为可开发的需求文档。好的分析能过滤伪需求、减少返工。

大白话拿到需求先别急着做，先盘一盘：是真的吗？给谁用？值不值得做？想清楚了再动手。

在多个需求竞争有限资源时，按价值、成本、风险等维度排序的决策过程。常用工具包括 KANO、RICE、MoSCoW 等模型，核心原则是"先做高价值低成本、少做低价值高成本"。

大白话活太多做不完时，先做哪个后做哪个。原则就一条：先做又重要又省事的。

组织研发、设计、测试等角色共同评审需求的完整性与可行性，确认理解一致后再进入开发。评审能提前暴露歧义与盲区，是减少返工和需求误解的关键环节。

大白话开发前把研发、设计、测试叫到一起过一遍需求，确认大家理解的一样，免得做完了才发现不是一回事。

对已确认需求的变更进行受控处理：评估影响、明确成本、更新文档并同步团队。频繁无序的变更会侵蚀进度与质量，变更管理的要义是"记录、评估、审批、同步"。

大白话需求说改就改最坑人。要改可以，得说清楚影响多大、要不要延期，大家确认了再改。

以"作为……我想要……以便……"句式描述需求的轻量表达方式，强调从用户视角说明"谁、要什么、为什么"。它是敏捷开发中需求的最小表达单元，常配验收标准使用。

大白话用一句话说清需求：“我（什么用户）想要（什么功能），好让我（得到什么好处）”。简单直白，开发也看得懂。

把用户完成核心任务的步骤横向展开、按优先级纵向排列的用户故事全景图。它让团队同时看到"全局骨架"与"细节血肉"，常用于规划版本边界与 MVP 切分。

大白话把用户从头到尾的每个步骤摊开在一张图上，一眼看清全流程和重点，方便决定第一版先做哪块。

基于真实用户调研提炼的典型用户模型，包含背景、目标、行为习惯与痛点等特征（如"28 岁的职场妈妈"）。画像让团队讨论需求时有"具象的用户"可参照，避免面向空气设计。

大白话给目标用户捏一个具体的人，比如“28 岁的上班族妈妈”。以后讨论需求就说“她会怎么用”，而不是对着空气设计。

可视化用户从接触产品到完成目标全过程的工具：记录每个触点的行为、想法、情绪与痛点，帮助团队发现体验断点与优化机会，是设计"流畅体验"的重要输入。

大白话把用户从接触产品到用完的每一步画出来，标上他每一步的心情，哪里爽哪里烦一目了然。

描述用户在特定时间、地点与情境下使用产品的具体情形，如"通勤地铁上单手操作""深夜赶稿时找素材"。场景让需求更具体，是设计功能与评估体验的重要依据。

大白话用户“在什么情况下用”这个功能，比如地铁上单手刷手机。场景清楚了，功能才知道怎么做才顺手。

与产品相关的所有利益相关方：用户、老板、运营、销售、研发、合规等。PM 需要识别干系人、管理其期望并平衡多方诉求，任何一方的诉求被忽视都可能导致项目受阻。

大白话跟这事有关的所有人：老板、用户、运营、研发……他们的想法都要照顾到，漏了谁都可能出幺蛾子。

判定需求"是否完成且合格"的明确条件清单，供开发自测与测试验收。清晰的验收标准能显著减少"做完但不对"的返工，是用户故事的必要组成部分。

大白话事先说好“做成啥样算过关”，白纸黑字列清楚。开发照着做，测试照着查，省得扯皮。

产品或需求完成后，由产品经理、业务方或用户确认实现是否满足预期与验收标准的过程，是需求闭环的最后一步。验收通过才意味着需求真正"做完"，未通过则进入返修。

大白话功能做完后，产品、业务或用户亲自确认一下“是不是我要的那个”，是了就收工，不是就打回返工。

团队约定的"一个故事或迭代真正完成"的统一标准，如代码完成、自测通过、文档更新、已上线。DoD 让"完成"一词在团队内有唯一且无歧义的含义。

大白话团队约定“做完”到底指什么：不光代码写完，还得测过、文档更新、上线了才算。免得有人觉得“写完就算完”。

系统研究竞品的功能、体验、定价与策略，提炼可借鉴点与差异化机会的方法。常用手段包括功能对比表、体验评测与 SWOT 对照，目的是"知己知彼"而非简单抄袭。

大白话去看看别人家做得咋样，好用在哪、坑在哪，咱能做点什么不一样的。知己知彼，抄也要抄明白。

与目标用户一对一深度交流以获取真实需求与反馈的定性方法。访谈的关键是开放式提问、追问动机与观察行为，避免引导性问题把答案"喂"给用户。

大白话找几个目标用户坐下来聊天，听他讲怎么用、卡在哪。关键是多问“为啥”，别把答案喂给他。

用标准化问卷规模化收集用户信息的量化方法，适合验证假设、测量满意度与用户画像。问卷设计的核心是题目清晰、选项互斥、样本具有代表性。

大白话用一份问卷问一大波人，收集大家的意见和数据，适合验证“是不是大多数人都这么想”。

组织 6-8 名用户围绕主题进行小组讨论的定性研究方法，通过成员间的互动激发更多观点，常用于需求探索与概念测试。缺点是易受从众影响，需专业主持人引导。

大白话找七八个人围一起聊一个话题，你一言我一语能聊出更多想法，适合前期摸底，但容易有人跟风说话。

把需求按用户满意度的影响分为五类：必备型（不做不行）、期望型（做了更好）、魅力型（做了有惊喜）、无差异型（做了没感觉）与反向型（做了反而扣分）。它帮助识别哪些是"锦上添花"、哪些是"不可或缺"。

大白话把需求分五类：没你会死（必备）、有你会爽（期望）、没有没想到、有了超惊喜（魅力）、做了也没感觉（无差异）、做了反而招骂（反向）。

用四个因子量化需求优先级：触达用户数（Reach）×影响程度（Impact）×信心指数（Confidence）÷工作量（Effort），得出可横向比较的分数。适合需要"算出来"的排期场景，让排序过程透明可辩。

大白话给需求算分：影响多少人 × 影响多大 × 多确定 ÷ 要多费劲。分高先做，排期有理有据。

把需求分为四档：Must（必须有）、Should（应该有）、Could（可以有）、Won't（本轮不做），帮助团队在资源受限时明确"砍单边界"。它是敏捷排期中团队沟通优先级的常用语言。

大白话需求分四筐：必须有、应该有、可以有、这轮先不做。活多的时候照着砍，大家没意见。

用影响（Impact）×信心（Confidence）÷成本（Effort）快速打分排序的轻量方法。相比 RICE 更简单，适合海量想法快速筛选，常配合增长实验与看板使用。

大白话RICE 的轻量版：影响 × 信心 ÷ 成本，快速打个分，适合一堆想法里先筛出能做的。

产品需求文档：面向研发与测试的详细需求说明书，包含背景、目标、用户场景、功能详述、交互说明、边界与验收标准。PRD 是"开发前必须对齐"的契约文档，写法重逻辑与可执行性。

大白话给研发看的“需求说明书”，把功能怎么做、边界在哪、做成啥样算好写得清清楚楚，开发前大家照着对齐。

市场需求文档：聚焦市场与用户侧的分析文档，说明市场机会、目标用户、竞品格局与产品定位，是 PRD 的上游输入，回答"为什么做、为谁做"。

大白话讲“市场为啥有机会”的文档：用户是谁、竞品咋样、我们凭什么做。是 PRD 的上游，回答“为什么做”。

商业需求文档：面向决策层说明产品商业价值的文档，涵盖商业背景、市场机会、商业模式、成本收益与风险，回答"值不值得做"，是立项与资源投入的依据。

大白话给老板看的“这买卖值不值得做”的报告：能赚多少钱、要花多少钱、风险多大。老板点头了才立项。

用静态页面或可点击流程模拟产品界面的设计稿，用于验证想法、对齐需求与评审交互，让团队在开发前"看见"产品。按精细度分为低保真与高保真两类。

大白话还没开发时先画或搭一个界面草稿，让大家提前“看见”产品长啥样，改起来比改代码便宜多了。

低保真原型的一种：用线条与方框勾勒页面的布局、信息层级与交互流程，不含配色与视觉细节，用于快速确定结构与逻辑，是交互与视觉设计的基础。

大白话用框框和线条画的页面骨架，只有结构和位置，没有颜色和细节，快速确认“东西放哪”。

仅表达结构与流程的粗略原型（如线框图、手绘稿），制作快、成本低，适合早期需求对齐与多方案快速比较，避免在未验证的想法上投入精细设计。

大白话粗糙但快，能表达大概布局和流程就行，适合早期想法还不确定时快速试错。

接近真实视觉与交互的精细原型，含配色、字体、图标与动效，体验接近成品。适合进行可用性测试、向管理层演示以及给研发作为开发参照。

大白话做得跟真的一样的原型，颜色、字体、动效都有，能拿去给用户测试、给老板演示。

设计用户与产品之间的交互方式：操作路径、反馈、状态与动效，目标是让用户"用得顺畅、用得明白"。交互设计师与 PM 协作，把需求转化为可操作的界面逻辑。

大白话设计“用户点哪、点了之后发生啥、页面怎么回应”，让用户用得顺、找得到、不迷路。

组织与呈现产品信息的结构设计：导航、分类、层级与标签。好的信息架构让用户"找得到、看得懂"，是复杂产品体验的地基，常通过卡片分类法等调研验证。

大白话安排信息怎么组织：菜单怎么分、页面怎么跳、东西放在哪，让用户想找啥都找得到。

用户使用产品全过程的整体感受，涵盖易用、愉悦、高效与可信。UX 是设计的结果而非单一环节，PM 需要把体验目标纳入需求设计，而不只是"功能实现就行"。

大白话用户用下来整体的感觉：好不好用、顺不顺手、开不开心。功能好但用着难受，照样留不住人。

用户直接看到和操作的视觉界面：布局、色彩、字体、图标与控件。UI 是 UX 的载体，好的 UI 兼具美观、清晰与一致性，并在不同设备上保持稳定。

大白话用户肉眼看到、上手操作的那一层：按钮、颜色、排版。好看又好点，就是好界面。

邀请真实用户完成任务、观察其操作与卡点来评估产品易用性的方法。尽早测试、少量用户（约 5 人）即可发现大部分问题，是"不要等上线后才发现难用"的保险。

大白话找真实用户来试用，看他会不会用、卡在哪。不用很多人，五六个就能暴露大部分问题。

用节点与箭头描述业务流程或功能逻辑的图示，包含判断、分支与异常路径。流程图是需求沟通与开发实现的共同语言，能提前暴露逻辑漏洞与边界缺失。

大白话把流程画成带箭头的图，从哪开始、怎么分支、出错了咋办，一眼看全，逻辑漏洞也藏不住。

从用户视角描述"在什么条件下、执行什么操作、系统如何响应"的场景化说明，包含主流程、分支与异常流程。常用于复杂功能（如支付、权限）的细化与测试设计。

大白话描述“谁在什么情况下做了啥、系统怎么反应”，把正常流程和异常情况都写清楚，测试照着写用例。

统一建模语言：软件设计中标准化的图形建模语言，包含用例图、类图、时序图、活动图、状态图等，用于描述需求、结构与交互。UML 图是需求分析与系统设计阶段的通用沟通工具，能帮助跨角色对齐复杂逻辑。

大白话一套画图的标准语言，画用例图、时序图、类图等，把需求和系统结构画出来，技术和非技术都能看懂。

由设计原则、组件、规范与设计令牌（色彩、间距、字体等）组成的一整套可复用设计体系，保证多产品线的视觉与交互一致，显著提升设计与开发效率。

大白话把颜色、字体、按钮等统一成一套规范，大家照着用，做出来的界面才像一个妈生的。

把常用界面元素（按钮、弹窗、表单等）封装为可复用代码组件的集合，与设计系统配合，让团队"搭积木"式快速构建页面，并保证实现与设计一致。

大白话把常用按钮、弹窗、表单做成现成的积木块，开发直接拼，又快又不容易出错。

最小可行产品：以最小成本实现核心功能、足以验证关键假设并获取用户反馈的产品版本。MVP 的目的不是"功能少"，而是"最快验证值不值得做"，是精益创业的核心概念。

大白话先做个“刚刚够用”的版本上线试水，看用户买不买账，再决定值不值得继续做。花小钱验证大方向。

以迭代、增量、拥抱变化为核心的软件开发理念：小步快跑、频繁交付、快速响应反馈，而非瀑布式"一次到位"。Scrum 与看板是它最主流的实践框架。

大白话不憋大招，小步快跑：两三周一版，做完就上线看反馈，随时调整，边做边改。

最流行的敏捷框架：固定时长的冲刺、明确定义的角色（产品负责人、Scrum Master、开发团队）与仪式（计划会、站会、评审会、回顾会），强调自组织与持续改进。

大白话敏捷里最流行的一套打法：固定周期、固定角色、固定开会节奏，让团队自己管理自己，持续改进。

Scrum 中一个固定时长的开发周期（通常 1-4 周）。冲刺内目标锁定、不新增需求变更，结束后交付可用的产品增量，是"短周期交付"节奏的基本单位。

大白话一个固定的开发周期（一般一两个月内），这段时间目标锁死、不加新需求，到点交付一版。

源自丰田的可视化管理方法：用"待办—进行中—完成"列呈现任务流，并限制在制品数量，让瓶颈一目了然。看板适合需求流动频繁、不适用固定冲刺的团队。

大白话一块白板分几列（待办、进行中、完成），任务卡片往里贴，谁卡住了、哪积压了一眼就能看到。

团队每天用短时间（15 分钟内）同步"昨天做了什么、今天做什么、有什么阻塞"的会议，站着开以保证简短。站会的目的是暴露问题而非汇报工作。

大白话每天 15 分钟站着开的小会：昨天干了啥、今天干啥、有没有卡住。不为汇报，就为暴露问题。

完成一个可交付增量的开发循环。产品通过一轮轮迭代逐步逼近目标，每次迭代都应有明确的产出、验证与复盘，避免"憋大招、一次上线"。

大白话做一版、看反馈、改一版，这样循环着往前走。产品是“磨”出来的，不是一次憋出来的。

项目中的关键节点：重大版本上线、关键功能完成或阶段目标达成。里程碑用于向干系人同步进度、管理期望，是排期与资源投入的锚点。

大白话项目里的重要节点，比如“9 月底上线 V2.0”。到了节点就给大家看进度，心里有数。

评估需求工作量并安排上线时间的过程。排期要预留缓冲、考虑依赖与风险，PM 需要在"业务期望"与"团队现实"之间找到平衡，并诚实沟通不确定性。

大白话估一估这活要多长时间，定下啥时候上线。估的时候要留余量，别被“这就完了？”逼到天天加班。

把通过测试的版本有计划地推向用户的过程，包括发布计划、灰度策略、回滚预案与上线监控。发布不是终点，而是观察数据与用户反馈的新起点。

大白话把测好的版本正式推给用户，不是点个按钮就完事，要计划好怎么放量、出问题怎么回滚。

先让少量用户（如 5%）使用新版本，验证无异常后再逐步放量到全量的发布策略。它把发布风险控制在最小范围，是"上线事故"的重要防线。

大白话先放给 5% 的用户试，没问题再慢慢放给所有人。出事故最多坑一小撮人，不会全盘崩。

显示冲刺内剩余工作量随时间下降的图表：横轴为时间、纵轴为剩余任务量。曲线趋势反映进度是否健康，是 Scrum 团队最常用的进度可视化工具。

大白话一张图看冲刺进度：横轴时间、纵轴还剩多少活，线往下走得顺就说明节奏正常。

产品与预期不符或无法正常使用的程序问题。缺陷按严重程度与影响范围分级，PM 需参与"哪些必须上线前修复、哪些可延后"的判定，平衡质量与节奏。

大白话就是 bug，程序不按预期跑或者直接崩了。上线前哪些必须修、哪些能缓，产品要拍板。

使任务无法继续推进的阻碍，如外部依赖未到位、环境故障、关键决策未定。站会上最重要的输出之一就是暴露阻塞，PM 的职责是第一时间推动解决。

大白话干不下去的卡点：接口没给、环境坏了、决策没定。站会上最重要的事就是把它喊出来解决掉。

任务完成所依赖的外部条件：其他团队接口、第三方服务、设计产出等。依赖管理不善是项目延期的主要来源，需要提前识别、明确时间并对齐各方。

大白话这活要等别人：等别的团队接口、等第三方服务。依赖管不好，延期八成因为它。

由业务方或真实用户在类生产环境验证产品是否符合预期的环节，通过后才正式上线。UAT 是质量保障的最后一道门，重点验证"需求是否被正确满足"。

大白话上线前让业务方或真实用户先在测试环境“把把关”，觉得 OK 了才正式上线，相当于最后一关质检。

需求、设计、开发、测试、上线严格串行的传统开发模式，强调前期文档完备、后期少变更。适合需求明确、变更少的项目，缺点是反馈周期长、试错成本高。

大白话老式做法：需求、设计、开发、测试、上线，一步一步走完才回头。适合需求明确的项目，缺点是改起来太费劲。

用相对单位估算用户故事工作量的方法（常取斐波那契数列 1、2、3、5、8……），关注"相对大小"而非绝对工时。它帮助团队估算速度（Velocity）并规划冲刺容量。

大白话不用小时估工作量，用“大小”估：这个任务比那个大还是小（1、2、3、5、8……）。估大小比估时间准。

迭代或项目结束后，团队回顾"做得好、待改进、下一步行动"的会议（亦称复盘）。回溯的目的是改进流程而非追责，是敏捷团队持续优化的引擎。

大白话一个项目或迭代做完后，大家坐一起聊聊：哪里干得好、哪里要改进、下次咋办。对事不对人。

在网页或 App 中嵌入代码、记录用户行为数据（点击、浏览、注册等）的技术手段。埋点是产品数据的源头，应在需求阶段就规划"要验证什么、埋什么点"。

大白话在 App 或网页里埋“摄像头”，记录用户点了哪、看了哪。没埋点就没数据，没数据就没法优化。

埋点记录的一个具体用户行为，如"加入购物车""点击支付"。事件通常附带属性（时间、渠道、页面、数值等），是数据分析的最小单位。

大白话一个具体的用户动作记录，比如“点了加购”“点了支付”。一堆事件拼起来就是用户行为轨迹。

把关键流程（如注册、下单、付费）拆成连续步骤，观察每一步的转化与流失，定位"用户在哪一步放弃最多"。漏斗是转化优化的核心工具，常配合分群与路径分析使用。

大白话把“注册、下单、付款”这种流程拆成几步，看每步有多少人溜走，就知道用户死在哪一步。

一段时间后仍继续使用产品的用户比例，如次日、7 日、30 日留存。留存是产品价值的"照妖镜"——拉新很快但留不住，说明核心价值尚未成立。

大白话昨天来的用户，今天还来吗？一周后呢？留不住人，拉再多新用户也是白搭。

日/周/月活跃用户数，衡量产品的用户规模与活跃度。DAU 高但留存差，通常意味着"虚假繁荣"；不同产品需选择合适的活跃口径（登录、使用、产生内容等）。

大白话每天、每周、每月有多少人在用。数字高但留不住，可能就是“虚假繁荣”。

完成目标行为的用户占进入流程用户的比例，如注册转化率、付费转化率。提升转化率是增长的核心手段之一，需结合漏斗分析找到最大流失环节。

大白话100 个人走进流程，几个走到了最后？比如 10% 的注册转化率，就是 100 人里 10 人注册。

唯一能反映产品为用户创造核心价值的指标，如 Airbnb 的"预订过夜数"、微信的"活跃用户数"。它指引全团队朝同一个方向努力，是增长决策的灯塔。

大白话全公司只盯一个最关键的数，这个数涨了说明产品真的有用。比如“每周下单的用户数”。

经典增长模型：获取（Acquisition）→激活（Activation）→留存（Retention）→收入（Revenue）→推荐（Referral），又称海盗指标。它帮助系统拆解用户生命周期各环节的增长机会。

大白话增长五步曲：拉人（获取）、让人用起来（激活）、留住（留存）、收钱（收入）、喊朋友来（推荐）。照着五步找机会。

通过优化产品体验、渠道投放、裂变机制等手段系统性提升用户规模与质量。增长不是单纯的拉新，而是"获取—激活—留存—变现—推荐"的全局工程。

大白话想办法让用户越来越多：产品好用、投放精准、老带新。不是砸钱拉新那么简单，得整套组合拳。

用户注册后第一次真正体验到产品核心价值的时刻（Aha Moment），如"发布第一条动态"。激活是留存的前提，PM 常围绕激活设计新手引导与首日体验。

大白话新用户注册后第一次“哇，这玩意有用”的那个瞬间，比如发完第一条动态。这个瞬间越早，越留得住人。

一个用户在整个生命周期内为产品贡献的总收入。LTV 与获客成本的对比决定商业模式是否健康，通常要求 LTV 大于获客成本的 3 倍以上。

大白话一个用户一辈子能给产品贡献多少钱。跟获客成本一对比，就知道赚不赚钱。

获取一个新用户平均花费的成本，约为推广费用除以新增用户数。CAC 必须与 LTV 匹配，否则会出现"卖一单亏一单"的规模不经济。

大白话拉一个新用户平均要花多少钱。如果拉一个人花 100 块，他一辈子才贡献 50 块，那就亏了。

投入产出比，即收益除以成本，衡量产品、渠道或活动投入是否值得。PM 在做方案取舍时常用 ROI 横向比较，优先做"投入小回报大"的事。

大白话投入一块钱能赚回几块钱。做方案前先算账，回报低的往后排。

用"你有多大可能向朋友推荐本产品（0-10 分）"衡量用户口碑与忠诚度的指标：推荐者比例减去贬损者比例。NPS 是衡量"用户是否真心满意"的常用健康度指标。

大白话问用户“你愿意把产品推荐给朋友吗”，打分 0-10。愿意推荐的人多，说明产品真的讨人喜欢。

一段时间内停止使用产品或取消订阅的用户比例。高流失会吞噬增长成果，需结合流失用户特征与原因（功能、价格、体验）有针对性地治理。

大白话一段时间里跑了多少用户。流失太高，拉新的速度都赶不上跑的速度。

把核心指标集中可视化展示的界面，让团队实时看到产品健康度与业务变化。好的看板"一屏看清"，并聚焦北极星指标与关键过程指标，而非堆砌所有数据。

大白话把最重要的几个数放到一块屏幕上实时看，一打开就知道业务好不好，不用到处翻报表。

把用户随机分为多组、分别展示不同方案，用真实行为数据判断哪个方案更优的科学决策方法。它是"用数据代替争论"的标准工具，适合页面文案、布局与算法的验证。

大白话把用户随机分成两组，一组看 A 方案、一组看 B 方案，看哪个效果好。用数据定胜负，不靠吵架。

判断实验结果差异"不是随机波动造成"的置信程度，通常要求 P 值小于 0.05。没有显著性的"提升"可能是运气，直接据此决策存在风险，需结合样本量与效应量判断。

大白话实验结果差别够不够“真”，还是只是运气。数字差一点点的时候，别急着高兴，先看显不显著。

产品从零到第一批用户或内容的启动阶段，常面临"没有用户就没有内容、没有内容就没有用户"的循环难题。常见解法包括种子用户运营、人工供给与邀请制。

大白话产品刚上线，没用户也没内容，陷入“鸡生蛋蛋生鸡”的死循环。只能先人工攒第一批，慢慢转起来。

产品早期邀请的深度参与用户：他们容忍不完美、愿意反馈、帮助打磨产品并带来口碑。种子用户的质量往往决定产品早期迭代的方向与节奏。

大白话最早请来的一批铁杆用户，产品不完美他们也愿意用、愿意提意见，还能帮你宣传。质量比数量重要。

用颜色深浅可视化用户在页面上的点击、滚动与停留分布的工具。热力图能直观揭示"用户真正在看什么、点哪里"，是页面布局与转化优化的常用依据。

大白话把用户点击的地方用颜色标出来，点得越多颜色越深。一眼看出用户到底在看啥、点啥。

用九宫格梳理商业模式的工具：价值主张、目标客户、渠道、客户关系、收入来源、核心资源、关键业务、重要合作与成本结构。一页纸看清"怎么赚钱、靠什么运转"。

大白话一张九宫格，把“给谁、给啥、怎么赚钱、要花多少钱”都填进去。一页纸看清这生意怎么转。

按人群特征（地域、年龄、行为、需求）把大市场切分为可服务的小市场。细分帮助产品聚焦目标用户，避免"什么人都想做、结果谁都做不好"。

大白话别想通吃所有人，先把市场切成一块块的，挑一块最合适的深耕。贪多嚼不烂。

通过桌面研究、问卷、访谈等手段了解市场规模、趋势、竞品与用户需求的过程，是产品立项与方向判断的依据，强调"先验证再投入"。

大白话动手做之前先做功课：市场多大、大家要不要、竞品咋样。调研清楚了再干，少交学费。

在用户心智中为产品确立的独特位置：一句话说清"我是谁、为谁、解决什么、和别人的区别"。定位决定营销口径与功能取舍，是产品策略的核心输出。

大白话一句话说清“我是谁、给谁用、跟别人有啥不一样”，让用户一想到某类需求就想到你。

确定产品价格与收费模式的方法，如成本定价、价值定价、竞品跟随等。定价直接影响收入模型与用户接受度，是商业化设计中最关键也最敏感的一环。

大白话定多少钱、怎么收钱。定贵了没人买，定便宜了不赚钱，还要看竞品脸色。

基础功能免费、高级功能付费的商业模式。其关键是"免费层提供足够价值吸引用户，付费层价值感强到让用户愿意升级"，常见于工具类与内容类产品。

大白话基础功能免费吸引人，高级功能收费赚大钱。关键是免费的要好用，付费的要让人心痒。

按周期（月/年）持续收费的模式，强调续费与留存。订阅制产品的收入可预期性强，因此更关注长期价值、流失率与续费率的持续优化。

大白话按月或按年交钱续着用。收入稳定，但用户随时可能跑，所以特别怕流失。

产品推向市场的整体方案：目标市场、渠道、定价、推广节奏与销售打法。好产品配上错误的 GTM 同样会失败，GTM 需要与产品能力同步设计。

大白话产品做出来后怎么卖出去：卖给谁、走什么渠道、怎么宣传、怎么定价，一整套打法。

用户越多、产品价值越大的现象，如微信、美团、闲鱼。网络效应是强大且难以复制的护城河，常见于平台型与社交型产品，是其增长飞轮的核心。

大白话用的人越多，产品越好用，于是越多人用。比如微信：朋友都在上面，你就离不开。这是最强壁垒。

产品长期抵御竞争与抄袭的壁垒：品牌、数据、规模、网络效应、专利、转换成本等。PM 思考"竞品为什么抄不走我"，就是在寻找与加固护城河。

大白话凭什么竞品抄不走你：品牌、用户数据、规模、生态。没有护城河，做得好也容易被抄死。

从优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）、威胁（Threats）四个维度评估产品或业务形势的经典工具，常用于战略制定与竞品对比。

大白话把自己和局势摆开看四件事：优势、劣势、机会、威胁。看清自己，也看清环境。

按"单个用户或单笔交易"计算收入与成本的模型，如单客 LTV 与 CAC、单均毛利。单位经济为正，规模越大越赚钱；为负则"规模越大亏得越多"。

大白话不算总账，算“每个用户或每单”赚不赚钱。单客赚钱，规模越大越赚；单客亏钱，越火越亏。

目标与关键结果：由"目标（O，想达成什么）"与"关键结果（KR，如何衡量达成）"组成的绩效管理方法，强调聚焦、透明与对齐。KR 应可量化、有挑战，通常按季度设定。

大白话定一个大胆的目标（O），再用几个能量化的结果（KR）衡量做到没。比如“让产品更受欢迎”配“月活涨 30%”。

关键绩效指标：衡量业务或岗位表现的核心量化指标，如转化率、收入、满意度。与 OKR 的"挑战目标"不同，KPI 更偏向基准达成与绩效考核。

大白话衡量干得好不好的几个关键数字，比如转化率、收入。跟 OKR 比，KPI 更像“考核线”。

OKR 中用于衡量目标达成度的可量化结果，如"月活提升 20%"。好的 KR 是结果而非任务，可验证、有挑战且数量精简（每个目标 3-5 个）。

大白话OKR 里用来证明“目标达成没”的数字，要具体、能衡量，比如“用户时长提升 20%”。

让团队目标、优先级与执行节奏保持一致的过程：OKR 对齐、需求对齐、信息同步。对齐不到位是"团队各干各的"的根源，也是 PM 高频沟通的价值所在。

大白话让大家的目标、优先级、节奏一致，别各干各的。目标没对齐，团队越努力越跑偏。

PM 与研发、设计、测试、运营、市场等多角色协同推进产品的工作方式。PM 是协作的"粘合剂"，需要建立信任、明确分工、及时同步，让每个人"都知道为什么做"。

大白话产品、研发、设计、运营、市场一起干活。产品经理是中间的粘合剂，得让大家劲儿往一处使。