人人都是产品经理2.0 思维导图模板_ProcessOn思维导图、流程图

概念

五个要素

核心用户

刚性需求

真实

需求强烈,不满足不行

高频

典型场景

唤醒点

产品概念

解决方案

竞争优势

竞争标的

你要和谁做对比

三个层次

同类产品

同需求不同类产品

所有产品

争取时间的产品

国民人均时间被不同App切割

你要分割谁的时间

人无我有

人有我优

筛选(顺势而为)

内部因素

能力

人,团队和项目的匹配

资金是否到位

资料

行业资源

经验

行业的各方各面

业务能力

反复做某件事形成的套路

意愿

使命,愿景,价值观

方向感

目标感

外部

价值

宏观:天花板

潜在用户*单个用户可挖掘的价值

微观;身边人(种子用户)

减少自以为是的错误产品

简化项目启动流程

成本

宏观:大环境(PESTEL)

政治

经济

社会

社会成员的历史,价值传统,风俗,教育水平

技术

环境

法律

微观:行业环境(波特五力模型 )

替代品

同行竞争者

买方

卖方

潜在进入者

需求:采集和用户研究

需求采集

需求采集的原则

10/100/1000

每个月10个用户调查,100篇用户相关文章,处理1000个用户反馈

要点:保证用户和产品经理的接触强度

区分维度

获取性质

直接采集

真实,准确

间接采集

已整理,结论获取效率高

立场利益是什么?提问和需求者又分别是谁?是否有曲解?

最好的采集办法

全员参与采集

产品经理处理

性质定义

区分原因

群体和个体具有特殊性和共性

所做和所说不一定会一致,人前人后都要更关注,避免伪需求

四个象限及对应的方法

"以某个产品为例子"流程

产品规划阶段

听用户"定性地说",确定产品方向(做什么),随机抽样四十个用户做访谈,写出需求列表

项目早期

听用户"定量地说",确定需求优先级(先做什么),投放20万份调查问卷,但最终决定优先级权仍在产品经理手上

项目实施中

看用户"定性地做",确定实现的几个需求是怎么做,设计的同事完成可用性测试,陆续找来10个用户来验证

上线后优化

看用户"定量地做",根据产品的用户使用情况做用户分析,进行迭代

要点

螺旋上升,保证四个象限依次实现,完成良性闭环循环

是否和产品交互

两种需求

电视机需求

用户以为需要,有了却不使用的产品功能

洗碗机需求

用户以为不需要,使用后离不开的产品功能

用户没有这项需求的认知,考虑让用户体验,感受这个产品的优势来培养需求

多考虑在优化现有方案的需求采集

低成本验证

不准备复杂系统,简化实现

人肉跑流程来验证

场景真实性

临场感决定使用细节和体验

战略需要的"内部需求"

时刻记住优先满足外部用户的需求

满足外部用户的价值需求来实现商业价值是最终目的

其他的"实用"办法

批斗大会

邀请用户来公司当面批评产品

骂不起来,找"托"来热场

利用网络

搜索关键字

论坛

让产品去做客服,见客户

用户与需求

需求的三种深度

第一种:观点和行动

第二种:目标和动机

第三种:人性和价值观

依据

马斯洛的需求层次理论

超我

自我实现

认知和审美

自我

尊重

社交

本我

安全

生理

负面人性:七宗罪

暴食

食物的诱惑

贪婪

补贴,打折

懒惰

上门服务

嫉妒

排行榜

淫欲

情色欲望需求

愤怒

论坛活跃喷子

骄傲

成就,标识

其他人性

好奇

同情

从众

关于用户

三个阶段

第一个阶段:抽象群体

设想用户是某一类人,目标用户,核心用户

第二个阶段:用户是具体个体

需求采集后,接触真实用户,寻找用户故事

第三个阶段:用户又是抽象群体

真实用户的需求整合出"人物角色"

工具

用户故事

具体的真实场景

人物角色(用户画像)

一个典型用户的生平表

区分维度

细分原则:需求场景要差异大

使用产品的熟练程度

专家

多为2B产品

稳定高效,性能高

有时候也考虑"向下兼容"

新手

简单易用,快速上手

多为2C产品

多边的产品

淘宝

买方

卖方

第三方服务商

知乎

提问者

回答者

围观者

滴滴出行

司机

乘客

平台运营方

人口统计信息(不明显)

年龄

性别

职业

...

业务场景

行业角色

运营

技术

产品

管理

航旅

普通用户

铂金用户

出游

亲子

单人

情侣

团建

产品的原则和初心

整个团队必须达成的共识的准则

伟大源于"初心"

功能:细节和打包

功能的细化

价值判断

广度

