邱岳的产品实战-1

1.验证码是一个好东西吗

牺牲用户体验，换来了安全，减少了公司的开销

用户习以为常，却不和逻辑，但确暗藏机会

2.产品经理工具指南

1.纸和笔

有沉浸感

2.全能扫描王

3.Axure最多

4.POP/墨刀

5.Xmind

6.UML

Visio

3.Trigraphy的设计哲学

用户对于＞6s的无状态操作，会放弃这个应用

用户第一次使用应用的时候，只想了解应用是做什么的。如果第一时间没有吸引用户，那么这个用户多半就流失了。

我们可以使用用户引导暗示

4.如何当好AI时代的产品经理

唯一能持久的竞争优势，是胜过对手的学习能力

通过视频课打基础—>通过书深入了解—>通过实际按理来了解—>读论文—>点道为止，不会就换

5.AI时代-实践篇

纸上得来终觉浅，绝知此事要躬行

深度识别会向，端到端方向发展

产品要了解算法的边界，才能更好的去设计产品

人工智能一定会被打散，渗透到各行各业，各个领域内。这是产品经理的机会。

6.TheGuardian的文本之美

通过卡牌设计，将不同类型结合在一起

在不同的用户路径下，有不同的交互手势

7.需求背后的需求

唯一不变的就是变化本身

需求不会变更，变更的是实现

给需求分析留出时间

给产品留出讨论的时间，没有问题的产品，是不能开始做的。

8.化变更于无形

拥抱变化

怎么能让团队去消化需求变更

产品经理进门的门槛不高，但做到合格挺难的

9.Hppper的人工智能

人工智能不是让机器跟人交流，说人话。很多这种产品，反倒给人更多冰冷的感觉。

通过文案和细节，还有很多温馨的提示，让我们感受到了更多温暖。

10.产品被抄袭了怎么办

被抄袭说明你做的是对的

抄袭也带不走你团队的DNA

不要将产品的外表做为优势

idea、功能流程、界面都不是优势

要利用用户的积累信用

淘宝的信用
微信的朋友粘度
名片上印上了电子邮箱地址
音乐播放器的收藏功能

ASO优化

ASO全称是APP Store Optimization，即应用商店优化。概括来说，所有能够让开发者上传发布的应用产品，在苹果商店变得更容易被用户找到的方法和策略，或者说提升App曝光度的方法过程。

11.如何借鉴灵感

不要像素级的抄袭

学我者生，像我者生——齐白石

追本溯源，知其所以然

12.LabRdr的设计实验

权限获取，在用户设置了之后再获取

让用户付出的东西，是不是可行的。申请权限和用户获得的，至少要是对等的。

产品和用户的每一次互动，其实都是一次交易

只有当这个价值高于用户对于自己所付出资源的成本预期时，交易才会顺利地进行

13.产品规划（上）

作战计划书，做计划的过程却不可或缺——艾森豪威尔

自上而下

每个人都知道接下来的方向

自下而上

每个人都能更好的发挥

结合

先自上而下-然后自下而上
先下发目标，然后让各组做计划

产品规划不等于功能发布计划

14.产品规划（下）

No battle plan survives contact with the enemy

没有任何作战计划在与敌人遭遇后还有效

产品规划的留白

时间留白
- 业务的规划尽可能的在战略层来设计
空间留白
- 特别细节的可以留给之后

当你面前摆着一堆待办事项，你的创造力会被封印

15.Mimo与LearnPython的导学之趣

教育类的应用，需要自我驱动力

教育学习本来就是反人类

在教育里做社区，很多工具APP转到社区，提升用户粘度。

16.内部产品找到产品经理的价值

“心事浩茫连广宇，于无声处听惊雷。”

内部产品

公司员工内部使用的产品

资源线性化

业务部门了解技术部门多少人力
展示技术部门的交付能力

收集用户想要的非常方便

不要变成由功能驱动的产品经理

要跳过方案，寻找背后的动机的需求

内部用户一般直接提需求，要想想为什么？

