1. Blogs of Wangbaoqiang首页
  2. 读书

《神一样的产品经理》读书笔记

  1. 产品经理诞生的背景和价值
    1.1 产品经理诞生的背景
    1.中国互联网的发展:

a) 第一阶段(1987——1998),探索和基础设施建设阶段

b) 第二阶段(1999——2005),web1.0阶段,即互联网普及阶段

c) 第三阶段(2006——2011),web2.0阶段,即互联网快速增长和多元化整合发展阶段

2.移动互联网的发展:

a) 第一阶段(2000——2002),中国移动互联网的初级阶段,文字信息、图案和铃声

b) 第二阶段(2003——2005),WAP时期,以内容为主

c) 第三阶段(2006——2008),互动娱乐时期,有功能性应用

d) 第四阶段(2009——2011),SoLoMoCo,各种应用在手机上广泛应用

1.2 产品经理的价值
1.产品是企业价值的载体,企业通过产品交换来实现商业价值,企业是否成功,很大程度上取决于产品是否优秀甚至卓越

2.产品经理是公司价值链中最重要的一个环节,是直接面向客户、带领团队创造价值的领军人物,一个成功的产品经理不但能引导产品的发生,而且能引导公司的发展

  1. 产品经理的新视角
    2.1 产品经理定义
    1.产品经理是驱动和影响设计、技术、测试、运营和市场等人员推进产品生命周期的经理人

2.在产品生命周期的不同阶段,驱动者是动态变化的:在研发期,产品是驱动者,产品上线之后,运营或业务部门是驱动者

3.产品经理分类:

2.2 产品经理是代孕妈妈

2.3 最牛的产品经理
主要体现在影响力、核心需求把控力、创新力和痴情力

2.4 产品经理的职责
1.明确产品的目标用户群及其特征

2.获取、评估和管理用户需求

3.完成产品需求文档、产品原型和流程图

4.精通用户体验、交互设计和信息架构技能

5.项目管理、需求变更管理和需求验收

6.产品运营数据的分析和总结

7.提供运营、市场和销售等支持

2.5 产品经理的能力
1.产品经理能力

2.6 产品经理常犯的错误
1.自我感觉良好

2.知其然,不知其所以然

3.老板的话是圣旨

4.需求变更频繁

5.不善于沟通

6.不重视需求文档和原型

7.为了做产品而做产品

8.项目管理混乱

9.不做计划和总结

2.7 产品经理与项目经理的区别
1.产品经理重在策划,做正确的事。其所策划的产品是否符合用户和市场的需求,是否解决了目标用户的需求,评估哪些需求是否该做,科学定义需求优先级,产品上市是否能给公司带来商业价值,是否实现公司商业目标

2.项目经理重在执行,正确的做事。执行到位,在时间、成本和资源的约束条件下完成既定的目标

  1. 产品经理的进阶之道
    3.1 产品经理十问
    1.职业规划是神马?专业还是管理?

2.最缺的产品技能是什么,如何弥补?

3.心目中的产品团队应该是怎样的?

4.做产品时最大的困惑或问题是什么?

5.有做阶段性计划和总结的习惯吗?

6.一个月看几本书?都看哪方面的书?

7.曾经在同事面前做过技能或知识的分享吗?

8.经常参加一些线上或线下产品经理活动吗?

9.有研究产品并撰写调研文章的习惯吗?

10.有产品经理的气场、影响力和说服力吗?

3.2 产品经理道与术
宁愿选择一流的实施三流的想法,而不选择一流的想法三流的实施

3.3 推荐书籍
1.人人都是产品经理

2.结网

3.就这么做产品

4.赢在用户

5.用户体验的要素

6.Don’t make me think

7.Designing web interfaces

8.交互设计精髓3.0

9.玩赚你的网站

10.触动人心:设计优秀的iPhone应用

11.谁说菜鸟不会数据分析

12.数据挖掘

13.产品经理手册

14.产品经理的第二本书

  1. 产品定义、类型、气质和战略战术
    4.1 产品定义和价值
    1.产品是能够提供给市场、供用户使用或消费的、可满足某种欲望和需要的任何东西,产品是满足用户需要的复杂利益的集合。

2.产品的五个要素:

a) 产品的内涵:为用户提供的基本效用或利益,满足用户的本质需求——核心价值

b) 产品的形式:指实现产品的内涵所采取的方式,包括功能、内容、设计等——期望价值

c) 产品的外延:指用户在使用或购买产品时所得到的附加服务或利益——附加价值

d) 产品的理念:产品的信念和宗旨——期望价值

e) 产品的终端:web、桌面客户端、收集、平板电脑等——期望价值

3.用户买的不是你做的产品,用户买的是你做产品的信念和宗旨。

4.营销学之父菲利普科特勒说:星巴克卖的不是咖啡,是休闲,是一种氛围;法拉利卖的不是跑车,是一种近似疯狂的驾驶快感和高贵;劳力士卖的不是表,是奢侈的感觉和自信;希尔顿卖的不是酒店,是舒适与安心;麦肯锡卖的不是数据,是权威与专业。

5.微创新:

a) 产品设计,从小处着眼,贴近用户需求心理

b) 产品功能,一定要专注,不求大而全

c) 产品更新,小步快跑,不断试错

4.2 成功产品定义
能引导和创造用户需求、创造或改变目标用户生活方式、拥有良好用户体验、为企业带来赢利、创造商业价值的产品

4.3 产品类型
1.主要产品类型:

a) 工具型

b) 媒体型

c) 社区型

d) 游戏型

e) 平台型

2.在产品市场格局中占有一席之地的公司产品类型是一个动态发展的过程,单一形态的产品类型大都往多个形态的产品类型过渡和发展

a) 工具+媒体

b) 社区+平台

c) 工具+平台

d) 媒体+工具+社区+平台

e) 平台+社区

f) 游戏+社区

g) 工具+社区+游戏+媒体+平台

4.4 产品气质
产品的气质来源于天赋、内功和外功的完美结合

