这份笔记把产品经理需要掌握的基础知识串成一条逻辑链：从文档规范起步，再到产品从无到有的过程。每个理论尽量按「定义 → 为什么重要 → 怎么做」展开，并配有案例（背景、问题、做法、启发），便于零基础反复阅读与练习。

一、产品文档撰写规范（PRD 的基本功）

PRD 全称 Product Requirements Document（产品需求文档）。产品文档（尤其是 PRD）是产品经理与开发、设计、测试沟通的「合同」。写得规范，执行就顺；写得模糊，容易返工和伪需求。

1. 命名规范

  • 定义：标题准确、简洁、无歧义；常见格式为「描述对象 + 版本号」。
  • 为什么重要：团队每天浏览大量文档，命名混乱会找错文件或用旧版。
  • 怎么做：对象细化到模块或功能；版本号便于追踪迭代。
  • 示例：《CRM（Customer Relationship Management，客户关系管理）系统 - 用户注册模块产品需求文档 V1.2.3》。
  • 小贴士：若已是终版且不再改，可省略版本号。

2. 表达规范

  • 定义：通篇使用客观、书面化专业表述。
  • 为什么重要：口语化显得不专业，也易引发误解。
  • 怎么做：避免「我觉得」「咱们下周」「接下来我们」等，改为「用户调研显示……」「根据数据分析……」「为满足 XX 需求，建议……」
  • 错误示例：「我觉得注册流程太麻烦，咱们简化一下吧。」
  • 正确示例：「用户调研显示，注册环节跳出率高达 42%，建议简化验证码输入步骤以提升转化率。」

3. 版本号规范

  • 定义：采用 V X.Y.Z（X 主版本、Y 次版本、Z 修订号）。
  • 为什么重要：文档会反复改，必须让所有人明确当前版本，避免用错。
  • 怎么做：
    • 首次发布：V1.0.0
    • 小改（措辞、细节）：Z + 1（如 V1.0.0 → V1.0.1）
    • 中改（新功能、流程调整）：Y + 1，Z 归零（如 V1.0.0 → V1.1.0）
    • 大改（架构、重大需求变更）：X + 1，Y、Z 归零（如 V1.0.0 → V2.0.0）

每次修改后，在文首放版本记录表：版本号、修订人、修订时间、修订内容、备注（影响哪些模块）。

PRD 核心结构（新手可直接套用）

完整 PRD 通常包含以下 7 部分：

  1. 文档概述（标题、版本、修订记录、阅读对象）
  2. 需求背景（为何做、解决什么痛点、数据依据）
  3. 用户画像（目标用户特征）
  4. 功能需求（流程图、交互、异常、字段定义）
  5. 非功能需求（性能、安全、兼容、埋点等）
  6. 数据指标与验收标准（如何衡量成功、测试通过条件）
  7. 风险与未解决问题

2026 补充：建议增加「AI 逻辑说明」：模型输入输出、概率与不确定性处理、幻觉（hallucination，模型编造不实内容）与风控对策。

练习建议：选一个简单功能（如登录页），按上述结构写一份 PRD，重点练异常场景描述。

二、产品设计核心词汇表

用户画像（User Profile）

  • 定义：根据社会属性、生活习惯、消费行为等抽象出的标签化用户模型，本质是「给用户贴标签」。
  • 为什么重要：只有清楚「谁在用」，功能才不容易跑偏。
  • 层级：画像体系 → 维度（基础信息、地理位置、兴趣等）→ 标签（越精准通常覆盖人数越少）。
  • 构建流程（7 步）：
    1. 采集数据（CRM（客户关系管理）、日志、API（Application Programming Interface，应用程序接口）、SDK（Software Development Kit，软件开发工具包））
    2. 数据清洗（去空、去重、纠错）
    3. 数据标准化（跨设备、跨账号统一标识）
    4. 用户建模（聚类、分类等）
    5. 标签挖掘（大规模计算）
    6. 标签验证（小样本真实案例）
    7. 数据可视化（柱状图、饼图等）

2026 趋势：实时动态画像与隐私合规（如 GDPR（General Data Protection Regulation，《通用数据保护条例》，欧盟）、国内等保）并重。

常用运营指标

指标 英文全称 含义
DAU Daily Active Users 日活跃用户（一日内去重登录/使用）
UV Unique Visitors 独立访客（常按设备计）
PV Page Views 页面浏览量（每次访问计一次）

