首页  思维导图  详情

产品经理能力模型

2021-03-04 11:43:34   10  举报





AI智能生成

为你推荐

查看更多



产品经理核心能力框架

产品经理能力模型

最全的产品经理能力模型

产品经理

产品规划

产品设计

工作流程

作者其他创作

大纲/内容

产品经理能力模型

用户分析

用户画像

用户画像分析

目的

通过对目标用户所具特征的一种具体形象的描述，给用户贴上各类标签，通过这些标签将用户分为不同的群体，以便对不同的群体分别进行痛点或者需求的分析。

分析内容

基础信息

基础属性

工作岗位

工作角色

业务相关

与当前业务相关的特征

执行计划

在产品中实际的执行步骤

用户痛点

使用产品时的痛点

行为特征

在产品中产生的行为

工作目标

使用产品要达到的最终目的

态度与观点

对产品的正向/反向态度及对应观点

需求期望

对产品提出的需求模块、需求点、优化设计等

竞品分析

竞品选择

竞品分类

功能完全相同的竞品

找出当下产品的核心价值，评估与我方设计目的与市场上成型产品的一致性

更快更好地借鉴对方取得成功的地方

有针对性地寻找差异化竞品的方向

核心功能相似的竞品

通过以点带面地挖掘价值点或创新点

排列组合式地寻找核心功能相似的竞品

可寻找到的竞品会更加全面，值得借鉴到的价值点会更多

功能本质相同的竞品

加深对待设计产品需求本质的理解，通过本质相同挖掘需求的核心所在

从大方向入手横向选择竞品，在其他领域中得到解决问题的启示

该类竞品最容易发现亮点和突破点

竞品选择的依据

五个维度

功能匹配度

功能亮点

用户群情况

热门程度

下载量/使用量

竞品收集

核心思路

在紧扣目标用户核心诉求的前提下，尽可能多的找到各种能满足用户核心诉求的产品。

收集方法

在应用市场、专业网站、行业调查报告中寻找竞品

通过这种方式找到可见可用的竞品，而非停留在概念上的竞品

通过市场评分、下载量、产品介绍初步对竞品做一个判断，便于后续的收集和选择

使用搜索引擎寻找竞品

借助搜索引擎大数据，找到众多相关的竞品，拓展竞品的涉猎范围

通过访谈产品的潜在目标用户寻找竞品

可以直接询问到当前市面上用户平时喜欢使用哪款产品

进一步了解用户想法和需求点

核心功能是否还能通过其他方式实现

将竞品的核心功能分为几个维度，从线上倒推线下去考量

部分功能扩大

从重点功能入手，寻找更多可借鉴的产品

其他行业是如何做到的

跨行业参考其他行业是如何进行产品设计的

不局限于参考产品的主要用途，借鉴竞品在其他行业中达成的目的方式

通过过程、操作的碎片化寻找竞品

将产品的结构、使用过程、操作等进行拆解，根据每一个碎片信息寻找竞品

通过重要干系人的需求分析提炼关键词，收集关联竞品

分析重要干系人的需求，提取更多的关键词，进一步收集更多的竞品

为自身产品设计提供产品模式、架构、功能的快速借鉴，利用其设计点。

快速思考竞品在“本质”方面的相似之处，吸收并内化到现有产品中，得到各种创新可能。

竞品概况

穷举大量竞品，分析市场情况与各个竞品的特点，竞品分级与选择

竞品战略分析

产品定位

运营策略（核心竞争力）

竞品分析要点（优缺点）

范围层（主要功能）

全功能列表

功能数据分析

结构层（信息架构）

信息流程

页面层级

界面布局

框架层（交互设计）

交互样式

表现层（视觉设计）

布局

颜色

样式

文案

发展趋势

竞品市场份额趋势

竞品版本更新内容的方向

市场竞品趋势

热度

新竞品的出现

竞品分析报告

需求管理

需求调研

用户需求调研问卷