4.5产品战略和战术
1.战略就是计谋、谋略、计划、打算等;战术是按照战略计划的具体实施过程,即技术、技能、技巧

2.战略分析

a) 行业分析

i. 确定行业规模(生存空间)

ii. 竞争者结构分析(并购)

iii. 与上游谈判价格的能力(扩大规模)

iv. 与下游谈判价格的能力(行业强)

v. 进入者分析(竞争壁垒)

vi. 替代品威胁

b) 产品选择

c) 行业定位

d) 核心竞争力

3.预测行业发展趋势:

a) 根据行业历史

b) 逆向思维法

c) PEST分析法

4.产品战略指的是产品的研发、运营、市场、销售等全局性规划和策略

a) 观念,即愿景

b) 定位,做什么产品,核心价值

i. 产品方向

ii. 产品类型

iii. 产品价值

c) 竞争,差异化、关键竞争要素,成本优势

d) 模式,商业模式、赢利模式

e) 规划,指产品研发、上市、运营推广的路线图

i. 波士顿BCG矩阵评估与分析:放弃瘦狗、捉住金牛、维持明星、投资问题

ii. 麦肯锡三层面法:吃着碗里的,看着锅里的,瞄着田里的

  1. 企业大部分利润来源的核心业务
  2. 有增长潜能的正在崛起的业务
  3. 未来长远发展选择的业务

5.阿里巴巴——商人的网站,小企业做生意的地方;iPhone——移动浏览器及“杀手级”的触摸屏界面;Facebook——真正使用的社交网络;Pandora——超级简单的个性化电台;twitter——所有人不到一分钟就能写微博;flipboard——social magazine;zite——personalized magazine;知乎——一个真实的网络回答社区,帮助你寻找答案,分享知识;点点——收集、整理、分享你的兴趣爱好

6.产品线(Product Line)指一群密切相关的产品,这些产品功能相近,用户群与渠道类同

7.产品事件中,关于产品组合管理的资源投入,按7:2:1的投入比例进行

  1. 商业需求文档
    5.1 项目背景
    1.商业需求文档主要包括:

a) 项目背景,阐述为什么做

b) 项目时机,为什么是现在做

c) 项目规划,阐述怎么做

d) 项目的收益、成本、风险及对策,阐述项目预期的收益,需要花费哪些成本,项目面对的各种风险及可能的应对之策

2.产品提案:

a) 既有产品提案:指的是已经上线运营一段时间后的产品,出具数据运营报告,分析当前产品存在的突出问题,亟需解决

b) 创先产品提案:全新的产品或者是在既有的产品的基础上衍生出来的新产品,出具相关的调研报告

i. 用户调研

  1. 目标用户
  2. 用户细分(麦肯锡八法细分用户)
  3. 用户特点(人口统计信息、性格、爱好、需求特征等)
  4. 用户行为(频率、习惯、消费等)
  5. 用户核心需求
  6. 用户场景(用户如何使用,在什么地方、什么时间使用)

ii. 市场调研

  1. 国内外这个产品领域的市场现状
  2. 市场规模、行业发展趋势
  3. 行业调研报告

iii. 竞争对手

  1. 标杆竞争对手、竞争对手产品占有的市场份额
  2. 竞争对手的主要优势
  3. 产品差异化策略

3.麦肯锡八法细分用户:

4.提案目标:

a) 吸引、留住用户,提高KPI

b) 系统或技术、产品架构调整

c) 拓展新业务市场、占领细分市场份额

d) 运营、市场、销售支撑等

5.商业价值:

a) 增加收入,提高市场占有率,创造营收

b) 提高用户基数和粘度

c) 市场造势,提升品牌价值

d) 产品差异化,抑制并击败竞争对手

5.2 项目时机
合适的时间,合适的人做合适的事

5.3 项目规划
1.核心功能点:用一句话概括核心功能点

2.产品架构图:

a) 数据库层

b) 数据服务层

c) 应用层

d) 表现层

e) 用户层

3.阶段规划:每个阶段应该完成哪些主要功能,要达到什么样的目标

4.主要功能规划:产品主要有哪些功能模块,对主要功能进行描述

5.产品路线图

5.4 商业模式
1.商业模式越简单越好

2.商业模式:

a) 广告模式

b) 会员服务

c) 游戏模式

d) 收入分成

e) 增值服务

5.5 收益、成本、风险及对策
1.收益预估:包括收入、用户、品牌、降低成本、投入/产出比等

2.产品定价策略:

a) 新产品定价策略:

i. 高定价:

  1. 优点:短期内取得较大利润,竞争时采取降价,可限制竞争者加入,符合消费者从高到低的心理
  2. 缺点:不利于打开市场
  3. 适合品牌价值和产品质量比较高以及在业界指定了行业规范掌握话语权的企业

ii. 低定价:

  1. 优点:迅速打开产品销路
  2. 缺点:投资回收期太长,且价格变动余地小

iii. 中定价:

  1. 优点:价格稳定,赢利目标可按期实现
  2. 缺点:比较保守,不适合竞争激烈的市场环境

b) 心理定价策略:

i. 尾数定价(零头定价):适用于基本生活用品

ii. 声望定价(整数定价):适用于价格交规的耐用品或礼品,以及消费者不太了解的产品

iii. 招徕定价(特价定价)

iv. 系列定价(分级定价)

v. 吉祥数定价

vi. 习惯定价

c) 折扣定价策略:

i. 数量折扣

  1. 累计数量折扣:鼓励顾客经常向本企业购买,成为可信赖的长期顾客
  2. 一次性数量折扣:鼓励顾客大批量购买,促进产品多销、快销

ii. 现金折扣/提前支付折扣:鼓励顾客尽早付款,加速资金周转,降低销售费用,减少财务风险

  1. 折扣比例
  2. 给予折扣的时间限制
  3. 付清全部货款的期限

iii. 功能折扣/交易折扣

iv. 季节折扣/季节差价

d) 差别定价策略:

i. 用户群体

ii. 产品功能

iii. 季节时间