其他常见指标：MAU（Monthly Active Users，月活跃用户）、留存率、Churn（流失率，客户/订阅流失比例）、NPS（Net Promoter Score，净推荐值）、ARPU（Average Revenue Per User，人均收入）等。

UI 与 UX

  • UI（User Interface）：可见可点的界面元素（按钮、输入框、菜单等）。
  • UX（User Experience）：使用产品的整体感受（是否顺手、是否可信）。

相关术语：Wireframe（线框图）、Prototype（可交互原型）、Mockup（高保真视觉稿）、Component（组件）、Modal（模态框）、SPA（Single Page Application，单页应用）、API（应用程序接口）、Responsive Design（响应式设计，适配多屏）等。

2026 现代词汇补充

AI-Native Design（AI 原生设计，自设计之初围绕模型与智能能力构建）、Agentic Interface（代理式界面，以自主代理为主交互对象）、Skeleton Loading（骨架屏加载占位）、Dark Mode（深色模式）、Accessibility（无障碍，常缩写为 a11y）等。

网页布局常见词汇

  • 结构：Header（页头）、Nav（Navigation，主导航）、Main（主内容区）、Sidebar（侧栏）、Footer（页脚）、Hero Section（首屏主视觉/吸引区）
  • 导航：Breadcrumb（面包屑路径）、Dropdown Menu（下拉菜单）
  • 组件：Card（卡片）、Carousel（轮播）、CTA（Call To Action，行动号召按钮/区块）、Modal（模态框）、Accordion（手风琴折叠面板）、Pagination（分页）
  • 布局与体验：Grid System（栅格系统）、Lazy Loading（懒加载）、Infinite Scroll（无限滚动）、PWA（Progressive Web App，渐进式 Web 应用）、Mobile-First（移动优先设计策略）

三、SaaS 产品基础知识

SaaS 定义

SaaS（Software as a Service）指供应商在云端提供应用，用户按订阅使用，无需本地安装，联网即可访问。

为什么重要：相对传统本地软件，降低了使用与试错成本；但供应商需持续迭代、标准化与 客户成功（Customer Success，围绕续约与价值落地的职能/团队），否则订阅易被取消。

核心特征：多租户（multi-tenant：一套部署隔离服务多个客户组织）、自动更新、订阅付费（席位、用量、效果付费等）。

发展与经营模式（简述）

  • 起源：如 Salesforce 等推动了订阅模式的可行性。
  • 中国语境：数字化与 SaaS 渗透近年明显加速。
  • 经营要点：标准化产品打底 + 适度定制增值；分销与直销组合；以客户成功为中心。定制化越低，往往毛利率越高。
  • 2026 观察：AI Agent 兴起，纯「记录型」SaaS 护城河承压；企业更倾向为「结果」付费；国内生态灵活，在 AI 原生转型中仍有结构性机会。

关键商业指标

MRR（Monthly Recurring Revenue，月度经常性收入）、ARR（Annual Recurring Revenue，年度经常性收入）、LTV（Lifetime Value，客户生命周期价值）、Churn（流失）、CAC（Customer Acquisition Cost，获客成本）等，用于判断产品是否持续为客户创造价值。

四、产品从无到有的完整过程

4.1 概念提出：寻找真正的机会

理论：产品概念不是随机 idea（创意/点子），而需同时想清五件事，再判断值不值得做：

  • 核心用户：目标用户中最关键、最典型的群体（不是「所有人」）
  • 刚性需求：最痛、最迫切的问题
  • 典型场景：痛点高频出现的时空
  • 产品概念：一句话说清你的方案
  • 竞争优势：相对现有方案的亮点

案例 1：智能长命锁

  • 背景：家长带孩子外出时普遍担心安全。
  • 核心用户：家有 3～5 岁儿童、时间紧、重安全的白领父母。
  • 刚性需求：走失与环境风险。
  • 典型场景：海滩、游乐园等户外场所。
  • 产品概念：外观像饰品的智能长命锁，含定位、超距报警、哭声报警等。
  • 竞争优势：家长可掌握位置，孩子因设计愿意佩戴。
  • 启发：同时满足「家长放心」与「孩子喜欢」。