调研方式

用户访谈

用户分类

高级管理人员

目标

探讨产品的目标与范围

调研要点

列举部分主要问题

提供相应案例的解决方案

列举潜在问题

备注说明

确定产品的范围/确认已知问题，探讨潜在问题，标示关键点

业务经理

理清业务脉络

了解工作流转流程

列举相关的业务时间列表

准备一些业务事件的关键点问题

收集审批流程、权限的设定以及业务部门的边界

确定每个业务事件的流程、流转的数据、相关参与者，明确控制点以及审批流程

操作人员

获得业务操作过程

了解每个节点的需求痛点

罗列相关业务活动

获取相关业务规则以及数据关联信息

获取相关业务节点和流转过程

从基本情况、功能、实际应用、设计约束等多个角度设计调研问题

财务人员

获得财务流转过程

了解安全性问题

获得财务统计方式

获得财务对业务的必要数据关联信息

获得财务对业务节点的介入时机以及方式

确定财务中的审批流转方式，业务数据字段以及财务相关的记录方式

问卷调研

问卷内容

基本信息

所属部门

调研对象岗位&姓名

调研形式

针对产品

调研时间

调研提纲

岗位与该产品相关的工作内容有哪些？

业务的处理流程和时间节点是什么？

业务工作的输入、处理、输出是什么？

业务工作中的依据、资料、表格是什么？

在这些工作中，各环节处理的耗时和一周处理的频次？

在这些环节中最痛苦的地方是什么？

对该产品有哪些想法和建议？

情景调研（实地考察）

现场观摩用户的实际工作步骤，达到业务场景重现的目的

调研步骤

创造用户平日工作时使用产品的场景

观察用户在熟悉的场景下如何进行操作

对需求与业务流程建立更直观的认识

观察细节思考任务的步骤、找到脉络

对观察结果形成落地说明

需求筛选

确定哪些需求对目前产品来说价值最大，由此来判断需求的价值和优先级。

优先级确认后，得出现阶段要开发的需求，明确核心需求和场景，为产品设计提供依据。

筛选依据

是否符合产品定位

是否是目标用户的需求

细分后目标用户群大不大

是否是产品当前生命周期内必须要解决的需求

需求频率大不大

能否对业务或用户产生正面影响

需求是否有延伸性

目前技术能否支持该需求的实现

技术基础知识

技术实现原理

表现形式

需求分析

需求的深层性

第一层：观点，加工后的诉求

某个用户或传达者给产品提出“诉求”

属于传达者对需求通过自身认知的加工后，呈现出的结果

需要对提出的“诉求”进行深入挖掘

第二层：动机，是加工的原因

挖掘用户提出诉求的背景或原因

通过用户的表述，还原加工过程

第三层：本能，是要满足的需求

用户内心深处的真实需求

将“诉求”还原成人的本能需求

使产品尽可能满足用户更多的需求

真正需要解决的需求

需求的变化性

关注用户群变化引起的需求变化

同一用户不同场景下需求的满足

关注部门、岗位、角色变化引起的需求变化

解决的话会带来什么

针对用户

是否可以提升用户体验

是否可以提高工作效率

是否可以提升某项指标

不解决的话会影响什么

是否会增加反馈

是否会增加投诉

是否会令指标异常

其他

问题能解决到什么样的程度

是否与其他功能、服务有关联或者影响（逻辑、流程、数据...）

是否在现有的功能中已有解决方案

结合当前生命周期的产品条件是否能体现出该需求的价值

结合目前趋势是否符合该需求的上线条件

成本核算

人工成本

产品/功能开发天数（工作日）乘以

参与人员工资

公司承担的人员社保费用

公司公摊费用

水费

电费

物业费

房租费

设备费

折旧费

......

采购费用

项目所需半成品采购费用

项目部署费用

服务器

域名

关联三方费用

需求池

成本核算报告

产品设计

功能结构梳理

信息结构思维导图、功能结构思维导图

