邱岳的产品实战-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细节上这么下功夫。

46.产品经理的世界没有对错

产品是产品经理唯一的名片