17.产品经理如何获得非权力性的影响力

最好的办法，就是建立信任

主要方法：持续保质保量的完成工作

当你不断做对的事情，你能得到的信任就越来越多

主动承诺，成功交付，敢于承担，及时沟通

当企业里，大家对信任不是那么重要，不是成长性的环境，建议离开。

建立信任是一个长期的过程，事情一件一件的做好，答应了的要做好，以此积累信任。不能做的就不要答应；有风险的要提前预警，可能有什么问题导致什么结果；中途有问题的，尽早提出来；事后主动背锅承担责任。

珍惜自己的信用，尽心把事情'做好，甚至超出想象，不要被打上一个坏的标签。

18.WWF Together

人们在有眼睛的地方，会提高自己的工作效率

人们分享跟自己相关的图片或者视频，是比较愿意的

榫卯、WWF、BBC纪录片 —IOS平台

19.与开发打交道

产品和开发，一定要关系好，一定要多沟通

产品，为什么做什么

开发，做什么怎么做

大家都是有一致目标的：让一个产品活的更好，活得更久，所以产生对立的情况，是由于双方共享信息不够透明及时，信息不对称导致猜疑和矛盾。主动沟通，弥补对方的信息短板，市非常好的沟通法则。学习了，产品把“why”讲明白，是在讲，用户场景需求，工程师把相对通俗易懂的“how”讲懂，双方共同决定“what”的方向。

20.合作共赢

多鼓励开发多给自己提意见

让工程师和产品经理轮流做项目经理

产品经理要勇于帮工程师承担责任

鼓励产品经理背工程的KPI

产品和开发能不能找到共同的外敌

21.Fabulous的精致养成

每个人都会自己本能的关注自己

藏在姓名中的细节

在整个流程的一开始，它就会询问你的姓名。而是一个姓名，不仅仅用于个人中心里面进行展示。他的整个流程中都会亲切的呼唤你的名字。

跟用户交流的时候，我们在谈论他，我们在谈论用户，用户就更关注。

习惯养成类的应用，不可以一次养成太多的习惯

22.图文基本功-1

清晰的表达是核心

没有内容的形式和没有形式的内容，都是不能存在的。

产品必须要有做出漂亮文档的能力

PRD（产品需求文档）

多看模版
重操作的 To C 产品可能需要交互流程描述和线框图
To B 的产品可能注重的是概念模型和业务流程

BRD（商业需求文档）

描述的是商业级别的内容和判断，通常逻辑和内容会比较短小精悍，但背后要有广泛的调研和思考基础
公司股东层面
面对重大的战略决策
大部分的项目是不需要BRD的

MRD（市场需求文档）

一般会在既有的产品路线上启动比较大的项目或者新功能时用到
是PRD和BRD的承上启下的作用
回答是我们怎么做

其他文档

UC文档
- UseCase用例文档
  - 引言：注明文档的目的、主要读者及文档中使用的术语；
    任务概述：简要介绍系统的目标、系统（或用户）的特点、假定和约束；
    功能需求：这部分是文档的重点，占了很大部分；
    非功能性需求：如外观需求、易用性需求等；
    接口：识别系统和外部其它业务系统直接的交互；
    文档需求：对帮助文件、联机手册、开发手册等特殊的文档需求；
    需求分级：对需求的优先级排序。
FSD 是功能详细说明（Function Specifications Document）
- 时候我们也称作 FRD，我们经常说“写 Spec”，其实就是指它。这时的文档就偏向实现了，交代具体的数据字典，概念模型结构，业务接口规范等等，一般 FSD 会跟 PRD 合并，不会单独拆出来。

大部分项目中，如果你写了 PRD，就不大需要再写 FSD 了。除非项目的规模很大，涉及各种各样的子项目，可能整个项目组有一套 PRD，但每个具体的子项目会准备专门的 FSD。

DRD
- 交互说明文档
  - 所谓DRD即是用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。
产品原型
- 静态原型
  - 纸和笔-线稿
- 动态原型
  - Axuer交互