确定产品功能结构

分析并传递该产品的功能结构

设计步骤

确定产品的所有功能

确定产品的模块

确定子模块或子功能

流程梳理

业务流程图、功能流程图、页面流程图

基本原则

获取详细、真实的业务流程

从业务部门直接获取

即业务部门已整理好的流程

弊端

缺乏完整性和可扩展性

产品经理观察、了解业务流程

模拟业务流程，落实为流程图

与业务部门核实，逐一完成各个节点的流程

将业务拆分为产品功能

按用户来拆分不同的功能

不同的用户角色整理不同的功能流程

泳道图

按功能来拆分

整体功能拆分为小的功能模块

减少重复工作，提高操作效率

相同属性和内容的业务在流程图中合并

适合线上处理的原则

涉及数据留存的业务，线上更方便查阅资料

能提高效率的业务流程，比如多部门协同操作的业务

可以提炼形成企业规范，推广至整个企业使用的流程

先做必要性的流程

从产品的易用性和准确性考虑，关注大多数用户的使用情况，先做优先级最高的流程

具体步骤

按生产活动定好生产岗位

确定流程需要完成的目标和最终输出

根据输出结果倒推前一步的产物，依次往前类推

确定每一步产物需求的生产活动

确定各个生产活动之间的关系

调整完善

交互原型

作为沟通工具，将抽象的需求具像化，提高项目协作的效率，评估需求的可行性，使参与人员能够查看、使用并给予反馈。

包含内容

展示完整的功能模块

展现完整的流程

界面以及界面中的元素展现需求的所有功能点

界面中元素的各种状态说明

元素操作后的效果

异常、极限状态的说明

设计考量

整体及流程

目标分析

业务目标

想要实现什么样的目标和成果？实现这个目标的真正动机是什么？

用户目标

针对什么用户在什么场景下解决用户的什么问题？达到什么目的？

产品目标

用一句精简的话概述

设计目标

根据以上三个目标提炼关键词进行分析

整体分析

架构是否容易理解

是否提供了用户熟悉的结构和布局

信息层级是否清晰

页面之间的关系是否清楚

信息分类是否合理

信息组织的合理性

主题是否清晰

能迅速找到用户所在节点

目的是否明确

能迅速清楚用户可以做什么

是否具有扩展性

后续框架与扩展如何考虑

是否突出了重点

用户关注的重点功能是否突出展示

用户角色（权限）

是否清楚产品一共有几种类型的用户

每一种用户是否可以清晰的知道自己的任务

各个不同的角色之间能否转变

在体验和呈现内容上是否需要做区分

账号体系

登录方式

如何注册

账号是否需要同步

流程

从A到B路径是否一致

逆向流程是否考虑完整

有没有闭口短路的现象

能否实现闭环

任务流程中断后的提醒，再次恢复后的提醒

输入/输出是否符合预期

跳转名称与之前是否一致

操作容错

视觉动线是否合理

内容状态显示

数据获取

从哪里获取数据

系统抓取

用户上传

如何获取

自动更新

手动加载

获取时间长短

是否始终允许

是否需要授权

缓存

临时缓存

可以删除性缓存

永久性缓存

首次使用时的加载情况

非首次使用时的缓存情况

状态

初始

为空

常规

中间状态

内容过期

显示

边界值

最大值

最小值

各种极限情况

非最优展示

有无重复或短缺

内容异常

敏感词、内容违规

无法获取数据

加载时间过长

错误提示

反馈和通知

通知

通知方式

是否支持多种通知方式

邮件

短信

站内信

消息推送

调用系统通知

调用第三方通知

推送策略

推送时间、表现形式、失效形式

用户退订

是否支持退订

界面的反馈提示

用户操作后的提示

操作成功、操作失败的提示分别是什么，接下来要做什么

弱提示还是强提示

异常中断的提示

接下来要做什么

需要特别在当前流程中断的提示

