对于产品经理来讲，产品工作多而杂，这种情况下只能进行整理，下面文章是笔者分享的关于产品工作核心要点整理的内容，感兴趣的同学可以进来学习学习哦！

一、产品经理工作流程及内容

1. 产品规划

• 对行业整体下的产品定位及战略规划。
• 对产品自身系统及功能建设的迭代规划。

2. 需求调研

1）竞品调研

①调研对象：

• 与该产品的核心业务的同行业对比。
• 与同样满则该产品的核心功能的产品对比。
• 与使用该产品的用户群体的其他产品对比。
• 在同一时间内或同一场景内同时存在的产品对比。
• 与同样满足该产品满足用户的需求的产品或替代品对比。
• 与该产品的更低或更高阶阶段的产品对比。

②调研维度：

• 表现层（视觉及美感）。
• 架构层（界面布局和信息内容）。
• 结构层（交互和框架结构）。
• 范围层（功能和业务范围）。
• 战略层（战略目标及业务目标）。

2）自身产品调研：

①调研对象：

• 产品用户
• 竞品用户
• 内部人员
• 用户购买决策者（部分产品购买与使用者主体不一致）。

②调研方法：

1. 问卷
2. 访谈
3. 数据收集
4. 模拟实验

3. 需求分析

• 分析需求的真伪，是否合理。
• 分析需求的深层含义，找出核心诉求及痛点。
• 判断该需求是否可持续、是否长期稳定存在。
• 分析该需求的价值，是否对产品体验及整体方向一致或有帮助。
• 分析满足该需求的成本，计算投入产出比，判断是否需要满足，或现阶段满足。
• 判断该需求的优先级，计时符合以上条件，对正向反馈的提升有多大，排优先级。
• 该需求的延伸需求有哪些？以及是否可以去其他需求一起实现满足功能，方便后期扩展？以及降低实现成本？
• 要求：同理心、场景化、多角度多角色、多维度、多阶段的进行分析。

4. 输出方案

• 原型：几乎所有需求都需要，帮助开发理解，部分公司原型由交互产出。
• PRD：若原型里有逻辑描述，则不需要，视情况而定。
• 思维导图：辅助使用，内容复杂时需要，看需求。
• 流程图：逻辑复杂时需要，分析需求，梳理逻辑时需要。
• MRD（部分公司部分场景需要）：跟PRD比侧重商业及业务逻辑，少了方案细节内容。

5. 沟通及评审

①沟通：

1. 前期准备
2. 沟通过程

• 阐明业务背景及价值。
• 可以引导但是不要全部自己说，不给用户及需求方表达需求的机会。
• 沟通时同时也是需求调研及分析的过程，倾听的同时，分析底层原因。
• 沟通时做好流程梳理，可一边沟通一边梳理，当场确认。

沟通结果

• 需求目的、需求范围进行明确。
• 业务逻辑、产品逻辑及流程明确。
• 求优先级明确。

②评审

评审准备：评审前沟通、确认并通知与会人员、准备会议材料。

前期沟通：

• 核心人员前期初步沟通确认方向与主要内容。
• 提前1-3天发出原型活其他材料帮助提前了解。

与会人员：

业务评审的与会人员主要有：

1. 业务
2. 产品
3. 项目经理

技术评审额与会人员主要有：

1. 开发
2. 测试
3. 用研
4. 产品
5. 项目经理

会议材料：流程图、原型等

评审过程 ：

1. 讲解流程+细节
2. 问题讨论
3. 答疑

会议纪要：

1. 会议内容
2. 待办事项
3. 依赖项

6. 产品验收

• 验收功能范围
• 验收功能逻辑

7. 上线后反馈及数据分析

• 反馈跟进：产品数据、用户反馈、内部反馈、技术监测。
• 产品数据：用户数据、功能数据、业务数据、辅助数据。
• 用户数据：基础数据、用户行为数据。
• 基础数据：地区、时间、、学历、爱好等。
• 用户行为数据：PV、UV、点击、月活、日活、停留时长、页面转化等。
• 功能数据：筛选数据、搜索记录、退单原因等。
• 业务数据：销量、转化、复购率、渗透率、当期成交量、当期成交率、投诉率等。
• 辅助数据：满意评价、用户对店铺/酒店评分。
• 用户反馈：意见反馈、客服反馈、外部舞蹈反馈（舆情监控）、用户调研。
• 内部反馈：UED调研、产品复盘。
• 技术监测：埋点、报文。

8. 数据分析

对比分析、转化分析、分层/分组分析、用户反馈分、基础监测数据分析、行业内数据分析等。

二、产品经理的工作产出及要求

1. 原型

产品架构图