- 做原型逻辑和框架表达清楚就行
- 标注：让组件和逻辑描述的更清楚

23.图文基本功-2

常用图例

概念模型图
- 最初的设计会影响到产品
流程图
- 描述过程
  - visio
  - 一般描述单一功能
泳道图
- 能够直观地描述系统的各活动之间的逻辑关系，利于用户理解业务逻辑。
时序图
- - 读图成本低
状态图
- 系统中所有实体都有状态
- 订单有状态、人有状态
用例图
你的每个用例都是为了盈利的，或者是为了盈利做准备
要保证每个用例用户都是愿意买单的
不要拘泥于一种工具，每种工具都是为了解决某一个问题而产生的。
多了解一些工具，你就多了一些思路和方法。

24.PathSource的混乱与直观

短而粗糙的视频，我感觉是很真实的感觉

给找这个方向职位的人更安心的感觉，这是更真实的工作状态

25.产品世界的暗黑模式

观点：很多人都在犯得错误，依然是错误。

卑鄙是卑鄙者的通行证，

高尚是高尚者的墓志铭。

让你无意间泄露信息，通过收集用户的信息，逼迫用户购买，垃圾邮件，强制续费。

这被称之为：暗黑模式

没有垃圾邮件，就不能有更大范围的传播了

没有道德瑕疵的产品，没有足够强的卖点。

26.写好产品文档的诀窍

1.明确受众，目的和形式

2.BRD-面向的是管理层

3.PPT，阅读型和演讲型的

4.PRD-面向工程师

最好图文并茂，现场讲解
文档要增加易读性
文档要先写厚，再写薄

5.文档写作最后发酵一下

睡一觉，脱离出来，再继续写。

27.Quartz&Hooked的对话交互

利用思维模式和阅读习惯的设计

聊天记录形式的设计

28.产品分析的套路-1

谁的，什么问题，用什么方法

谁的？

从投资者的角度考虑问题
- 是产品经理成功的标致
供应链
上下游
用户本身

平台型产品可能遇到的问题

成为上游供应市场的技术公司
被平台中的优秀销售代表所垄断
- 比如小池柑橘形成垄断后，
  大家只买小池柑橘。

29.产品分析的套路-2

能帮助我们完成进步的，恰恰是人类的天性本身

分析产品问题X的时候，我们想到了Y解决方法。

然后我们把全部精力都放在怎么实现Y方法上，而忽略了去思考，应该从X问题本身出发。

场景会演化出很多功能

浏览器的收藏
- 演变成了书签栏
知乎的收藏夹
- 演变成了UGC

怎么了解一个职位

了解他们一天要做的事情
了解他们的绩效考核
了解他们最害怕什么
跟他们交朋友

产品经理接到的需求通常不是真正意义上的“需求”，而是提出需求的人，基于某一个需求提出的“解决方案

30.Primer的交互

卡牌交互的魅力

人的操作非常自然

把内容切的很碎

31.产品分析的套路-3

一定要大量的把玩互联网的产品和服务

接触的方案越多，你就有更多解决方案的能力

要拿出精力来设计第一印象

要跳出功能开发来解决问题

从内容的源头做好使用引导降低用户的错误率，比事后通过审核驳回来教育用户，用户体验要来的更好。同时还能降低审核的压力，对这个公司或者组织而言都是有益的。

产品经理确实经常容易变成功能经理，遇到需求和问题，立刻着手从功能角度找方案。着的确是我们这一行的“笨蛋锤子”。

32.从受众规模，需求频率和强度出发

产品经理需要让正确的事情相继发生

中国的流量红利和人口红利

随便一个产品，做toC的，面向的就是中国10亿互联网的网民，其他国家，估计只有几千万。

需求优先级的衡量

列出来（list）
判断规模TAM
- 推测受众人数
- 基础服务强度
- 需求使用频率

受益者越多、问题的频率越高、强度越大，则解决这样问题的价值就越大，优先级也越高。

33.Arts&Culture的架构之美

设计精妙

内容很有意义