iv. 地理位置

3.产品定价方法:

a) 成本导向定价法:

i. 成本加成法:单位产品价格=单位产品成本*(1+加成率)

ii. 目标利润法:单位商品价格=总成本*(1+目标利润率)/预计销量

iii. 编辑成本法:单位产品价格=(总的变动成本+边际贡献)/预计销售;边际贡献=预计销售输入-总的变动成本,使用于产品供过于求,卖方竞争激烈的情况

b) 需求差异定价法:

i. 因地点而异

ii. 因时间而异

iii. 因商品而异

iv. 因顾客而异

c) 竞争导向定价法

i. 随行就市法

ii. 差异定价法

4.成本预估:

a) 人力成本预估

b) 非人力成本预估

5.风险:

a) 政策风险

b) 技术风险

c) 法律风险

d) 市场风险

e) 决策风险

f) 资本风险

6.风险对策:

a) 规避:技术风险

b) 转移:决策风险

c) 缓解:市场风险、资本风险

d) 接受:政策风险、法律风险

  1. 市场需求文档
    6.1 用户描述
    1.用户描述:

a) 目标用户群

b) 用户需求痛处

c) 用户特征

d) 用户动机

e) 用户角色建模

2.马斯洛需要层次扩展:

3.用户角色建模:

a) 用户角色定义

b) 用户角色价值

i. 专注用户

  1. 不可能建立一个适合所有人的网站
  2. 不为1%的需求骚扰99%的用户

ii. 引起共鸣

iii. 统一意见

iv. 创造效率

v. 提升决策质量

c) 用户角色创建步骤

i. 发现用户

  1. 问题:目标用户是谁?用户规模有多大?他们的主要行为有哪些?
  2. 方法:定量数据收集
  3. 输出:调研报告
  4. 数据来源:面对面访谈、观察法、二手信息、调查问卷、行业调研报告

ii. 提供背景

  1. 问题:用户之间的差异有哪些?
  2. 方法:查看材料,将用户群标记分组
  3. 输出:目标用户群概述文档

iii. 证实验证

  1. 问题:用户角色信息(喜欢/不喜欢,内在需求,价值观)、环境信息(工作场所、工作条件)、场景信息(工作策略和目标、信息策略和目标)
  2. 方法:定性数据收集
  3. 输出:调研报告

iv. 聚类用户

  1. 问题:是否抓住了主要用户群?还需要考虑其他的用户群吗?这些用户群是否同等重要?
  2. 方法:聚类分类
  3. 输出:用户群分类描述

v. 创建用户角色

  1. 问题:基本信息(姓名、性别、照片)、性格(内向、外向)、背景(职业)、对待技术的情绪与态度、个性特征等
  2. 方法:聚类分类
  3. 输出:用户群分类描述

vi. 定义情境

  1. 问题:用户角色的需求是什么?是在什么样的情境下产生的?
  2. 方法:寻找情境及其产生的需求
  3. 输出:需求和情境的分类

vii. 验证和认可

  1. 问题:你知道其他人喜欢这个用户角色吗?
  2. 方法:知道用户角色的相关人员阅读用户角色信息并就此发表意见和反馈

viii. 统一认识

  1. 问题:我们如何将用户角色信息分享给团队的相关人员?
  2. 方法:组织会议、发送电子邮件、举办活动等

ix. 创建场景

  1. 问题:在设定的情境中,既定的目标下,用户使用技术的时候会发生什么
  2. 方法:叙述式脚本,使用用户角色描述和情境形成场景
  3. 输出:场景、用例、需求规格说明书

x. 更新用户角色信息

  1. 问题:用户角色信息发生变化了吗
  2. 方法:可用性测试、新用户数据
  3. 输出:专人负责更新用户角色信息

4.用户场景指用户在什么时间、什么地点使用或消费产品

6.2 市场描述
1.占比加权法估算:

a) (5~7个主流品牌销售额之和)/权重数=市场总容量约数,权重数基本为几大品牌市场占有率之和

b) 区域越小,数据越准确

c) 适用于成熟产品进入成熟市场

2.核心精算估算:

a) 尽量将容易失真的部分控制在营销策略中无关紧要的部分

b) 操作过程可控制,信度和效果都很好,调查的规模适中

c) 适用于消费时间、场所相对集中的产品

3.替代品类比法估算:

a) 根据产品功能上的代替性,列出最近的4种产品,计算着4种产品的容量,接着分别乘以替代率,然后相加得出平均值

b) 能够比较准确的反映市场状况,并与营销策略关系极大

c) 适用于新类别产品

4.统计调查法估算:

a) 市场需求容量=区域市场总人口数区域人口品均收入区域人口中目标人群的占比*目标人群购买同类别产品的支出比例

b) 潜在市场容量=潜在购买率(城市或农村的调查值)人口数自然变动因素(人口增长等)*人口社会变动因素(人口城市化等)

c) 逻辑性强,精度可控制,对市场整体把握性强,但成本较高,规模较大,操作热暖的专业性要求高

d) 适用于铺市面广、销售点分散、消费时间分散的产品

5.历史数据分析法估算:

a) (N为年份)

b) 精度不高

c) 适用于已经在区域市场比较成熟的产品

6.3 需求描述
1.需求描述即阐述需求点,包括功能需求和非功能需求及其优先级

2.非功能需求:

a) 安全需求

b) 性能需求

c) 兼容性需求

d) 数据统计需求

e) 帮助需求

f) 财务需求

g) 法律需求

h) 运营需求

i) UI需求

6.4 产品规划案例

  1. 需求分析与管理
    7.1 需求定义
    在用户购买力既定的前提下,需求就是用户想要的、能够解决问题或达到目标的欲望集合

7.2 需求本质
需求的本质:名望、权利、利益

7.3 需求分类
1.娱乐休闲

2.归属感

3.沟通

4.意见领袖

5.利益

a) 激活产品的超级影响者:1%规则:只有1%的粉丝会对品牌进行社会化的传播和分享

b) 将最好的内容预留给超级影响者