案例 2：口碑网

  • 背景：外出就餐易踩雷，缺少可信的吐槽与分享渠道。
  • 核心用户：常在外就餐的年轻人。
  • 刚性需求：踩雷后想快速发泄并提醒他人。
  • 典型场景：餐后情绪高时。
  • 产品概念：餐厅列表 + 点评/吐槽。
  • 竞争优势：把个体坏体验变成可复用的避坑信息。
  • 启发：创始人真实痛点常是产品起点。

4.2 需求采集与用户研究

理论：既听用户「说」，也看用户「做」，定性定量结合。Z 字采集法常见顺序：

  1. 规划阶段（偏定性）：访谈、开放问题，形成需求清单
  2. 项目早期（偏定量）：问卷与统计，排优先级
  3. 实施阶段（偏定性）：原型可用性测试，观察真实路径
  4. 上线后（偏定量）：数据驱动持续迭代

临场感原则：尽量到真实场景里感受，否则容易脱离实际。

反面案例 1：智能浮标 App

  • 设想：鱼上钩时手机震动提醒。
  • 问题：钓鱼时常需盯水面，难低头看手机。
  • 原因：只听「要提醒」，未现场观察行为。
  • 改进方向：先现场观察，再考虑语音、硬件浮漂等组合。

反面案例 2：商场找车位 App

  • 设想：没车位时 App 帮找空位。
  • 问题：地库信号差；入口通道共用，余位与排队逻辑复杂。
  • 原因：未完整走「开车进地库」全流程。
  • 改进方向：离线能力、入口余位、排队与预期管理等。

反面案例 3：磁力手机充电线

  • 设想：借鉴笔记本磁吸线防跌落。
  • 问题：手机常边充边玩，磁力导致易脱落。
  • 原因：混用了「电脑静置充电」与「手持使用手机」两类场景。
  • 改进方向：磁力规格或可旋转结构等针对性设计。

4.3 转化：需求分析与多种常用理论

需求从「原始表述」到「可开发、可测试、可排期」，很少靠单一方法一次搞定。下面几种理论互补：有的偏把问题问全（5W2H），有的偏挖动机与任务（JTBD、Y 模型），有的偏分类与满意度（KANO），有的偏迭代取舍（MoSCoW），有的偏写成研发能接的条目（用户故事）。实际工作中常组合使用。

怎么选（极简对照）

目的 常用框架
访谈/评审时防遗漏、对齐事实 5W1H / 5W2H
区分「用户嘴上要的」和「真正要完成的进展」 JTBD、Y 模型
判断需求做不做、做了用户满不满意 KANO
本迭代 Must/Should 怎么划 MoSCoW
进入开发与测试语言 User Story + 验收标准（AC）

5W1H / 5W2H（结构化澄清）

  • 是什么：用一组疑问词把需求说完整、可核对。常见 5W1H：What（做什么）、Why（为什么做/解决什么）、Who（谁用、谁受影响）、When（何时、频次、时限）、Where（场景/终端/环境）、How（怎么做、流程约束）；5W2H 再增加 How much（多少量、成本与收益预期、指标）。
  • 为什么重要：减少「会上好像懂了、开发时发现关键条件没问」的返工。
  • 怎么用：需求评审逐条过；写 PRD 时缺哪一项就标红补访谈或数据。

Jobs to be Done（JTBD，待完成的工作）

  • 是什么：用户不是在「买产品」，而是在雇佣某个方案，去完成生活里的一项进展（Job）。经典表述是「在某种情境下，我想从 A 状态到 B 状态，因此愿意付出……」。常与人口统计标签脱钩：同类 Job 可能跨人群。
  • 为什么重要：避免只堆功能却完不成用户真正想推进的任务。
  • 怎么用：用 Job 语句重写需求；竞品对比时问「用户到底雇谁来完成同一项 Job」。

微例：用户买电钻，表面要「钻」，深层 Job 往往是「在墙上可靠地开孔挂东西」——方案可能是免钉胶、挂钩服务，不一定是更猛的钻头。

Y 模型（从「说的」到「该做的」）

理论：Y 模型强调「用心听，但不要照着做」：从用户的说法与行为，下钻到目标动机乃至价值观，再落到更合理的产品功能。

四个节点（示意）：

  1. 用户需求/场景：说了什么、做了什么（5W 中的 Who/What/Where/When：谁、何事、何地、何时）
  2. 用户目标/动机：真正想达成什么（Why：为何）
  3. 人性/价值观：更底层的驱动（如需求层次）
  4. 产品功能：给出的方案（How：如何做）