34.价值曲线（排定需求优先级方法）

把精力放在思考上，而不是工具上

先做好优先级最高的事情，然后把一些重要的指标，先做到及格线，最后突出那么一两个指标。把这一两个指标做到10倍或者更高。这样，你就有了核心竞争力

淘宝和京东

京东把正品和配送都做到了极致
这样京东就从这个角度活了下来

当排在第一的问题我们解决不了，成本太大。

那我们可以线解决第二个问题

原研哉设计的医院里几乎所有的桌布，灯布，产房的标识都是用白色的布。由于白色非常容易脏，一方面督促医院要能保持整洁，另一方面，通过长期整洁的白色，将“卫生”这个概念从视觉上展示了出来。创意的视觉设计可能有时候会是一个很好的解决方案。

35.代表性问题

1.怎样展示自己在AI方向的优势

1.在AI有实际的成果（用数据说话）
2.描述我认为的AI和面试公司业务的提案
3.介绍一下学了什么，有什么感悟
无论是在学校学习还是工作中，需要有打造自己“作品集”的意识。说自己学过什么，不如说自己能做什么；说自己能做什么，不如说自己已经做成了什么。

2.交互和产品的边界

产品：用文档来描述用例流程
对于能力不强的交互，就要一点点教了

3.时间不多，没办法进行产品发酵

当你很无能为力的时候，你可以处理完事之后，直接去睡觉，然后第二天早上起来再看。

4.怎么让团队对需求评审用心

提升团队对需求评审的好奇心

5.好的信息架构是什么样的

设计
- 让信息可以自己表达自己架构
- 从用户角度考虑信息架构
  - 符合用户的心智模型
  - 比如电商就分很多线路
    - 线路对应不同的人群

6.AI火热，前景真的好吗？

AI是用新的方法来解决老的问题

7.1-2年的产品经理，怎么面试

能发现岗位的来龙去脉
能证明自己在任何岗位有能力
能把工作完成的非常好

8.转产品是不是应该继续

建议先做好本职的工作，之后再转到产品
当做好本职工作后，你会发现，你的很多东西都能运用到产品中去。

9.需求变更怎么沟通

跟谁沟通就用他能接受，他喜欢的语言去沟通

36.案例分析：解读知识星球

如何让一个论坛类型的APP，很多年以前的优秀内容，能让新来的人也看到。

知识平台类型的APP，每个星球的球主的离开，都对平台有很大影响。

37.做好需求评审-1

如何让大家关注产品

提前发出文档
工程师来组织评审
规定每个人必须说两个以上的点
部门代表，在纸上签字

需求评审的受众和目的

需要向其他人讲清需求的背景和来龙去脉
说明这个东西，跟大家都有什么关系
要做到你提的东西不会让大家意外
开会前要把产品文档发出去
如果有条件可以一对一的跟进一下
如果你对需求评审都吊儿郎当，别人也不会在意的

38.做好需求评审-2

如何在评审中控住全场

当心知识的诅咒

当一个人拥有某种知识的时候，就难以表达清楚某件事情，因为这个人提前不知道这个知识。没有办法明确传达给人。

不要强迫要吸引

与人相处更是如此
从场景和故事出发，让每个人都能听懂
对产品方案有信心，自信者，人恒信之

不要为了赢而争吵

复述，专为陈述句。
待会会议结束，我在跟你线下，单独过

39.SeatGeet的订票设计

显示票量在价格区间的分布

支付页面是卡片

这样交互体验会衔接更流畅

40.产品鸡汤

成长不是顿悟，而是练习

没有任何一个抉择是生死抉择

不是每个抉择都会决定生死
有时候甚至什么都不做，都能活下来
我们应当对无用的更改进行克制

平淡无奇，十之八九

哪有什么胜利可言，挺住就意味着一切

坚决执行，不要绣花

在战略上谨慎，在战术上激进

41.产品的管理心得

产品一定要利用影响力来影响团队

管人＞管事

团队士气低落，团队会不稳定