c) 利用好博客和论坛

d) 区分一般影响者和超级影响者

6.获取知识和资讯

7.自我情感表达

8.爱和被爱

9.社交

10.分享

11.安全

12.尊重

7.4 需求与产品
产品包括两块:功能和内容

7.5 获取需求
1.获取需求的主要方法:

a) 行业调研分析报告、业内专家、资深专业人士

b) 定性的用户访谈

c) 定量与定性结合的调查问卷

d) 运营数据分析

e) 将自己变成目标用户

2.一对一用户深度访谈:

a) 确定访谈目的

b) 选准访谈对象

c) 营造良好的访谈氛围

d) 访谈流程要有策略

e) 验证用户真实需求

f) 记录用户访谈成果

3.焦点小组访谈:

a) 访谈前的准备工作

i. 明确访谈的目的,要解决什么问题,需要验证哪些问题

ii. 访谈对象的甄选,新用户、中度用户、老用户各占相同比例

iii. 确定访谈的时间、地点、人数、奖励措施以及访谈参与人

iv. 细化访谈的问题脚本,整理出我们需要访谈的核心问题列表,形成文档

b) 访谈中执行工作:整个过程尽量避免访谈对象的回答出现比例失衡,记录下访谈回答的核心观点

c) 访谈后整理工作

4.日记分析法

5.调查问卷:

a) 调研流程:

i. 定义问题,明确调研目标

ii. 确定调研设计方案

iii. 设计调查问卷

iv. 确定抽样方案、样本容量

v. 收集数据

vi. 分析数据

vii. 撰写调研报告

viii. 后期跟进

b) 调查问卷设计流程:

i. 阐明调查问卷的目的

ii. 确定数据收集的方式

iii. 确定问卷答案格式

iv. 问题的措辞

v. 问卷的流程与布局

vi. 评估问卷的流程和布局

vii. 测试并修正

viii. 实施

6.需求采集表

7.6 评估需求

1.KANO模型:

a) 基本型需求:

i. 可以消除用户的不满,不能增加用户满意度

b) 期望型需求:

i. 若得到满足或表现良好,增加用户满意度;得不到满足或表现不好,不满也会显著增加

c) 兴奋型需求:

i. 当特性不充足时,并且无关紧要的特性,则用户无所谓;当产品提供了这类需求中的服务时,用户对产品非常满意,提高用户的忠诚度

2.KANO需求归类矩阵

M代表Must-have,基本型需求;L代表Linear,期望型需求;E代表Exciter,兴奋型需求;R代表Reverse,相反的需求;Q代表Questionable,可疑的结果;I代表Indifferent,无关紧要

3.做减法:

a) 根据产品定位

b) 根据产品价值

c) 根据产品场景

d) 根据产品迭代

7.7 需求优先级定义
先做重要且紧急的需求,后做重要不紧急的需求,接着做紧急不重要的需求,最后做不紧急不重要的需求

7.8 管理需求
需求管理表

  1. 产品需求文档
    8.1 产品需求文档内容
    1.MECE是mutually exclusive 和collectively exhaustive,相互独立,完全穷尽

2.版本号格式:主版本号.子版本号[修正版本号[.编译版本号]]

3.项目初版时,版本号为1.0或1.00;当项目在进行了局部修改或BUG修正时,主要版本号和子版本号都不变,修正版本号加1;当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加1,修正版本号复位为0;当项目在进行了重大修改或局部修正累计较多,而导致项目整体发生全局变化时,主版本号加1

4.内容包含:

a) 版本号和修订历史

b) 名词术语定义

c) 功能需求总表

d) 流程图、顺序图、活动图

e) 功能需求详细描述

f) 非功能需求

g) 文档的更新和维护

5.UML(unified modeling language)有用例图(use case diagram)、类图(class diagram)、对象图(object diagram)、顺序图(sequence diagram)、协作图(collaboration diagram)、状态图(state chart diagram)、活动图(activity diagram)、构件图(component diagram)、部署图(deployment diagram)

8.2 产品原型
1.产品原型设计就是将产品的概念细化成为可见的产品具体形态

2.常用工具:纸质、word、excel、ppt、visio、photoshop、uidesigner、axure rp pro、mockup

8.3 页面交互图

8.4 需求文档质量评估标准
1.正确性

2.可行性

3.必要性

4.优先级

5.明确性

6.可证实

7.完整性

8.一致性

  1. 用户体验
    9.1 用户体验的必要性
    用户体验(user experience)关注的是用户怎么使用产品,用户解决问题、完成任务、达到目标之后的满意度如何

9.2 用户体验的层次
用户体验层次从低到高:有用——能用——可用——用的爽——品牌

9.3 用户体验的要素

9.4 用户体验的分类
1.感官体验:

a) 设计风格潮流:清新、简约、简洁、精简,更有人情味与趣味的设计风格已经逐渐成为趋势和潮流

b) 产品LOGO冲击力:

i. 合乎时代潮流

ii. 强烈的视觉形式感和高度艺术性

iii. 易于识别和记忆

iv. 具有高度的概括力

v. 符合行业特征

vi. 具有现代感

vii. 简洁、生动、形象

viii. 具有扩展性,为重大事件节日专门设计

ix. 信赖度很高

x. 给人亲切、和蔼的感觉

c) 产品运行速度快且稳定安全

d) 页面布局合理

e) 页面色彩统一

f) 图片、音乐和视频质量高

2.交互体验:

a) 导航

b) 搜索

c) 任务流

d) 主次

e) 直接

f) 统一

g) 少做

h) 反馈

i) 对称

j) 简洁

3.情感体验:

a) 尊重

b) 惊喜

c) 亲和

d) 满意

e) 共鸣

f) 细致

4.价值体验:

a) 核心价值

b) 期望价值

c) 附加价值

5.信任体验:

a) Footer

b) 隐私保护

c) 权威推荐

d) 成功案例

9.5 用户体验的度量
网站转化率(conversion rate)是指用户进行了相应目标行动的访问次数与总访问次数的比率