潜在用户数量 * 单用户的价值

频度

需求频次 * 单次复杂程度

强度

不可替代性

紧急

持久

用户的有效使用周期

不同时期不同侧重点

产品验证早期,看重强度

看新老用户的留存

优先留住老用户

常见版本号

0.8 / 0.9 / 1.0

产品拉新阶段,看重广度

常见版本号

1.1 / 1.2

产品增长瓶颈期,看重频度

成本评估, 性价比

成本

研发

非研发

确认性价比

价值 / 成本

功能分类:KANO模型

必备属性基础功能

must have

无法消除满意,只能消除不满

魅力属性亮点功能

Excited to have

忠诚度和口碑的基础

超前的洞察,预见需求

期待属性期待功能

Nice To Have

已知你有,希望你继续升级

无差异属性无差别功能

低成本验证

小方案

验证用户需求,验证市场

反向属性反向功能

用户属性的干扰

用户多边形

立场决定判断

用户的多样性

有人喜欢

有人讨厌

打包,确定MVP

尽可能地放弃

要点: 少做就是多做

不要集中完成,而是迭代实现

限制因素

不同功能不同策略

基础功能必做,留足资源

初创期,实现各别低成本的亮点

期待功能,先做高性价比

无差别功能,无需做,等低成本验证

反向功能 , 权衡各方利益

功能和其他部门的调度关系

考虑功能的相似性

考虑非功能需求

MVP的表达, 产品架构图

图表

整个流程的表

前后台

功能和需求管理起来

空间维度

功能列表

罗列所有的模块,描述,价值,优先级,成本,备注,性价比等的表单

时间维度

需求流程

执行的流程图

概念变成图纸

产品设计文档(沟通完成再动笔写)

网站结构图(思维导图)

整个网站的结构,确定了网站的模块划分和网页个数

面向对象思想/用户任务闭环(一系列帮助用户完成任务的环节)

MECE原则(Mutually Exclusive Collectively Exhaustive,相互独立,完全穷尽”)

网页蓝图

产品 + UI共同设计

UI先行,产品也有一定自主权

网页描述图

描述网页的元素和背后逻辑,不包含页面布局

产品设计文档的流程

产品部门 设计 产品设计文档

交给 研发团队 确认 可执行性,研发成本和评价意见

交给 高层领导 确认 项目周期,批人批钱

交给 研发团队 指导 具体的研发

交给 测试团队 制定 测试计划

研发团队的对文档的要求(产品文档最重要的用户)

保持简短的肯定句式,消灭模糊

保持最新

消灭错误(多检查,并不存在毫无错误的文档)

不要对研发人员的工作指手画脚

有编码,容易归纳任务列表

使用恰当的表达方式(表格等),不拘泥于文字

执行:立项组队和研发生产

评审

原型验证

不要努力做错事

做原型或demo

NPS (net promoter score) 纯推荐值

用户回想其他人推荐产品的的可能性

产品早期验证时候验证用户价值

(推荐的人数-批评人数)/样本总量 *100%

评分标准(0-10分)

9-10分 :推荐者

7-8分 : 被动者

0-6分;批评者

理想分数是50%,及以上

100人中推荐者至少75人

产品委员

拥有资源的leader 组成,在四个节点时候,做出判断

四个关键点

概念筛选

立项组队

上线发布

营销推广

立项

人

物

MRD

描述问题

利用故事

意愿,外部价值,成本

ROI 投资回报率

解释为什么要做这个产品

解决方案

阅读对象: 资源拥有方/投资方/老板

PRD

怎么做

阅读对象: 开发,设计,测试

获取资金

你的产品能做多大?

你是否对产品全身心投入?

BRD,PRD,MRD文档是否形成

对于领导

PPT宣讲演示

对于风投

商业计划书

如果不够,把产品执行出来

组队

成员目标

成员沟通

大小公司

第三方的力量

研发过程

产品进经理要不要懂技术

和技术人员无障碍沟通

多想技术伙伴请教技术知识和黑话

根据产品 ,决定懂什么技术

特别关注技术方案和业务场景的关联

测试是专业的

设计和运维

不要这样做

Secret Box

Copy&Paste

直接复制,使用

Hardcode

写死代码,不考虑配置文件和变量

Less Testing

减少测试

Skip Error Handling

不考虑异常的情况

Descope

偷摸减少需求

Less Review

减少设计评审

No Autotest

不采取测试自动化

Never Do This

实施前

表达含糊,说不清需求价值

不考虑功能细节

帮技术评估工作量

倒逼技术团队做出承诺

实施中

做了一半,改需求

开发过程中失联

过度关注细节

实施后

不反馈

任务没有节奏感

其他

犹豫不决

