第一次参加产品会议，很多新人都会产生一种错觉：明明每个字都听得懂，连在一起却不知道大家在说什么。
产品经理的专业术语看起来很多，但并不需要死记硬背。大部分术语都对应产品工作中的一个具体环节：发现问题、分析需求、设计方案、推动上线，再通过数据验证结果。
下面按照产品从想法到落地的完整流程，讲清楚产品新人最需要掌握的20个专业术语。
例如，一款在线课程工具的用户可能很多，但它的目标用户可以进一步明确为“需要独立制作和销售课程的知识博主”。
定义目标用户不能只看年龄、职业和地域，还要关注他们的需求、使用场景、行为习惯和付费意愿。目标用户越清晰，产品功能、内容和推广方向越容易确定。
新人常见误区是把“所有人”都当作目标用户。事实上，服务所有人，往往意味着无法真正满足任何一类人的核心需求。
用户画像是根据用户调研、行为数据和实际特征，整理出的典型用户模型。
用户画像不是给用户随便编一个名字、年龄和兴趣爱好，而是帮助团队回答：“我们正在为谁设计产品？”
用户痛点是用户在完成某个目标时遇到的困难、阻碍或成本。
例如，“我想要一个导出按钮”只是用户提出的解决方案，不一定是真正的痛点。继续追问后可能发现，用户真正的问题是“每周都要手动整理数据向领导汇报”。
产品经理不能只记录用户说了什么，还要分析用户为什么这样说。找到表面需求背后的真实问题，才可能设计出更有效的解决方案。
用户场景描述的是用户在什么时间、什么地点、出于什么目的使用产品，以及过程中会遇到什么问题。
同一个功能放在不同场景中，用户要求可能完全不同。例如，办公室里填写报表和在手机上临时查看报表，对操作效率、页面布局和信息密度的要求并不一样。
价值主张是产品向目标用户提供的核心价值，也是用户选择你的产品而不是其他方案的主要理由。
为哪类用户，在什么场景下，解决什么问题，带来什么价值。
价值主张不是“功能丰富”“体验优秀”这类宽泛描述，而是明确告诉用户：这个产品能帮你完成什么，以及为什么适合你。
需求池是集中记录和管理产品需求的地方。需求可能来自用户反馈、销售人员、客服、管理层、竞品研究和数据分析。
但需求池不等于开发任务清单。一个需求进入需求池，只代表它被记录下来，并不代表一定要做。
比较完整的需求记录应包含需求来源、用户问题、使用场景、影响范围、预期价值和当前状态，方便后续分析与排序。
需求分析是产品经理对需求进行拆解、验证和判断的过程。
需求分析的重点不是证明一个需求“能做”，而是判断它“该不该做、现在要不要做、应该怎么做”。
作为一名某类用户，我希望完成某个行为，从而获得某种价值。
作为一名团队管理员，我希望批量邀请成员，从而减少逐个添加成员的时间。
用户故事能够帮助团队把注意力放在用户目标和最终价值上，但它不能完全代替详细的产品规则、交互流程和异常情况说明。
需求永远比研发资源多，因此产品经理必须判断先做什么、后做什么，以及暂时不做什么。
不能因为某位用户声音最大，或者某个需求讨论次数最多，就直接把它排在第一位。优先级本质上是价值、成本和风险之间的权衡。
PRD是Product Requirements Document的缩写，即产品需求文档。
一份实用的PRD通常包括需求背景、产品目标、用户场景、功能范围、页面流程、业务规则、异常情况、数据要求和验收标准。
PRD并不是写得越长越专业。它真正的作用，是让设计师知道要设计什么，让研发知道要实现什么，让测试知道如何判断功能是否符合要求。
如果团队成员看完后仍然产生大量不同理解，说明文档还没有完成有效的信息传递。
信息架构，英文简称IA，指产品中的页面、内容和功能应该如何分类、组织与呈现。
例如，一个电商App通常会包含首页、分类、购物车、订单和个人中心。如何划分这些模块，用户从哪里找到商品，订单信息放在哪一层，都属于信息架构问题。
好的信息架构能够让用户快速理解产品，并顺利找到需要的功能。
用户流程是用户为了完成某个目标，需要经历的一系列操作步骤。
选择商品 → 加入购物车 → 确认订单 → 填写地址 → 支付 → 查看结果。
产品经理不仅要画出正常流程，还要考虑库存不足、支付失败、地址无效、用户主动取消等分支情况。流程梳理得越清楚，后续原型设计和需求评审越顺畅。
线框图是一种低保真的页面表达方式，主要用于确定页面结构、信息层级、功能位置和基本布局。
线框图通常不强调颜色、字体和视觉细节，因为这个阶段最重要的是确认“页面上应该有什么”“内容放在哪里”，而不是讨论按钮应该用蓝色还是绿色。
先用线框图验证结构，可以避免团队在产品方向尚未确定时，过早把时间花在视觉细节上。
原型是在产品正式开发前，对页面、功能和交互过程进行模拟。它可以只有简单的页面跳转，也可以接近真实产品的操作效果。
相比单纯的文字说明，原型能让团队更直观地检查页面结构、操作路径和交互逻辑，也方便在开发前发现问题。
在实际工作中，产品经理通常需要借助原型工具把PRD变成可讨论的方案。例如，
摹客3是一款面向产品经理、UI/UX设计师和产品团队的原型与UI设计平台，提供原型模式和UI模式。产品新人可以利用内置组件快速搭建线框图，通过拖拽设置页面、组件和图层交互，再邀请团队成员协同编辑或评审。产品经理完成原型后，设计师还可以继续完善UI方案，并将设计稿交付给开发。这样一来，需求就不再只停留在文档里，而是能够被提前体验、讨论和验证，也能减少产品、设计与研发之间的理解偏差。
摹客3官方教程也提供了从线框设计、原型设计到协作交付的完整说明。
MVP是Minimum Viable Product的缩写，即最小可行产品。
它不是一个功能残缺、体验很差的产品，而是用尽可能少的功能，验证最关键的产品假设。
假设你想做一个AI简历优化平台，第一版不一定要包含模板市场、社区、求职课程和会员体系。先让用户能够上传简历并获得修改建议，就可以验证他们是否真的需要这项服务。
判断MVP范围时，可以问一句：如果删除这个功能，我们还能验证最核心的产品价值吗？如果答案是能，它可能就不属于第一版。
可用性测试是邀请目标用户完成指定任务，并观察他们是否能理解页面、找到功能和顺利完成操作。
测试过程中，不要急着告诉用户应该点击哪里。用户的犹豫、误操作和疑问，恰恰能够暴露产品设计中的问题。
可用性测试关注的不是用户喜不喜欢界面，而是他们能否有效、顺畅地完成目标。
A/B测试是同时向不同用户展示两个版本，通过数据判断哪个版本表现更好。
例如，一部分用户看到“免费开始”按钮，另一部分用户看到“立即体验”按钮，然后比较两组用户的点击率。
进行A/B测试时，应尽量只改变一个关键变量，并确保测试对象、时间和统计口径基本一致。否则，即使结果出现差异，也很难判断究竟是什么因素造成的。
用户漏斗是把用户完成目标的过程拆分为多个连续环节，并统计每一步剩余多少用户。
访问落地页 → 点击注册 → 填写信息 → 完成验证 → 首次使用。
如果大量用户停留在“填写信息”环节，就需要进一步检查表单是否过长、提示是否清楚，或者是否索取了不必要的信息。
漏斗的价值不只是展示数据，而是帮助产品经理定位问题发生在哪一步。
转化率是完成目标行为的用户数量，占进入该环节用户数量的比例。
转化率 = 完成目标行为的用户数 ÷ 进入该环节的用户数 × 100%
注册、下载、提交表单、购买和续费都可以作为转化目标。分析转化率时，必须说明统计时间、用户范围和具体行为，否则不同数据之间没有可比性。
留存率用于衡量一批用户在首次使用产品后，经过一段时间仍然继续使用产品的比例。
常见指标包括次日留存、7日留存和30日留存，但不同产品的合理观察周期并不相同。高频社交产品可能关注次日留存，低频企业服务则可能更关注月度使用和续费情况。
新增用户很多，并不代表产品真正成功。如果用户使用一次就离开，说明产品可能没有提供持续价值。
第一，不要孤立地背概念。把这些术语放进一条完整链路中理解：
找到目标用户 → 分析痛点和场景 → 整理需求 → 编写PRD → 设计流程和原型 → 制作MVP → 上线并观察数据。
第二，找一款自己熟悉的产品进行拆解。尝试写出它的目标用户、价值主张和核心用户流程，再思考它的MVP可能包含哪些功能。
第三，在实际工作中主动使用。术语只有被应用到需求分析、原型设计、评审沟通和数据复盘中，才会真正转化为产品能力。
产品术语是团队沟通的共同语言，却不是衡量产品经理水平的最终标准。真正重要的是，你能否理解术语背后的思考方式，并用它们发现问题、表达方案和推动产品落地。