9.6如何提高用户体验
1.新手上路提示

2.适当引导用户

3.贯穿生命周期

4.超出用户预期

5.正确对待反馈

6.可用性测试

7.数据分析和挖掘

8.多用和多研究

  1. 用户体验设计
    10.1 概念设计
    概念设计要描述出用户的整体任务有哪些,各个任务节点之间的关系和关联如何

10.2 信息架构
信息架构(information architecture),主体对象是信息;重点关注的是如何将信息传达给用户,使用户在较短时间内找到需要的信息,主要关注信息的结构粒度、组织方式、归类以及展现形式

1.组织系统:如何组织信息

2.标签系统:如何表示信息

3.导航系统:如何浏览信息

a) 全局导航

b) 区域导航

c) 情境导航

d) 辅助性导航

e) 定制化导航

4.搜索系统:如何搜索信息

5.可扩展性

10.3 交互设计
1.场景设计

2.任务分解

3.任务流交互:

a) 基于流程的交互:以用户目标位导向进行设计,注意区分新手、专家、和中度用户对任务流的熟悉程度,根据用户的使用场景,揣摩实现模型和心智模型

b) 基于界面的交互:

i. 主次原则:到底放什么,取决于要重点引导用户操作的功能和通过数据分析得出的功能相结合

ii. 直接原则

iii. 统一原则:保持统一,降低用户的认知难度和操作成本

iv. 少做原则:尽量准确把握用户的心理预期,揣摩用户的心智模型,进而实现用户的心理预期

v. 反馈原则:尽量对每个操作能做到人机交互反馈,让用户清楚自己目前的状态,减少疑惑,有时候还能起到引导用户操作的目的

vi. 对称原则:原始状态-用户操作-用户取消操作-恢复到原始状态,给用户反悔的机会,提高用户操作的容错性

vii. 简洁原则:为用户着想,文案简洁易懂,具有自我解释性和引导性,符合语言表达习惯。帮助用户诊断、识别和恢复错误,告诉用户大概的原因和解决办法,做适时的提醒

10.4 视觉设计
1.避免视觉噪声

2.主次、对比、相似性、分层

3.视觉流:

a) 对角线对称

b) 垂直轴对称

c) 从左到右,从上到下

4.配色和排版:

a) 颜色搭配:主色调+辅助色最好不超过三种,有层次感

b) 颜色引导用户

c) 排版:分割、区块和强调

5.风格一致

  1. 可用性测试
    11.1 可用性测试的必要性

11.2 可用性测试的方法
1.卡片分类法:

a) 用于研究 用户如何理解和组织信息

b) 方法:将信息(概念、条目、内容、小分类)写在一张张卡片上,然后归类

c) 分为开放式卡片分类法(opened card-sorting)和关闭式卡片分类法(closed card-sorting)

2.录屏摄像

3.眼动跟踪

4.A/B可用性测试

5.运营数据

6.可用性测试工具:userfly、clicktale、crazy egg、usabilla、feedback army、five second test、intuitionhq、user reel、navflow、adduse、notebox、user testing、fenggui、silverback、concept feedback、clixpy、user echo、upshot、kissinsights、verify

11.3 可用性测试的流程
1.准备阶段:

a) 明确可用性测试的目的

b) 安排可用性测试的日期和时间

c) 选择可用性测试方法

d) 确定可用性测试对象:

i. 招募什么样的人

ii. 招募人数

iii. 如何招募

iv. 指定测试任务清单

v. 确定相关参与人

vi. 确定供测试用的产品对象

vii. 准备测试设备和地点

viii. 指定可用性测试议程

ix. 预测试

2.实施阶段:

a) 原则:

i. 尽量不要打断用户的操作

ii. 尽量让用户独立完成

iii. 测试环境和场景人物应当尽量符合用户使用产品的真实环境

iv. 充分尊重和鼓励用户,给用户正面反馈

b) 主持人:

i. 说明本次测试的产品、测试的目的、测试的大致步骤以及可能花费的时间

ii. 宣布测试议程,包括欢迎词、开场白

iii. 对于测试相关的解释说明,建议用户边做边说

iv. 请求用户签署保密协议,说明任务,测试对象提问,测试总结

c) 记录员:主要负责记录用户在执行每项任务时做了什么,说了什么,碰到什么问题

d) 观察员:负责用户执行每项任务时填充任务场景、用户操作的步骤等

3.总结阶段:

a) 收集数据进行分析

b) 定义问题优先级

c) 列举问题清单:

i. 问题名称

ii. 问题优先级

iii. 问题描述

iv. 原因分析

v. 解决方案

  1. UED团队
    12.1 团队组建
    1.团队负责人

2.用户研究员

3.视觉设计师

4.交互设计师

5.前端工程师

6.文案工程师

12.2 工作流程

  1. 产品流程
    13.1 策划阶段(Plan)
    1.主要工作与交付物

2.需求达到的预期KPI

3.需求说明会

13.2 执行阶段(Do)
1.设计阶段

2.开发阶段

3.测试阶段

4.上线准备阶段

13.3 检验阶段(Watch)
1.数据检验阶段

2.策划会议阶段

  1. Scrum敏捷开发
    14.1 Scrum敏捷开发介绍
    1.开发宣言:

a) 个体和交互胜过过程和工具

b) 可用的软件胜过完备的文档

c) 客户合作胜过合同谈判

d) 响应变化胜过遵循计划

2.敏捷开发原则:

a) 最先要做的是通过尽早、持续地交付有价值的软件或产品来使用户满意

b) 即使到了开发后期,也欢迎改变需求

c) 经常交付可以工作的软件,交付时间间隔越短越好

d) 在整个项目开发期间,业务人员和开发人员必须天天一起工作

e) 围绕被激励起来的个人构建项目

f) 在团队内部,最具有效果且富有效率的传递信息的方法是面对面的交谈

g) 工作的软件或产品是首要的进度度量标准

h) 敏捷过程提倡平稳的开发节奏,发起人、开发者和用户应能保持一个长期、恒定的开发速度