• 产品层级（举例）：用户层、管理层、支撑层、数据层。
• 内容层级：业务/大场景、系统、功能、子功能、角色、规划节奏（已有、目前、未来）。
• 交互关系：层级之间、系统之间。

产品框架图: 按照功能层级/页面层级编辑原型页面。

原型布局：需符合用户操作流程、便于理解。

符合用户操作流程：

1. 原型附带交互流程功能，需按照浏览习惯从左到右，从上到下，并按照主流程、辅流程逻辑进行排列。
2. 同一页面或功能，对于角色/维度较多或同角色/同纬度内页面较复杂时，需分组框定/标记，并注明区分逻辑。

便于理解：

1. 对于二级页面及功能放置于独立新画布时，需先贴上上一级页面或入口，便于理解改页面或功能的来源。
2. 页面平铺时，需使用辅助箭头，指明页面内按钮及页面之间的交互流程。

页面名称：

1. 原则：名称需与页面内容/页面名称一致，利于内部沟通理解，也利于原型页面之间交互逻辑说明。
2. 要求：页面名称需简洁；多状态多场景多角色状态页面内容不同时需在页面名称上区分，例如：个人中心-未登录、个人中心-已登陆。

页面原型图：

1. 原型图组成：文字/标题/内容、图片、　icon、线框。
2. 注意项：不要太大，影响观感；尺寸按照iphnone6或12为页面尺寸框架；多个页面的原型风格需统一；注意第一屏所覆盖的功能范围，是否符合产品目的及用户体验。
3. 功能逻辑。

方法：原型页面/功能点与说明项进行标号及将标号对应，必要时还需用颜色进行区分标号；原型功能内容与描述逻辑位置相对应，便于观看。

组成：前置条件、触发条件、功能类型。

前置条件：账号状态、授权情况、用户角色、时间阶段、动作操作等。

触发条件：动作（点击、浏览）、状态变更、时间变化等。

功能类型：展示项（图片、文字、图文、等）、按钮项（查询、新增、删除、编辑等、筛选项（筛选功能）、输入项-类型（文字、图片、数字、时间等）、输入项限制（类型限制、长度、是否比他、选择时单选、多选、编辑时是否可修改、是否可删除（可删除是否二次确认、删除后交互效果、删除类型为物理删除、逻辑删除；不可删除是否有交互表现）、是佛默认填充、默认填充（默认内容、内容来源条件（慢则条件时、不满足条件时））。

功能描述：角色、场景、功能内容、功能逻辑、操作后效果、突发状况、特殊状况

• 角色：C端用户（举例）：已注册用户、未注册用户、已登陆用户、未登录用户。
• B端后台：销售、运营、管理员、客服、财务、其他。
• 场景（举例）：用户界面不可操作退款，但用户找客服申请退款，客服同意退款后，可在后台才操作退款。
• 功能内容（举例）：点击“X”按钮后，弹窗弹出，可编辑XXXXXX，点击保存后保存。
• 功能逻辑（举例）：

1. 新建状态下，不需输入XX ID，保存后系统自动生成；
2. 编辑状态下，不可更改XX、XX、XX，若点击结束，结束时间修改为当前时间，状态变更为：已结束；
3. XX 已结束后不可修改。

• 操作后效果：状态变化、内容变化、跳转链接。
• 突发状况/特殊情况：略

注意：多状态多条件下的不同功能逻辑去进行区分，分段说明。

2. PRD

包含：

• 编辑记录
• 目录
• 内容

1. 一级功能/二级功能/三级功能/…
2. 前置条件
3. 触发条件
4. 功能类型
5. 功能描述
6. 突发状况/特殊情况

注意：多状态多条件下的不同功能逻辑去进行区分，分段说明。

3. 思维导图

• 页面/功能维度
• 场景维度
• 角色维度

4. 流程图

用户操作流程图：

• 体现用户浏览页面动作
• 体现用户点击动作
• 体现功能状态
• 体现判断节点
• 体现异常情况
• 多用户角色时需多泳道

系统串联流程图：

• 多泳道
• 体现流转的内容
• 其他同用户操作流程图

5. MRD

• 产品/本期目标
• 全局规划
• 关键要素
• 行动计划

6. 数据分析

a. 分析节点：

• 日常分析
• 版本分析
• 阶段分析
• 转型/其他场景分析

b. 设计分析思路：

• 总分分：从整体数据差异中反向查找差异原因。
• 分分总：分层分部分析后得出总体结论。

c. 数据呈现：

• 数据表
• 图形

d. 标记：

• 特殊数据或差异数据特殊颜色标记。
• 关联数据或关键数据特殊标记。

e. 复盘：

• 分析原因
• 同等数据在其他时间或其他维度进行对比，是否通用；反查结论是否有用、有价值。