产品经理方法论
基本概念
用户-需求-产品
在产品经历的工具箱中，有一组最基础的概念------用户、需求与产品。它们像三角形共同决定了产品世界的几何形状，同时也奠定了产品经历的稳定基础。
产生
设计
服务
用户
需求
产品
-
三角形的原点：
用户用户是所有故事的起点。他们即是生理或心理诉求的"人/群体"，也是最终决定产品命运的评判者。
产品经理的第一要务，是洞察并尊重这种诉求，而不是把注意力仅放在功能清单上。
-
连接边：
需求当用户的具体愿望被捕捉、被整理，它就净化为"需求"------一份可分析、可评估、可优先级排序的行动指令。需求让用户与产品之间出现了可以度量的关联，它即来源于用户、又指导着产品。
-
对抗边：
产品产品是满足需求的方案，是需求的物质化或虚拟化呈现。狭义上，它是一个 App、一台设备或一项服务；广义上，它还可以是流程、组织甚至理念，只要能为用户带来价值。
-
新的坐标系：
人/群体为了让三角形真正稳固，在模型中引入了"人/群体"这一基本单元。先有"人/群体"，才有了需求；有了需求，才有了产品；而产品最终又服务于"人/群体"，形成闭环。这一调整避免了循环论证，也让概念之间的边界感到清晰。
-
从三角形到体系：
角色与流程一旦厘清"人/群体-需求-产品"关系，产品经理的工作路径就自然展开：
- 从用户调研、需求挖掘，到撰写需求文档
- 从功能设计、流程图、原型图，到与研发、设计、测试团队协作；
- 从上线迭代、数据监控，到运营和商业分析。
这一连串恰好对应了本书后续章节的方法论，从宏观上看，他们都是"需求驱动产品，产品服务人/群体"这一主旋律的分声部演奏。
何为好产品
想要一款产品真正打动人，不止"能用"那么简单：
先解决真实需求------产品必须围绕用户到底想要什么来设计，否则再花哨也只是摆设。体验要超出预期------功能好用、界面友好，让用户觉得"用起来真顺手"，才愿意反复回来。还得会赚钱------再优秀的产品如果商业模式跑不通，就像漂亮的花瓶摆在家里没人买账。
一句话：好产品=有用+好用+可持续。只有三者兼顾，才能既让用户喜欢，也让公司赚到钱，毕竟商业逻辑从来都是产品成功的幕后大佬。
角色定位
- 先做用户"侦探"
蹲坑调研、访谈、画用户画像，搞清"他们到底想要啥"。 - 再当需求"裁判"
价值高低、优先级排序，把最有戏的需求往前排，让团队少走弯路。 - 还要当团队"指挥官"
从需求到设计、研发、上线，全流程盯紧，确保 everyone on the same page。 - 别忘了自我"园丁"
产品像花，需要不断浇水施肥------持续学习、复盘、迭代，才能花开满园。
产品经理既是用户的研究员、需求的把关侠，也是团队的指挥官和产品的造梦师。定位找准，你就能在职场交响乐团里奏出最闪亮的旋律！
产品经理知识体系
如果把产品经理的成长地图摊开，你会发现它围着三个"超级英雄"打转------用户、需求和产品。
- 用户篇：围绕用户这个基本概念，衍生出用户挖掘、用户分析、用户调研、用户访谈、用户画像的知识。
- 需求篇：围绕需求这个概念，衍生除了需求识别、需求分析、需求真伪评估、需求价值评估、需求评审、需求优先级评估、需求池管理等知识。
- 产品篇：围绕产品这个基本概念，衍生出了产品定位、产品分析、行业分析、商业分析、产品设计、产品管理、产品数据分析等知识。
这三个模块相辅相成：用户催生需求，需求定义产品，产品又反哺用户。
撰写产品文档
撰写产品文档基本方法
产品文档的撰写过程是将个人思想转换为文档的过程，只要掌握文档的撰写方法和规范，就可以万变不离其宗，以不变应万变。
文档详解
相关模板参见指定文件下载
商业需求文档（BRD）
Buniess Requirement Document
核心定位：面向决策层（老板、投资人）的「商业价值论证文档」，核心目标是证明 "做这款产品能带来商业回报"，争取立项资源（资金、人力）。
通俗 + 专业理解：就像向决策层提交的 "项目商业提案"------ 不仅要说明 "职场人需要高效协作工具"，还要用数据支撑："国内职场协作工具市场规模年增 25%，目标用户（中小微企业员工）达 8000 万，产品定价按年订阅制（基础版 399 元 / 年），预计 18 个月回本，3 年累计营收破亿"，同时分析竞品格局、盈利模式和风险管控方案，最终说服决策层 "这个项目值得投入"。
核心专业内容：
- 市场分析：目标市场规模（TAM/SAM/SOM）、增长驱动因素、政策环境；
- 商业模型：盈利模式（订阅制、增值服务）、定价策略、成本结构（研发 / 市场 / 运营）；
- 财务测算：投资回报周期（ROI）、营收预测、盈亏平衡点；
- 风险评估：市场竞争风险、技术落地风险、政策合规风险及应对预案。
市场需求文档（MRD）
Market Requirement Document
核心定位：面向产品、市场、销售团队的「需求洞察与定位文档」，核心目标是明确 "产品为谁做、解决什么核心痛点、差异化优势是什么"，为产品规划定方向。
通俗 + 专业理解：相当于 "用户需求白皮书"------ 通过用户调研（访谈 50 家中小微企业、问卷 2000 份）发现：核心用户是 25-40 岁的职场白领（产品 / 运营 / 行政），核心痛点是 "跨部门协作信息割裂、任务跟踪低效、文件版本混乱"，而竞品要么功能冗余（学习成本高）、要么免费版限制多（无法满足团队协作）。MRD 会明确这些需求优先级（用 MoSCoW 法则划分 Must have/Should have），并定义产品差异化定位："轻量化、零学习成本、支持多场景快速协作的免费基础版 + 增值服务模式"。
核心专业内容：
- 用户画像：目标用户 demographics（年龄 / 职业 / 企业规模）、行为特征、决策链；
- 痛点分析：用户核心需求（功能 / 体验 / 成本）、痛点优先级、场景化痛点描述；
- 市场定位：产品差异化优势（与竞品的功能 / 价格 / 体验差异）、目标市场细分；
- 需求验证：调研方法（定性访谈 + 定量问卷）、样本特征、需求置信度分析。
产品需求文档（PRD）
Product Requirement Document
核心定位：面向研发、设计、测试团队的「执行手册」，核心目标是明确 "产品具体长什么样、功能怎么实现、有什么规则约束"，确保各团队执行口径一致。
通俗 + 专业理解：就像产品的 "施工图纸 + 验收标准"------ 不仅要写清 "有任务创建、文件共享、进度跟踪功能"，还要明确专业细节："任务创建功能支持设置标题（字符限制 200 字）、负责人（单选）、截止日期（日期选择器，支持跨年月）、优先级（高 / 中 / 低）；点击「提交」按钮后，系统自动发送通知给负责人（站内信 + 邮件）；文件共享支持最大 500MB，支持 Office / 图片 / 视频格式，支持版本回溯（保留最近 10 个版本）"，同时包含界面原型、交互逻辑、异常场景处理（如网络中断、文件上传失败）、验收标准等。
核心专业内容：
- 功能模块：核心功能清单、功能逻辑流程图、模块间交互关系；
- 详细规格：字段定义（类型 / 长度 / 约束）、交互逻辑（点击 / 输入 / 跳转规则）、界面原型标注；
- 非功能需求：性能指标（响应时间≤2 秒、并发支持 1000 人）、兼容性（支持 Chrome/Edge/Firefox 最新 3 个版本）、安全性（数据加密存储、权限分级）；
- 验收标准：功能验收点（可量化、可验证）、异常场景处理标准、用户体验要求。
产品架构图
定义及分类
产品架构图是产品的骨架， 用可视化方式呈现产品的的核心模块、模块间的关联关系、数据流向、用户角色交互路径，以及产品与外部系统的对接逻辑。
互联网行业中，产品架构图常见类型：
- 业务架构图：聚焦用户要做什么，呈现核心业务流程和模块（如电商产品的商品浏览、下单、支付、物流等模块）
- 功能架构图：聚焦产品有什么功能，按模块拆分具体功能点（如下单模块包含创建订单、订单校验、订单提交）
- 技术架构图：聚焦技术怎么实现（研发角度），包含服务器、数据库、中间件、接口等
业务架构图
功能架构图
技术架构图