i) 不断地关注优秀的技能和好的设计会增强敏捷能力

j) 简单化是根本(不做过度设计和预测)

k) 最好的架构、需求和设计出自于自组织的团队

l) 团队会定期对前一个迭代进行反省总结,以便调整自己的行为,提高开发效率

14.2 Scrum敏捷开发流程
1.三个角色:

a) 产品负责人(product owner)

i. 制定产品战略、规划、用户调研、进行需求分析和评估等,评估决定做哪些功能后,出具产品backlog,确定产品的功能

ii. 决定发布的日期和发布内容,给迭代定下目标

iii. 为产品的利润负责,寻求投资回报率最大化

iv. 根据ROI(商业价值/工作量)确定功能优先级,必要时可将风险考虑在内

v. 指定sprint 计划,每个sprint开始前,根据实际情况调整功能和优先级

vi. 验收开发质量,接受或拒绝接受开发团队的工作成果

b) 项目的直接管理者(scrum master)

i. 领导团队实践scrum,协助产品负责人实现项目利益相关人的价值最大化

ii. 确保团队能胜任工作并保持高生产率

iii. 保证各个角色及职责的良好协作

iv. 解决团队开发中的障碍

v. 作为团队与外部的接口人,屏蔽外界对成员的干扰

vi. 保证开发过程按计划进行,组织每日立会、sprint 评审和sprint计划会议

c) 团队(team):5~9人

i. 团队要跨职能(包括开发人员、测试人员、UED等)

ii. 团队成员尽可能保证全职

iii. 尽全力确保达到sprint目标

iv. 高度的自我组织和管理能力

v. 向产品负责人演示产品功能,接收产品负责人对产品功能的验收

vi. 团队稳定,在sprint之间调整成员,团队成员的构成在sprint内不允许变化

2.四个会议:

a) Sprint会议:应考虑到团队的接受力、开发的速度、技术水平和商业条件

i. 制定sprint目标

  1. 分析和评估产品负责人提供的产品backlog
  2. 哪些产品backlog被选中应该放到这个sprint来实现
  3. 什么时间出具潜在的可交付物,达到什么样的目标
  4. 团队的接受力怎么样

ii. 创建sprint backlog

  1. 考虑如何实现这个sprint目标,从产品backlog选中要实现的产品backlog
  2. 进行任务拆分
  3. 创建sprint backlog
  4. 给sprint backlog的任务估算工作量(通常1-16小时)

b) 每日立会:每天早上上班开始,15分钟左右

i. 昨天我完成了什么工作

ii. 今天我打算做什么

iii. 我在工作中遇到了什么困难

iv. 每日立会不用于解决问题

v. 任务状态包括:to do(要做的任务)、doing(正在做的任务)、tested(已经测试过的任务)、reviewed(通过验收的任务)、finished(完成的任务)

c) Sprint评审会议:产品负责人评审和验收团队开发的产品功能

i. 回顾sprint策划会议定下的sprint目标

ii. 团队展示sprint中完成的功能,通过现在演示的方式展现功能和架构

iii. 产品负责人验收产品功能是否与产品需求相符,根据验收的结果,接受或拒绝团队提交的可工作的产品功能

iv. 产品负责人根据验收的结果,更新产品backlog

v. 团队成员都要参加,可以邀请所有人产品

d) Sprint回顾会议:团队定期进行自我检视和反省,发现什么是好的,什么是不好的,需要什么行动

i. 收集信息,找到问题的根本原因,讨论解决方法,制定行动方案

ii. 每个sprint都要做,一般控制在15-30分钟

iii. 全体人员都要参加,项目管理者、产品负责人、团队和可能的客户或其他相关人员

3.三个物件:

a) 产品backlog

i. 一个排序的、估算的、渐进的需求列表

ii. 一般情况下,使用用户故事来表示backlog条目

iii. 理想情况下,每个需求项都是对产品的客户或用户有价值

iv. Backlog条目按照商业价值排列优先级,优先级越高的条目越详细

v. 优先级由产品负责人排列

vi. 在每个sprint结束的时候要更新优先级的排列

vii. 多团队情况下,使用同一需求列表

viii. 确保下一个或两个sprint的产品backlog条目是可行的

ix. 团队需要花5%-10%的时间来做这件事情

x. 不育系产品负责人在没有优化backlog之前进入sprint计划会议

b) Sprint backlog

i. 要在sprint中完成的任务清单

ii. 能把产品backlog变成可用产品功能的任务

iii. 任务用小时估计,通常1-16小时

iv. 管理sprint的backlog

v. 团队成员这件挑选任务,而不是指派任务

vi. 对每个任务,每天要更新剩余的工作量估算

vii. 每个团队成员都可以修改sprint backlog,增加、删除或者修改任务

c) 燃尽图:指在冲刺长度上显示所有剩余的工作时间逐日递减的图

14.3 Scrum价值、误解和总结
1.价值:

a) 快速交付,每次迭代都能交付可运行的产品或软件

b) 到了开发的后期,也欢迎改变需求,积极响应和应对变化

c) 随时跟踪项目的状态和进展情况,及早发现问题和风险

d) 按照需求优先级进行开发,有利于改善项目提高沟通效率

2.误解:

a) 认为敏捷开发是拯救任何项目的银弹

b) 认为敏捷开发意味着不需要任何文档

c) 认为敏捷开发知识开发者的问题

d) 认为采用敏捷方法的开发组/项目不需要制定计划

e) 认为敏捷项目的范围可以随时改变

f) 认为敏捷开发只针对小项目适用

3.问题:

a) 角色经常更换

b) 会议效率低

c) 任务拆分不细致

d) 团队成员积极性不高

e) 过分关注短期目标

f) 信息沟通不对称

  1. 项目管理
    15.1 案例

15.2 项目启动
1.立项申请:目的是说服公司或者甲方愿意提供资源实施项目,可行性分析师立项申请的重要组成部分

a) 投资必要性:根据市场调查及预测的记过,以及有关的产业政策的因素,论证项目投资建设的必要性