案例 1：银行转账

  1. 表面：用户在柜台说「要转去招行」。
  2. 真实目标：安全、低成本到账。
  3. 价值观：安全、省钱。
  4. 可能的最优解：柜员建议开本票等更低费方案——若直接按用户说的方式做，可能又贵又委屈。

案例 2：淘宝快递单打印

  1. 表面：小快递公司都要单独模板。
  2. 真实目标：快速、准确打出面单。
  3. 价值观：高效、少出错。
  4. 最优解：自定义面单（底图 + 拖拽字段），一套机制覆盖大量承运商，避免页面与开发爆炸。

攀梯术（深挖人性，常配合 Y 模型）

从产品属性（A）连续问「为什么」，直到触及个人价值/价值观（V）。

示例：果酒

  • 喜欢果酒（A）→ 为什么？酒精低。
  • 为什么要低？喝得慢、有饱腹感。
  • 为什么要喝得慢？瓶身与设计显得「成熟」。
  • 为什么需要显得成熟？职场社交、归属感（V）。

卖点启发：不止讲口感，可关联「体面、社交、归属感」等叙事。

用户故事与验收标准（User Story + AC）

  • 是什么：用户故事常用模板「作为……（角色），我希望……（能力），以便……（价值）」——英文常见 As a / I want / So that。验收标准（Acceptance Criteria，AC）把「怎样算做完」写成可测条件（Given/When/Then 或条目清单），避免笼统形容词。
  • 为什么重要：把需求推进到可开发、可测试、可拆任务；利于和敏捷协作对齐。
  • 怎么用：一条故事对应一条主路径；边界、异常、权限写进 AC。可结合 INVEST 原则自检（Independent、Negotiable、Valuable、Estimable、Small、Testable：独立可谈、有价值、可估算、够小、可验证——各书表述略异，抓精神即可）。

KANO 模型（需求属性与满意度）

狩野纪昭（Noriaki Kano）提出，用功能存在与否与用户满意度的关系，把需求分成几类，指导取舍与沟通预期。

类型 大致含义 产品侧提示
必备型（Must-be / Basic） 没有会强烈不满，有了只觉「本该如此」 先保证底线，少拿它当宣传点
期望型（One-dimensional / Performance） 做得越好，满意越高 主战场：性价比与体验曲线
魅力型（Attractive / Delighter） 没有时无所谓，有了很惊喜 可做差异化，但要防止被对手抄成期望型
无差异型（Indifferent） 有没有都差不多 优先砍或降本
反向型（Reverse） 有了反而讨厌 谨慎，常需开关或分层

注意：同一功能随时间可能从「魅力」滑成「期望」再变「必备」，需周期性复盘。

MoSCoW 优先级法

  • 是什么：把需求划为 Must have（没有就不能达成迭代目标/上线标准）、Should have（重要但可短暂妥协）、Could have（锦上添花）、Won’t have（本阶段明确不做）。W 常写作 Won’t have (this time)，避免无限膨胀。
  • 为什么重要：把「都重要」翻译成可执行的排期语言，和干系人对齐边界。
  • 怎么用：每一类都尽量绑定可验证的定义（例如 Must 与核心指标或合规绑定），避免全进 Must。

小结：从分析到落地

先用 5W2H / JTBD / Y 模型把问题和动机写清楚，再用 KANO 看属性与预期，用 MoSCoW 定本迭代范围，用 User Story + AC 交给研发与测试。下一节的 MVP 讨论的是：在已排序的需求里，如何用最小成本验证最大不确定性。

4.4 功能细化、打包与 MVP

理论：对功能做价值与成本评估，再打成 MVP（Minimum Viable Product，最小可行产品/最小可用产品）：只含验证核心假设所必需的能力，先上线再学。需求属性与满意度分类（KANO）、迭代取舍（MoSCoW）见 4.3，本节侧重「打包成 MVP」的节奏。

价值感：性价比 ≈ 商业价值 / 开发量；商业价值又与用户广度、单用户价值、使用频度等相关。

案例：Zappos（美国鞋类电商，现属亚马逊）

早期用极简页面验证「是否有人愿意网上买鞋」，下单后人工采购发货跑通流程，再逐步建系统。启发：MVP 是用最小成本验证最大不确定性，而不是「功能少随便做做」。

4.5 运营与商业模式

理论：运营把能力翻译成用户能听懂的「故事」：目标用户、场景、问题、功能、收益。商业模式画布等工具可帮助梳理闭环（细分客户、价值主张、渠道、收入、关键活动与资源、合作、成本等）。