是否有必要中断当前操作

公告类、引导类的提升

用户操作后才会消失

错误纠正

纠正方式

是否需要声音提示

反馈出现的位置

是否显眼、干扰少，各界面的提示是否一致

用户主动反馈

如何主动进行意见反馈

是否有反馈入口

反馈方式

客服反馈

在线反馈

特殊场景

设备

分辨率

各种分辨率下如何显示，最大、最小考虑极限情况

不同设备，不同版本

是否需要调用硬件进行交互

蓝牙、定位、相机、话筒等是否需要授权

是否需要和其他硬件联动

打印等

异常操作

恶意使用

比如反复点击多次

中断情况

硬件情况

软件情况

网络波动等问题

用户主动取消

任务流程中用户能否主动中断

网络状态

有网络

没网络

网络信号不佳

网络链接超时提醒

刷新

点击刷新

自动刷新

加载数量

容错和防错

危险操作的二次确认

是否可以撤销

保存操作

中断后是否自动保存

特殊状态（移动端）

无图模式

夜间模式

低电模式

沉浸模式

文本及控件

图文

所有的图文模式是否一致

为空时如何显示

设置默认显示内容

内容不存在

控件

控件使用是否一致

整个产品的控件或组件保持一致（提示、弹窗、对话框等）

控件操作表意是否清晰

是否符合控件的使用标准、图标以及颜色

控件是否有默认选项

控件点开后的操作

文本

用语是否一致

语言表述统一，提示用语、称谓、菜单与命令用语、标点格式、产品功能名称的一致性

文字表达简洁、准确、通俗、易懂

把关键信息放在前面，去掉专业术语

实用性

是否符合操作场景，可明确引导下一步操作

文案是否有温度

是否以用户的角度出发，文案风格是否恰当

常见类型

填写申请

申请人填写中是否允许和其他用户的字段重复

申请人填写申请中的错误提示

提交申请后

后续流程

申请后通过什么方式提醒用户

邮件、短信、站内信等

是否有多种登录方式

密码错误是否有次数显示

超过限制如何提醒

忘记密码有什么方式取回

登录前

登录中（正常）

登录中（异常）

发生异常如何提醒

登录后

刷新页面还是记录登录前浏览的位置

列表

每一页的默认显示数量是多少

若分页，每页显示多少条

每一行的默认显示字段是多少

若字数太多，如何显示

列表默认显示顺序

图片为空的显示

内容过期的显示

内容不存在的显示

翻页（加载）操作方式

列表是否有多种排列方式

大图、小图、按时间、按类型

列表的操作

筛选、搜索等

静止状态（默认状态）

输入

编辑状态和常态的区别

编辑完成后的保存成功

编辑完成后的保存失败

编辑过程中是否能取消

编辑后是否提供预览

输入有逻辑关系的内容

排列组合的方式检查

输入被意外退出或中断后是否保存之前的操作

输入错误，边界值

按钮

正常状态

选中状态

不可点击状态

输入框（文本框）

是否有默认值

输入时状态

在输入过程中是否提供提示和判断

输入有错误时的状态

输入文本长度是否有限制

字符标准是什么

输入正确时的状态

无法输入时

加载状态

加载/上传/下载中（正常）

网络错误、操作错误

加载/上传/下载（异常）

如何提醒

加载/上传/下载后

加载/上传/下载成功

加载/上传/下载失败

加载过程中是否允许取消

单页面加载

一次性加载全部内容，一般在页面内容较少，信息文件较小的情况下一次加载完所有数据再显示

异步加载

单页面多模块加载

预加载

跨页面加载

功能需求

向相关人员传达产品需求

设计、开发、测试的依据

方便项目组新成员快速了解项目

将变更内容落实在书面上，方便追溯

文档管理

版本说明

当前版本

版本号

作者

撰写人姓名

日期

撰写日期

年/月/日

版本修订记录

修订历史版本号

修订日期

修订内容