i. 做好投资环境的分析

ii. 做好市场研究

b) 技术可行性:从项目实施的技术角度,合理设计技术方案,并进行比选和评价

c) 财务可行性:从项目及投资者的角度,设计合理的财务方案,从企业理财的角度进行资本预算,评价项目的财务赢利能力,进行投资决策,并从融资主体(企业)的角度评价股东投资利益、现金流计划及债务清偿能力

d) 组织可行性:制定合理的项目实施进度计划、设计合理的组织机构,选择经验丰富的管理人员,建立良好的协作关系,制定合适的培训计划等,保证项目顺利执行

e) 经济可行性:从资源配置的角度衡量项目的价值,评价项目在实现区域经济发展目标、有效配置经济资源、增加供应、创造就业、改善环境、提高人民生活等方面的效益

f) 社会可行性:分析项目对社会的影响,包括政治体制、方针政策、经济结构、法律道德、宗教民族、妇女儿童以及社会稳定性等

g) 风险因素及对策:对项目的市场风险、技术风险、财务风险、组织风险、法律风险、经济及社会风险等风险因素进行评价,制定规避风险的对策,为项目全过程的风险管理提供依据

2.组建项目团队:

a) 项目组成员主要有项目赞助人、项目经理、核心成员、非核心成员和其他人员

b) 团队成员:老板、项目经理、产品人员、UED人员、开发人员和运营人员

c) UED人员:用户研究员、视觉设计师、交互设计师、前端工程师和文案工程师

d) 开发人员:前端和后段开发人员、测试人员、运维人员

3.项目策划/制作任务书

4.项目开工会:

a) 召集项目团队成员,成员之间初步认识一下,项目经理主持会议,项目赞助人一般参加

b) 传达项目做什么,目标是什么,为什么做,怎么做,谁来做,项目经理是谁,每个人的职责是什么

c) 什么时候开始,什么时候完成,每个阶段要完成哪些任务

d) 项目成果评价的标准是什么,项目的约束条件有哪些

e) 项目的利益干系人有哪些,团队成员之间如何沟通

f) 统一思想,明确团队的管理和运作方式以及沟通机制

5.项目失败的主要原因:

a) 不完整或者不清楚的需求

b) 缺少客户的参与

c) 缺乏资源

15.3 项目计划
1.工作分解结构(work breakdown structure,WBS):

a) 按照产品的物理结构分解

b) 按照产品或项目的功能分解*

c) 按照实施过程分解*

d) 按照项目的地域分布分解

e) 按照项目的各个目标分解

f) 按照部门分解

g) 按照职能分解

2.活动排序:前导图(precedence diagramming method,PDM)用于关键路径法

a) 完成-开始(FS):最常用

b) 完成-完成(FF)

c) 开始-开始(SS)

d) 开始-完成(SF):最少用

3.资源估算:人力资源、物力资源、财力资源

a) 专家判断

b) 多方案分析

c) 项目管理软件

d) 自下而上估算

4.工期估算

a) 单点估算法:活动工期=最大可能值

b) 三点估算法:活动工期=(最乐观值+最大可能值*4+最悲观值)/6

c) 专家判断法

d) 成本估算:人力成本和非人力成本(硬件+软件+其他成本)

5.进度计划:

a) 关键路径法

b) 甘特图

6.风险计划

a) 风险来源:

i. 客户没有参与项目

ii. 得不到高层管理的支持

iii. 需求说明书不完整、不明确

iv. 项目计划编写不合理,预期目标不切实际

v. 工作任务的分解没有细化,没有责任到人

vi. 项目成员的素质不高,项目成员的工作精神状态不佳

vii. 挪用别人成果的所有权

viii. 项目前景和目标不清晰

b) 制定风险计划

i. 风险识别

ii. 风险等级评估

iii. 风险应对计划

  1. 规避
  2. 转移
  3. 缓解
  4. 接受

7.

15.4 项目执行和监控

15.5 项目收尾

  1. 产品运营的十个故事
    1.互联网产品是一个需要不断运营、不断打磨的产品。人家说好的产品是运营出来的,不是开发出来的——周鸿祎

2.目标明确

3.了解用户

4.抓住核心需求

5.核心竞争力

6.创意运营推广

7.站在用户的角度

8.应对风险

9.长远利益与短期利益

10.马太效应

11.标杆理论

  1. 产品运营规划和策略
    17.1 产品运营规划
    1.目标用户原则

2.投资回报率原则

3.阶段性原则

4.运营规划内容

17.2 运营策略和方法

1.开发平台

2.种子用户

3.媒介软文

4.技术工具

5.产品捆绑

a) 捆绑安装

b) 捆绑销售

c) 账号绑定

6.广告植入

7.合作整合

8.社区推广

a) 基于关系的社区推广

b) 基于内容的社区推广

9.创意推广

10.活动策划

11.事件营销

12.成长体系

13.数字营销

  1. 产品发布管理
    18.1 发布流程
    1.产品规划阶段(项目启动)

2.制作发布计划书(项目立项)

3.执行发布计划书阶段(发布计划书)

4.测试版本发布阶段(新产品发布)

5.正式发展阶段(发布后评估)

18.2 发布策略
天时地利人和

18.3 发布准备
1.产品命名和广告语

2.技术准备

3.各类培训准备

4.发布资料准备

5.产品市场定价

6.渠道建设

7.内容准备

8.宣传活动准备

9.认证资质和准入

10.账号申请和注册

11.客服准备

12.数据统计准备

13.相关通知准备

14.SEO准备

18.4 正式发布
1.新闻发布会

2.各类广告

18.5 监测调优
1.用户反馈的舆情监测

2.用户反馈的处理流程:

a) 运营组收集反馈,并判断反馈是否有效

b) 运营组将有效反馈分别提交给各部门责任人

c) 各部门负责人在24小时内给出处理意见

d) 运营组将处理结果反馈给用户

  1. 数据统计分析与挖掘
    19.1 必要性

信息=数据+时间+处理