案例：星巴克（节选）

  • 容量与定价：略增容量、小幅加价，利用锚定等心理。
  • 杯型命名：Tall / Grande / Venti 等，影响默认选择。
  • 会员与券：年度清零、短有效期等，结合损失厌恶创造复访。

启发：运营常是顺应人性与场景的设计，而非硬推。

五、产品经理个人修养与 2026 AI 时代

产品经理需要持续锻炼同理心、临场感与结构化思维。生活中也可以练习：例如改造卫生间时，不只问「要不要浴缸」，而是结合起居动线（老人起夜照明、台面高度是否顺手等）。

2026 AI 时代：产品经理角色往哪走？

AI Agent（智能体/代理：能感知环境、调用工具并多步推理以完成目标的程序或系统）普及后，传统「记录型」能力易被整合进代理式工作流；定价从纯席位转向「效果」与混合模式更常见。产品经理更需要把 Y 模型用在 代理式工作流 上：从「帮用户记」走向「帮用户推进结果」。角色不会简单消失，而是向 AI Orchestrator（AI 编排者）、AI PM（AI 产品经理）等形态进化。

传统「只写 PRD、画原型、管 backlog（待办需求列表/需求池）」的通用型 PM（Product Manager，产品经理）压力增大，但产品思维本身更值钱：AI 适合承接调研摘要、初稿、部分分析与低保真稿；难以替代的是同理心、战略取舍、跨团队对齐、伦理与合规判断，以及在不确定性里定义「什么值得做」。

任务层面：AI 已经覆盖什么？

  • PRD 初稿、用户故事、竞品要点、实验与埋点建议、低保真原型等，工具链已较成熟。
  • 「纯翻译需求」的空间在缩小：自然语言到实现的路径在变短。

价值层面：PM 更该押注什么？

借 Y 模型看 2026 年的分工感：

  • 需求场景：AI 能总结，但临场感与现场观察仍依赖人。
  • 目标/动机：浅层动机 AI 可辅助，深层人性与商业语境仍靠人。
  • 伦理与价值观：是否符合伦理、是否 dark pattern（暗黑模式/欺骗性设计：用界面误导用户决策；与上文 Dark Mode「深色主题」不是一回事）、是否真改善生活——需人承担责任。
  • 产品形态：越来越多体现为 Agent 工作流：哪些步骤自主、哪些 Human-in-the-Loop（HITL，人在回路：关键节点由人审核或纠偏）、失败如何降级与回滚、token（模型计费与上下文用 token 计）与算力成本相对业务价值是否划算。

新核心能力画像：更像 AI 系统设计与商业风险决策者，而不只是「功能清单经理」。

2026 年常见的三种角色方向

  1. AI Orchestrator（编排者）：多 Agent 协作、分工与边界（何时沉默、建议、自主行动）。
  2. AI Product Manager：面向 AI 原生产品，理解模型能力边界、幻觉、RAG（Retrieval-Augmented Generation，检索增强生成）、Agentic（代理式/多步自主）流程等。
  3. Full-Stack PM（全栈产品经理：产品、部分技术或增长边界更宽）/ Agent Manager（代理管理者）：产品、增长与运营边界更模糊；小团队用多 Agent 跑通闭环已更可行。

对传统 PM 的务实建议

  • 相对安全：Y 模型、临场感、商业判断、工作流与风控设计。
  • 风险较高：只会画原型、堆文档、机械管需求。
  • 可优先补的能力：Agent 工作流（Prompt（提示词/指令）、工具链、监控）、单位经济性（token 与基础设施 vs 业务价值）、伦理与数据合规、合成研究 + 真实验证、用更低成本做 MVP 验证。

机会窗口（尤其 SaaS）

  • 「记录型」能力被整合后，客户更愿意为结果与效果付费。
  • 垂直行业 AI-Native 仍有增量空间。
  • 小团队 + Agent 的「一人公司」形态在部分场景已可落地。

总结：2026 年的产品经理，从「把需求翻译成产品」进化成「把商业目标翻译成 AI Agent 工作流」。职位并未消失，反而更强调稀缺能力；市场上有观点认为 AI PM 的薪酬带可能高于传统 PM 一截（区间因地区与公司差异很大，需以实际招聘为准）。真正被淘汰的不是人，而是不愿意持续进化产品思维的人。