报喜不报忧,隐瞒

只看任务,不关注人

成长:规划和迭代

规划

规划:只看最短和最长

短的规划:1-3个月,最多6个月

长的规划:3-5,10年

规划

业务规划

MRD

Why

How

What

一句话说明业务定位

一个业务模式

模型之间的关系

产业链的各个角色的配合

盈利点

可以图表展示

3/5个业务关键点

产品规划

产品要做什么

从规划向上看战略

问答,找出产品的不足和激发方向

苏格拉底法

知识从怀疑产生

谈话为方式,辩论为技术寻找真理

提升规划能力的实践

举办宣讲会

大家一起点评

迭代

再理解敏捷

目的导向,结果导向

价值观

沟通

简单

反馈

勇气

谦逊

宣言

人与人的交互,重于过程和工具

可用的软件,重于详细的文档

与客户协作,重于合同谈判

随时应对变化,重于循规蹈矩

原则

最优先要做的是尽早、持续地交付有价值的软件，让客户满意

欣然面对需求变化，即使在开发后期。敏捷过程利用变化为客户维持竞争的优势。

频繁地交付可工作的软件，从数周到数月，交付周期越短越好。

在团队内外，面对面交谈是最有效，也是最高效的沟通方式。

在整个项目过程中，业务人员必须和开发人员每天都在一起工作。

以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好。

可工作的软件是衡量进度的首要标准。

敏捷过程倡导可持续开发。

坚持不懈的追求技术卓越和良好的设计，以此增强敏捷的能力。

简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。

最好的架构、需求和设计来自自组织的团队。

团队定期反思如何提升效率，并依此调整自己的行为。

敏捷的团队实践

快

低成本验证

使用简单的模版,实施功能流程,查看用户反馈

公关手段

借助媒体,提前放出信息(烟雾弹).查看用户的反映

辟谣

证实

同用户一起成长

持续更新

产品的三大关

印象关

体验关

无聊关

持续地更新关系产品用户的忠诚度

管理用户期待

提前减低用户的预期

不过高吹捧用户的预期

更新本身

功能更新

硬指标

和业界的先进水平的差距

差异化

用户的可接受体验的差距

内容更新

热点事件的应激反应

满足现有用户对热点的关注

利用热点吸纳用户

优先级

思想:机会成本

选择了A,就放弃了B

依据

成本

研发

非研发

收益

厮守底线

灰度测试

障眼法

炮火中前进

最小可行性产品( Minimum viable product)

更新的频率

客户端月更

时间盒

检查和处理

为什么要检查

PDAC框架

制定年度商业计划

确定发展目标和达到发展目标所需的关键任务

按照计划执行

检查执行情况

给予及时的处理意见

注意事项

确认执行结果和计划是否相符

任务颗粒度是否足够细

确定执行结果和应用环境是否相符

检查的方法

频繁使用自己的产品

自我思考

对产品层面的检查

用户对产品的核心概念是否了解,是否接受

图纸是否覆盖核心概念?核心概念之外是否设计太多的东西?

用户对图纸(虚拟功能?虚拟体验)怎么看?

项目结果对图纸是否相符?是否进行全面的测试

用户对项目阶段性结果(功能,体验)怎么看?

是否形成用户任务闭环?

是否存在流失率超高的任务节点

亲自使用

用户参与 CE(customer engagement)

提供明显的反馈入口

订阅产品关键字的搜索结果,了解其他渠道的反馈

建立或加入核心用户群

追踪单个用户的使用行为

对流失用户进行回访

预防问题

测试驱动开发 TDD (Test-Driven Development )

敏捷开发思想,自动化

在功能性代码完成之前完成测试代码

预防测试债务

思想

防止面包落地,如果非要落地,让面包落在盘子上

产品经历的七层修炼

0:职场新手上路

学习能力、执行力、沟通能力、逻辑思维、时间管理、团队精神、会议管理、办公软件使用

1:需求细化和研发跟进

文档与原型、领域知识、懂技术、懂设计、项目跟进

做客服

做TC

请吃饭

2.主动挖掘与项目管理

用户研究、项目管理、心理学、社会学、数据分析、竞品分析、协调资源、优化流程

3:完整产品与大局观

做取舍、需求管理、产品规划、懂市场、懂运营、商业感觉、行业分析

产品线与带团队

前瞻性、产品分解、产品生命周期管理、培养新人、团队管理、订目标、追过程、拿结果

5:成功案例与影响力

创新、输出方法论、知识传承、心态修炼、成就他人

商业闭环与全职能管理

开宗立派、领导力、企业文化传承、战略制定、组织发展

7:自己成功到助人成功

理想与信念、情怀、引领时代