19.2 流程
1.确定目标

2.数据准备

3.数据选择

4.数据预处理

a) 数据清理

b) 数据集成

c) 数据变换

5.挖掘模型

6.模型评估

7.发布结果

19.3 挖掘模型
1.聚类

2.关联

3.决策树

4.神经网络

5.回归

19.4 常用工具

19.5 案例

  1. 失败团队的问题和优秀团队的特征
    20.1 失败产品团队的典型问题
    1.执行力弱

2.团队成员不和谐

3.工作流程紊乱

4.沟通不畅

5.效率不高

6.需求变更频繁

7.文档缺乏规范管理

20.2 优秀产品团队的典型特征
1.优秀的组织领导

2.共同的事业愿景

3.清晰的团队目标

4.完善的制度流程

5.互补的成员类型

6.合理的绩效考核

7.系统的学习提升

8.独特的产品文化

30%的人永远不可能相信你。不要让你的同事为你干活,而要让我们的同事为我们的目标干活,共同努力,团结在一个共同的目标下面,就要比团结在你一个企业家底下容易得多。所以,首先要说服大家认同共同的理想,而不是让大家来为你干活——马云

  1. 产品团队管理
    21.1 产品团队组成
    1.独立部门产品团队:产品助理、产品经理、产品总监

2.跨部门产品团队:产品团队、UED团队、开发团队、测试团队和运营团队

21.2 最佳实践
1.招聘志同道合的人,不求最好,只求最合适

2.用人之所长,避人之所短,团队成员互补

3.读懂团队成员,不要伤害成员的尊严

4.在可控范围内给团队成员成长过程中犯错误的机会

5.设立挑战“911”基金,奖励出色完成任务的成员

6.设立惩罚基金

7.加强团队流程建设,鼓励成员分享知识和技能

21.3 成员考核
产品团队成员的考核可从需求文档、需求评估和优先级定义、需求管理计划表、需求变更、项目跟进、工作态度、沟通情况、运营指标和其他几个大项进行考核

21.4 冲突处理
1.竞争:由于团队冲突的双方都采取武断行为所造成的,双方都站在各自的立场上,各不相让,一定要分出个胜负、是非曲直

a) 优点:结果快,能立即分出胜负

b) 缺点:不能解决任何问题,全凭权力的压力

2.回避:指双方都想合作,但既不采取合作性行为,也不采取武断行为。你不找我,我不找你,双方回避这件事

a) 优点:不发送冲突,回避矛盾,个人得益

b) 缺点:公司受到损害,很多工作没人去做,造成工作积压

c) 提示:回避会有更多的工作被耽误,更多的问题被积压,更多的矛盾被激发,解决不了问题

3.迁就:指团队冲突的一方高度合作,不武断,另一方高度武断,不合作。牺牲一方的利益满足对方的要求

a) 优点:尽快的处理事情,可以私下解决,不用找上市,可以维护比较好的人际关系

b) 缺点:本身并没有解决问题,岗位职责没有得到维护

c) 提示:迁就是公司比较忌讳的一种方式,因为岗位的职责不维护,会对公司的管理造成伤害

4.妥协:冲突双方有部分合作,但有都很武断。双方各让半步,在一定程度上满足对方的一些要求

a) 优点:双方的利益都照顾到了,比较快或能够及时达成共识

b) 缺点:一些根源性的问题没有解决

c) 提示:妥协有时会出现别人和你讨价还价的情况,并再次提出更高的要求

5.合作:冲突双方高度合作,并且高度武断。双方彼此尊重,不牺牲任何一方的利益

a) 优点:能够彻底解决冲突双方的问题,并找出解决此类问题的办法,而且通过事先约定,防止下一次类似问题的发生

b) 缺点:成本太高,双方需要来回沟通

c) 提示:合作时一种理想的解决冲突的方法。就是双方彼此尊重对方意愿,同时不放弃自己的利益,最后可以达到双赢的结果,形成皆大欢喜的局面,但不容易达到

6.紧急且重要——竞争;不紧急不重要——回避;紧急但不重要——迁就/妥协;不紧急但重要——合作

21.5 特殊成员管理
1.摸清问题员工的需求,对症下药

2.抓住问题员工的弱点,使其就范

3.制定规则,积极引导

4.个性化激励,增加归属感

21.6 产品文化

你的产品可以不完美,但是只要能打动用户心里最甜的那个点,把一个问题解决好,有时候就是四两拨千斤,这种单点突破就叫“微创新”——周鸿祎

  1. 专业术语
    1.【B2B】:business to business,企业对企业

2.【C2C】:consumer to consumer,个人对个人

3.【C2C】:copy to china,山寨复制

4.【UGC】:user generated content,用户创建内容

5.【SNS】:social networking service,社会性网络服务

6.【ISP】:Internet service provider,互联网服务供应商

7.【ICP】:Internet content provider,互联网内容服务商

8.【WAP】:wireless application protocol,无线应用协议

9.【SP】:service provider,服务提供商

10.【LBS】:location based service,基于位置服务

11.【SoLoMoCo】:social社交的,local本地的,mobile移动的,commerce商务化

12.【UED】:user experience design,用户体验设计

13.【PEST分析法】:political政治,economic经济,social社会,technological科技

14.【API】:application programming interface,应用编程接口

15.【波特五力模型】:

16.【SaaS】:software as a service,软件即服务

17.【Paas】:platform as a service,平台即服务

18.【IaaS】:infrastructure as a service,基础设置即服务

19.【SKU】:stock keeping unit,库存量单位

20.【波士顿BCG矩阵】:boston consulting group growth-share matrix

21.【BRD】:business requirements document,商业需求文档

22.【MRD】:market requirements document,市场需求文档

23.【PRD】:product requirements document,产品需求文档

24.【UED】:user experience design,用户体验设计

原创文章,作者:wbq521,如若转载,请注明出处:https://www.wangbq.cn/426.html

发表评论

邮箱地址不会被公开。 必填项已用*标注

联系我们

18706728980

QR code