新建【XX】功能

修改【XX】功能

增加【XX】功能

删除【XX】功能

修改原因

简要描述改动原因

举例

业务需求

产品优化

安全问题

体验流程优化

修订人

修订人员姓名

审核人

审核修订内容人员姓名

初稿

修订中

正式发布

名词解释

文档中出现的名词含义

产品概况

产品介绍

阐述需求背景、介绍产品定位、设计目的、预期效果等

目标用户群

使用产品的用户

阅读文档的用户

产品描述

产品整体框架

参照上述功能结构梳理内容

产品主要功能的使用流程

参照上述流程梳理的内容

功能说明

功能模块标题

描述

原型图

用户场景描述

功能描述

输入/前置条件

输出/后置条件

非功能需求

类型

安全需求

如何防止恶意入侵、恶意刷单等

性能需求

如大致响应时间需求、最大并发数要求等

技术性需求

如是否存Cookie、是否使用https等

兼容性需求

如系统版本、浏览器等的兼容性

需求描述

对应需求类型描述需求内容

上线、下线需求

验收标准

验收部门

验收人姓名

验收测试

用户验收测试

性能测试

文档测试

安全测试

压力测试

上线需求

测试报告覆盖范围

测试环境

产品测试合格标准

缺陷修复率标准

覆盖率标准

下线需求

涉及范围

黑客入侵

出现交易、信息等敏感性数据的漏洞

牵扯侵权纠纷

用户差评率

附录

功能结构图/信息结构图

业务流程图/功能流程图

开发人员配置名单

项目排期表

产品原型、交互设计

PRD（产品需求文档）

上线培训

产品上线

产品说明文档

上线步骤

测试完成、bug已修复，核对完成上线需求

PRD、交互原型、设计稿的完整性

检查产品上线所需环境是否搭建完善

功能特性确定的输入、处理、输出

页面跳转的明确地址

检查产品文案

已有功能、标识的改动在其他模块的呈现、完整覆盖

按用户身份区分需求特性

文档中标注未实现的需求及旧功能的删减

异常条件下的兼容措施

与需求方确认正式发布日期

制定产品发布计划

考虑发布策略，文档中体现灰度发布

与技术人员对接最终发布版本

提交产品说明文档

邮件告知相关方正式发布信息

产品培训

产品白皮书、产品培训PPT、产品培训视频

将产品设计目的、使用流程、功能点描述整理归纳，令操作人员、推广运营人员在最短时间内快速了解并使用产品。

培训步骤

培训前

自我测试

熟练掌握产品的操作流程及功能点，进行模拟培训

配置好培训时所需测试数据

准备产品白皮书/产品培训PPT/培训视频

培训对象

确认参与培训的人员

若功能模块为不同操作人员操作，且互相没有操作重复项，建议分批次培训

培训时间

与各部门人员确认培训时间及培训批次

邮件告知相关方

培训中

培训签到

确认已接受培训的人员，避免遗漏

若培训对象为少数固定人员，此步骤可省略

培训背景

介绍本次上线的功能及产品背景，以及培训的内容

培训操作

模拟操作对象的实际操作场景，不要按照功能模块去讲解

实际操作

跟踪培训对象后续的实际操作流程

令操作对象趁热加深记忆

确认培训效果

查看真实用户是如何使用产品的，帮助后续产品设计及优化

培训后

邮件告知

以邮件形式告知相关业务口并附带产品白皮书/产品培训PPT/培训视频

建群讨论

创建钉钉讨论群，将所有参与培训的对象加入讨论群

方便培训对象咨询和讨论

便于后期的需求收集

优化迭代

用户满意度

加强与用户的沟通，了解产品及服务是否满足用户的需要，以解决用户遇到的问题，并以此作为导向，持续改进产品及服务。

调查方式

问卷调查

调查内容

目前评价的系统名称

调查对象基础信息

部门

岗位

姓名

在该系统内的角色

调查日期

