《启示录》说了啥
缘起
这是另一个系列文章的第一篇. 所以, 我说的这个 “缘起” 不仅是我为什么写这篇文章的缘起, 也是我为什么写这个系列的缘起.
2015 年的时候, 我开始了我的产品生涯. 现在看来是一件非常偶然的事情: 当时公司的一个产品经理生病了, 而他所在的项目又很急, 所以必须要在业务部分中选一个相对比较懂技术的人顶上去. 这个人就是我.
所以我干产品经理算是半路出家.
而且, 在我做产品经理的这几年来, 带过我的师傅主要有这么几位:
- 第一个教我的, 是一个做项目管理的大哥, 姓李. 手把手的教我, 一个采用瀑布模型的项目应该怎么作. 现在这个大哥还在海航做其他项目.
- 第二个教我的, 是一个做技术的老板, 姓周. 我一直使用 UML 做流程设计, 就是受他的影响. 现在这个大哥自己创业了.
- 第三个教我的, 是一个做咨询的博士, 姓应. 我对于商业模式, 分工界面, 业务架构的观点, 几乎都是他培养起来的. 现在这个大哥在学校里教书.
可以看到, 在我做产品经理的生涯中, 没有一个真正干产品的人, 告诉过我产品经理是个什么岗们, 应该干些啥.
而且自我做产品经理以来, 我就一直在做区块链应用.
所以在我的心理就有一个非常大的焦虑: 我所积累的经验, 技能和产品设计方法论是只能在区块链行业里用, 还是普适的.
这个焦虑在 2018 年初, 达到了顶峰. 我下定决心离开区块链行业, 要在其行业中试一试.
而《启示录》这本书, 就是当时面试我的一位大姐推荐的.
当时我去面试, 和这个大姐聊了不到 5 分钟, 就已经确定我不适合他们所招的岗位了. 所以后面就聊的比较放飞自我.
我提到了我的焦虑和困惑. 大姐荐议我去读这本《启示录》.
我买到这本书后, 将书中所说与自己的经历一一比对, 终于把一颗焦虑的心放回了腔子里.
所以这本书算是我的 安心之物. 所以我也把这篇文章作为这个系列的开端.
如果只看《启示录》的目录, 你可能觉得这本书系统的讲了一个产品经理如何做出一个产品来. 但是等你看到正文的时候你会发现, 这本书的体系性没有那么的强. 它更象是一部文集: 独立写作的文章, 按照主题被组织起来.
另外, 很显然作者喜欢凑整. 什么十条规律啊, 十个建议啊. 不要当真, 一看就凑出来的: 有的两三条说的是一个事, 有的又是对前边几条的总结.
产品设计的对象是用户的情感
作为信息产业, 互联网行业脱胎于 IT 行业而与 IT 行业有着本质的不同. IT 行业提供的是信息化系统, 而互联网提供的是服务.
正是这点不同, 使诞生于互联网时代的产品经理具备独有的特质.
因为 IT 行业提供的是信息化系统, 所以在 IT 行业中, 通常的情况是我有一个业务模式, 现在只是需要把他实现出来. 所以在 IT 行业中, 设计工作最终是要的是提供一个实现模型: 让机器理解人要做的事.
而在互联网时代, 则发生着明显的不同: 技术方案极大的丰富了, 我们的任务是利用这些技术方案为不特定的大多数提供服务. 所以设计问题的核心离开了实现模型, 变成了概念模型 — 也就是应用场景. 因为只有在实际的场景中, 人才可以理解系统能做什么.
而在《启示录》中把这个问题挖的更深, 他以 IPHONE 为例, 谈到苹果公司给他的四点启示:
- 硬件为软件服务;
- 软件为用户体验服务;
- 用户体验为情感服务;
- 产品为真正的用户需求服务;
产品面对的不是一个权力体系 (如权力结构完备的公司), 而是面对的活生生的人. 因此产品设计是试图回答这样一系列的问题: 我们要在什么样的场景下, 通过什么样的手段, 使那些人, 产生什么样的情感, 以此达到什么样的目的.
《启示录》以新能源汽车为例作了精采的说明:
在《启示录》成书的年代里, 新通源汽车的技术远没有现在成熟, 是一种成本极高的解决方案, 那为什么还有人会为这种解决方案买单呢?
非理性消费者也甘愿花两万美金购买普锐斯, 因为他们是狂热的环保主义者. 他们完全可以把购买普锐斯的钱用在别的地方, 比如买一辆摩托车, 一样可以减少温室气体排放做贡献. 他们急于解决问题的心情促使他们为昂贵而不实际的解决方案买单.
所以:
- 首先是一种身份认同 (如 “狂热的环保主义者”);
- 然后基于这种身份认同产生某种情感诉求 (如 “急于解决问题的心情”)
- 最后在这种情感诉求的驱动下用户会达成我们的产品目的 (如 “为昂贵而不实际的解决方案买单”)
为什么某知识付费的产品, 爱称其用户为 “爱智求真的小伙伴”, 因为他们的产品目标, 需要在这样一种身份认同所产生的情感诉求下达成.
支撑与干扰: 分工界面
产品设计以情感为对象, 也被其它要素所支撑: 人与技术.
只有真实的人, 在真实的场景下, 使用真实的技术, 才能产生真实的情感, 并以此真正达成产品的目标.
- 体现 “人” 的要素的部门有: 客服, 运营, 销售等部门.
- 体现 “技术” 的要素的部门有: 技术, 研发, 开发, 项目等部门.
而这些支撑要素, 同样也是干扰要素.
人对于产品的干扰
混淆客户需求和产品目标
最常见的例子是 OA 系统. 这个世界上没有一个 OA 系统是被他的用户 (公司员工) 所喜爱的.
原因很简单: 员工作憎恨的不是 用指纹, 地理信息, 面部认别打卡 , 他们憎恨的是 打卡制度本身 . 但他们又不能诋毁公司, 咒骂老板, 所以只能将怒气发泄在 OA 系统上.
所以我们如果把提升使用者的幸福感作为产品目标, 我们的产品会陷入到一个痛苦的失败循环中去.
为什么产品需求不能用户说了算
即使用户需求和产品目标是一致的, 用户需求也不能由用户说了算. 《启示录》对此解释道:
- 在看到产品前, 用户很难知道自己需要什么;
- 用户不知道什么产品是可行的;
- 用户之间缺少沟通, 很难达成统一.
这个道理就和医生要 根据病人的具体情况进行治疗, 但不能根据病人的提的方案进行治疗 一样; 只要我们承认 产品工作是一个专业工作 , 产品工作就应该 依靠专业技能 而不是由用户说了算.
技术对于产品的干扰
尤其是技术驱动的公司, 产品很容易被技术所干扰. 这种干扰主要来自于 “发现新热点, 开发新市场的冲动“.
这里我们举两个公司的例子来说明.
任天堂
任天堂对于自己的定位是玩具公司, 因此任天堂很少刻意的进行技术创新.
我们的指导思路是, 怎样可以为玩家带来愉悦的惊喜. 我们并不刻意的做创新, 而只是尝试找到让人们开心的方法, 所以往往做出其他们没有做出过的东西.
—— 任天堂研发部总经理
就是在这样的指导思路下, 任天堂用硬纸盒和 Switch 创造出了 Labo — 没有任何的创新, 但带来前所未有的创新游戏体验.
所以, 创新, 并不需要什么 “吓人科技”.
IBM
在前文提到的应博士带着我们做调研的时候, IBM 几乎成为了我们产品部的开心果.
无论我们在调研什么新兴技术, 都会看到 IBM 在该技术诞生阶段就冲入这个行业, 教育了市场, 培养了人才, 但在市场成熟后消声匿迹.
据说在云计算领域, 在 PlayStation 2 的时代, IBM 提出过这样一个路线:
当时的图形技术己经非常成熟了, 可以为游戏提供更好的画面, 但是图形技术受制于硬件的计算性能. 因此他们提出, 服务器的计算能力是非常强大的, 可以将图形计算的功能放到服务器, 通过云计算的方法来进行.
想法很好, 技术也不错, 但是当时网络环境并不能支撑这样的技术路线. 所以这条技术路线至今也没有实现.
分工界面
道理大家都懂, 但 为什么有的公司就可以避免人与技术对于产品的干扰, 而有的分司就避免不了呢?
是因为分工界面.
如果设置一个独立的岗位没有什么道理, 那个岗位就不会被独立的设置出来.
《启示录》一书, 细细的分析了, 如果产品岗位和营销部分混淆会产生什么问题:
也分析了, 如查产品岗位和项目/技术部门混淆会产生什么问题.
而正是在与其它岗位的对比中, 才定义了产品岗位到底是什么.
设计一个产品
好了, 我们知道了产品是 基于真实的需求, 利用用户的情感, 实现产品目标.
那么我们怎么保证我们的设计是 基于真实的需求呢?
《启示录》提出了一整套流程. 但把最重要的概括起来说: 前期做好用户研究, 后期做好原型测试.
前期做好用户体验
前期用户调研的方法主要分为三步:
- 约谈特约用户
- 进行市场调研
- 建立用户画象
约谈特约用户
进行市场调研
建立用户画象
用户调研是为了找到应用场景.
应用场景就好象产品功能的上下文. 产品功能是有在应用场景中才是可以理解的.
对于 2B 的产品我们可以找到客户的 业务关键人, 对于已经上线的产品, 或已经进行过初部动营的产品, 我们可以找到 种子用户.
但更多的时候, 应用场景是通过调研 行业前辈和竞争对手获得的. 教育用户成本是很高的, 所以如果有与产品的应用场景相似的前辈, 最好的方式学是直接向前辈学习. 不要重新发明车轮, 对于产品工作是一样的.
后期做好用户测试
曾经在网络上盛传着一种 “高保真原型无用论“ 认为, 原型说到底是一种工具. 主要是为了向开发人员说明, 产品是什么样的. 因此只需要能说明问题的 线框图 就可以满足这个需求. 高保真原型吃力不讨好, 还可能会误导 UI 设计人员.
曾经我也深以为然.
但这个结论是以 原型是给开发人员看的 为前提的.
《启示录》主张产品经理 一定要出高保真原型. 而 高保真原型是用来做原型测试 的.
原型测试 是用来测试我们产品所提供的应用场景是否真的可以被用户理解: 也即是 可用性测试.
如果我们不使用高保真原型来作原型测试, 那我们实际上是在使用我们的第一版正式上线的产品在作可用性测试.
而如果我们用正式上线的产品作可用性测试, 即使我们发现我们提供了错误的应用场景, 考虑到公司政治, 我们也没有勇气进行改正, 结果就会是将错就错的将就着.