在达成阶段性的目标，给大家买点水果。或者选拔一下我们进入什么阶段也行。

项目进展受阻怎么办?

加班
砍需求
加人
可以根据项目的重要程度，适当留有延期时间

项目经理的心态一定是稳住，心态要好

42.Unread的阅读体验

“良好的设计，当它做得好时，变得不可见。

有些时候设计过于好看，抢眼，反而是对APP是一种伤害。

43.玩的力量

打游戏和做工作的性质是类似的

打游戏是我们自找的
工作是违背我们意志的

游戏设计的手段

1.实时反馈
- 一些简单的反馈，会激活我们身上低级神经的反应，让我们沉浸到游戏里。（比如，开枪枪响）
- 比如按钮的反馈
- 交互设计里，有动效，反馈，或者是声音
- 戏不要过，不要产生负反馈
2.人性的开关
- 游戏利用我们的囤积欲
  - 收集勋章
- 游戏利用我们对损失的厌恶
- 游戏利用好奇心
- 利用游戏里的成就感，自豪感
- 渴望自己变得越来越好
- 禀赋效应，是指当个人一旦拥有某项物品，那么他对该物品价值的评价要比未拥有之前大大增加
  - 比如，你分享给朋友才能获得代金券
  - 比如，你做任务才能获得代金券。

游戏令人上瘾的原因，不外乎以下四种：

1）量化目标：打通副本、完成任务；
2）即时反馈：数字特效、进度提醒；
3）自主通关：提升等级、购买装备；
4）社交联系：组队打怪、加入公会。

对于任何技能或是工作，我们皆可设计人生闯关游戏，高效地制定学习套路，为自己带来无限学习热情。

1）量化目标：为自己设立短期目标；
2）即时反馈：我们最好为短期成果制定具体的数字；
3）刻意练习：多次使用这项技能，可通过多维度来检验；
4）主动社交：想尽办法寻找拥有某项技能的人或者人群。

44.玩的启示

游戏设计手段

与社群建立联系
- 王者荣耀
  - 5V5开黑
    - 不同的分工，赢得比赛
- 页面设计上随便加个用户头像，都算社区
  - 排行榜也算社区
- 社区一定要有运营
  - 否则有比如没有
    - 有人，就要有运营

构建意义

每个人都渴望成为独一无二的伟大
- 游戏的主线任务和剧情，往往建立在宏大的叙事

处心积虑的功能性设计，远不如关键性的机制设计来得重要、有效。

假设我们想要促进知识产品的销量
- 精心设计分享按钮的颜色
- 设计文案
- 处心积虑的功能性设计
- 如果是分销机制呢？
  - 如果A用户分享给B用户购买
    A用户得到佣金。

45.Chartistic复杂的图表

产品做出来一个很烂的版本之后，我们就知道怎么去优化了，所以先能做出来一个小的版本。

从场景出发，而不是从功能出发，给用户更好的体验。

把一个复杂的工具塞到手机里

如果用户“开始 → 完成”一个任务的路径较长，需要完成较多的步骤才能看到结果，用户非常容易放弃，手机场景下更是如此。大部分用户希望自己点击一个按钮，所有的一切都如自己预期一样，自动完成。

使用“假数据”（或者说是占位数据）在一开始就产生正向反馈，让用户感觉已经“完成”任务，只需要“修改”一下，进而产生安全感和掌控感。我发现，很多用户在做一件事情时，比起重新“创建”更喜欢“拷贝”已有的任务，然后修改，这让他们感觉一切都在自己的掌握之中。

Chartistic 对手机场景的理解让我印象很深。我设计App时，经常容易套用已有的条条框框，而不是从场景设计出发考虑功能。好的设计，就是当用户想做一个动作时，那个功能就在他预期的地方；产生一个疑问时，答案就及时出现。

设计 Chartistic 的公司，Zoho，是一家开发面很广的公司。曾经因为工作需要调查一些现有解决方案的时候，经常能看到这个品牌。很佩服他们在保证广度的同时，还能在App细节上这么下功夫。