该系统使用至今对您自身或本部门的工作是否有帮助？

有非常显著的帮助

有一定的帮助

没有明显的帮助

一点变化都没有

您是否经常浏览查询所填系统中与业务相关的信息？

经常浏览

有时浏览

偶尔看看

基本不看

您认为该系统的操作性如何？

非常好。界面美观，操作非常便利

很好。界面美观，操作比较便利

一般。界面一般，操作一般

较差。界面较差，操作不方便

您认为该系统的稳定性如何？

非常稳定。从来没有死机或异常退出情况，容错性强

很稳定。很少出现死机或异常退出情况

一般。偶尔有死机、登录不上或异常退出等情况，但不影响使用

较差。经常死机、异常退出。容错性较差

您认为该系统设计的操作流程是否合理？

非常合理。优化和规范了本部门的操作流程

很合理。对本部门的工作有促进和改善作用

一般。有些地方有改善，有些地方反而更加繁琐

不太合理。改善的地方乏善可陈，增加的工作量无效且繁琐

当系统出现问题时，您是否能找到解决问题的人并及时处理？

能。技术人员可以迅速响应并解决问题

能。但可能技术人员还在处理其他事情，不能及时响应并解决问题

不太清楚找谁。但是找到了技术人员可以响应并解决问题

不知道找谁。而且找到了技术人员也不能解决问题

如果不使用该系统，会给您的工作带来怎样的影响？

无法正常工作，业务搁置

部分工作无法进行，影响工作

有一定的影响，一段时间内会不太习惯

没有明显影响，其他方式也可以解决问题

完全没有影响，正常工作

总体而言，您认为该系统是否能满足日常需求？

完全满足。基本上不需要改进了

满足。大多数功能符合本部门要求，需要改进的地方不太多

基本满足。功能基本符合本部门需求，但在某些方面需要改进

不太满意。功能基本上不符合本部门的需求

您对该系统的整体评价如何？

非常好（91-100分）

很好（81-90分）

一般（71-80分）

较差（70分以下）

您认为系统评价一般/较差的原因是什么？

技术问题。功能不实用，系统本身存在太多bug，经常出错导致不信任整个系统

使用问题。使用人员操作不当或不按要求操作，系统信息质量不高

人员问题。对系统开发和技术支持人员本身的素质和水平有怀疑，导致对系统的不信任

服务问题。出现问题不能及时响应和解决，日积月累导致系统的实用性降低

在工作当中，曾发生过哪些问题导致影响您的工作效率？

您希望该系统在哪些方面进行改进或增加新的功能来满足工作需要？

开放性回答

用户体验

背景

背景介绍

体验产品名称

体验人员&角色

体验时间

体验环境

产品版本

体验设备

所处节点

初步明确体验用户的关注点

关注产品本身体验，注重第一感觉，找出问题所在。

体验内容

效果体验

视觉设计

文字信息传达

控件使用

动画特效

设定场景，任务走查

逻辑是否合理

步骤是否繁琐

操作是否便捷

场景的设定可以根据目的需求的不同发生变化

产品分析

产品外部体验，用户给出改进建议，产品经理寻找新的功能点。

信息架构

展示是否全面

内容是否合理

功能对比

对比核心功能点

差异化分析

与竞品不同之处

竞争优势

与竞品相比，该产品的竞争优势

总结及建议

总结产品在当前环境下真实的用户体验效果，详细记录产品在实际应用过程产生的效果及用户提出的改进建议。

制定迭代计划

产品复盘

复盘方法

回顾目标

制定目标的重要意义

叙述过程

列出完成目标的思考逻辑和步骤

行动的步骤

遇到的问题点

有意义的部分

评估结果

结果与目标的比较

高于结果

低于结果

符合结果

分析原因

QBQ

问题背后的问题

底层逻辑问题

方法问题

时机问题

目标高估问题

推演规律

产品的一大价值在于对未来的可控性

可控

不可控

半可控