33-邱岳的产品手记

开篇词 | 产品经理的世界没有对错

你好，我是邱岳，外号“二爷”，是个从业近十年的产品经理。

过去，我不太喜欢分享跟产品相关的东西，只是偶尔写写书评。一是觉得自己还没有形成值得对外输出的知识体系；二是因为产品与技术不同，产品领域只有成败，没有对错。

我们经常会听到说某款产品失败了，但它的技术团队非常厉害，却很少听说某款产品虽然失败了，但产品经理很厉害。

技术是硬指标，同样的业务，我单机能扛你十倍的 QPS，就可以直接宣布胜利了。

同一套标准测试数据，你写的算法召回率和准确率都比我高，性能还比我的好，那也没有任何争辩的余地，我立刻鞠躬致敬，评价标准硬朗而清晰。

产品却不一样，它并没有一个明确的判断标准。小到产品特性的选择，比如微信的用户头像是方的，QQ 用户头像是圆的，哪个优哪个劣？钉钉有已读回执而微信没有，哪个好哪个坏？微博下拉刷新停留在最新，Twitter 下拉刷新停留在当前位置，哪个对那个错？大到产品规划，先做留存还是先获客，头部还是长尾，社区还是工具？

每次有人找到我，想咨询我对类似问题的看法，我都不敢随意给出回应。因为怎么说都有道理，怎么说都能说圆。如果不是非常清楚一条产品线的来龙去脉和设计原则，哪怕只是一个细节，都很难给出明确的建议。

尤其年纪大一点的产品经理，见过了足够多的黑天鹅，看遍了各种意料之外的对错，更不敢随意分析，妄自断言。

越是在自己的产品里横刀立马的人，越不敢对别人的产品指手画脚。英语里有句话叫“it depends”，产品领域的对错取决于各种环境变量，更取决于掌舵人自己的价值选择与世界观。

产品经理行走江湖不看招式也不看颜值，产品，才应该是他唯一的名片。

如此看来，开个专栏写产品设计，对我来说实在是个忐忑之举。摸爬滚打数年，纵使有一腔倾诉欲，却又担心所观所想会误人视听。

极客邦总裁池老听闻后，拍桌子瞪眼说：“你把我们用户当什么人，怎可能你一句两句就能给带偏了？”

我一想也是，专栏作品从来不是什么“教程”，而应当是一扇可供交谈的窗口，所谓知识经济，其实带来最有价值的不是知识，而是求知的启发。

所以我决定应了这差事，在专栏里写写自己在这么多年产品经理生涯中的见识和思考。我会尽可能避免求全中庸，尽量提供结实的结论。希望我能给你带来的是启发，而不是一份标准作业手册。

专栏的内容会从产品经理的岗位特性和职能出发，会涉及以下几个方面。

产品经理的基本功。包括如何写好产品文档，如何开好需求评审会，如何管理产品节奏，如何做用户调研等，这部分内容可以帮助大家在日常工作中游刃有余，建立良好的习惯。

产品经理的实战素养。这部分内容会跟大家分享产品经理的实战经验，从典型工作场景出发，聊一聊怎样做项目管理，怎样跟开发、运营、业务打交道，怎样建立数据意识，以及结合我目前的创业项目，聊一聊如何做好 AI 时代的产品经理等。

产品观点与思考。除了工作，我还会分享一些自己的观点和思考，不考虑对错，而是努力抛砖引玉，尽可能为你带来启发。比如怎样应对抄袭，如何剖析产品价值，或者是如何看待需求变更等。

产品案例分析。产品经理平时总会大量使用各种产品，并从中吸取灵感和收获启发，这一部分我将定期提供自己把玩到的有趣产品的试用视频，把触动我的细节掰开揉碎，细说它们带给我的启发。

我希望这里的内容尽可能普适，但每个人都会有局限性，所以我也希望在这里可以多一些互动。或许你可以给我提交问题和分享见解，让我们互相促进，共同成长。

总而言之，若幸得你的订阅，我必将尽己所能，尽力不辜负你为此投入的时间和金钱。

愿我们可以度过一段有趣而充实的旅程，欢迎上船，一起加油！

01 | 验证码是个好设计吗？

当你注册或者登录某个应用的时候，经常会用到验证码。它们大部分是由一串歪歪扭扭的字符组成的，看起来并不容易辨别。

验证码的英文名是 CAPTCHA，这不是一个正规的单词，而是个缩写，它的全称是：Completely Automated Public Turing test to tell Computers and Humans Apart，翻译过来是：用来区分人类和电脑的全自动图灵测试。不知道为什么，我就是觉得它听起来像一个不大正经的恶作剧。

据维基百科的描述，验证码出现于十年前，是为了防止机器（程序）假扮成人，去占用原本为用户准备的资源。比如，利用脚本程序不断地模拟尝试登录以便破解账号密码，或者利用恶意代码在 BBS 中发布大量广告或诈骗内容。

可以看到，它的设计初衷是为了区分人和机器，实现方式是在正常流程中增加了一道门槛，人可以翻过去，而机器会被挡住。

从某种意义上说，它可能是个有效设计，但我不认为它是个好设计。因为挡住机器这件事本应该是服务提供方的责任，而服务方却将其成本转嫁给了用户。

这件事引发了我的思考。

第一个思考：不要将责任推卸给用户

不知道你有没有想过，让用户辨别和输入扭曲的验证码，其实是因为服务提供方的能力欠缺，无法静默区分人和机器，而输入验证码本身，这一操作对用户来说其实并无价值。

有一次我接到用户打来电话，抱怨自己搞不定验证码。我向他解释我们正在被攻击，所以临时调高了验证码的级别。电话的最后，我习惯性地向他道歉，用户却很体贴地安慰我说没必要道歉，毕竟被攻击不是我们的错。

当时我心头一热，脸上一红。他说的没错，被攻击确实不是我们的错，但更不是用户的错，让他们付出成本，花费时间，去辨别图片里的那个圆圈究竟是 O 还是 0 还是 6，其实就是让他们承担我们本应该承担的责任。

举一反三，如果再激进一点考虑，我们的软件服务中还有不少推卸责任的设计，比如让用户在成千上万的商品中筛选和比价，比如各种复杂的界面参数设置和兴趣选择。要是想得再发散一点，所有的银行账户密码似乎也没有必要，超市排队也是一样。

如果用户不需要付出筛选和比价的成本，或不需要花费精力记住账户密码，却可以享受到同样高质量的服务，是不是更好呢？

基于这样的思考，我们是不是应该马上去掉这些推卸责任的设计，比如想出更复杂的方案，替代现有的验证码机制呢？这是关于验证码的第二个思考。

第二个思考：方案选择的平衡

有效的设计确实未必是好设计，比如我自己曾经参与设计的产品中也用到验证码，而且在某些特殊阶段（像刚才提到的被定向攻击），我们还会升级验证码机制，让验证码出现的频率更高，而且更加难以辨认，从而在某些关键入口抵抗一些有针对性的攻击。

这一策略是有效的，但对用户的伤害也很大，升级验证码机制后，用户登录过程中耗费的时间会显著增加，通过率也会下降，还有大量的用户抱怨一股脑地涌进来。

然而从服务提供方的角度来看，它却用最低的成本快速地解决了当时面临的问题。这是产品设计方案选择过程中不得不做出的“平衡”，很多时候我们没有办法第一时间实施对用户的完美方案，这就需要在产品利益和用户利益之间，找到微妙的动态平衡点。

所以让一个产品经理讲用户价值其实不难，天花乱坠说完美方案也不难，难的是在实际工程里做出合适的决定。做工程大部分时候都满身污垢，能在其中保持镇定，保持平衡并不容易。

我们当时在扛过了几轮攻击之后，投入了一些技术资源，引入了更多静默监测的策略。比如记录用户密码、记录用户上次登录的位置 / 设备，或通过一些页面动作来做出判断，保证大部分老用户和一部分新用户不会受到验证码的打扰。

我们并没有做到完美，因为资源永远有限，我们需要把它更多投入到我们的竞争优势上，所以还是保留了验证码机制。在某些情况下还是用这种原始、粗暴，但有效的手段来解决问题——这就是我们选择的平衡。

第三个思考：验证码的进化

Google 在两三年前发布了一个叫作 reCAPTCHA 的解决方案，本着“对人类友好，对机器难搞”的原则，用户只需要简单点击一个“我不是机器人”的复选框就可以，不再需要分辨歪歪扭扭的验证码。reCAPTCHA 通过收集用户环境和行为数据，综合分析、智能区分人和机器。

除此之外，阿里也发布了自己的滑动验证码，还有国内一些第三方的验证码服务也在快速迭代进化。毕竟 Google 的服务不太稳定，他们还是获得了自己的生长空间。

这些更高级的验证码服务，大部分都在标榜自己的“人工智能”属性，不管真假，这确实是个非常典型的机器学习应用场景，提供各种行为特征，训练算法去分辨人和机器。

我们把这个思路放大来看，如果可以把过去看似理所应当，其实是由于服务提供方的成本考虑，而把责任推卸给用户的那些功能或流程拿出来重新思考设计，再搭配成熟的机器学习算法，或许就可以带来一系列革命性的用户体验进化。

比如免密支付，让用户不必再耗费精力记录密码，比如无人超市，让用户无需排队付款，无人驾驶，让用户在通勤的过程中不需要费神开车，等等等等。

这个伟大的变革时代提供了新的方法和工具，让我们有机会重新去审视过去由于技术和工具的限制而不得不做出的妥协。

用新方法解决老问题，或许不需要什么翻天覆地的变化，只是撬松一两块被惯性封印的砖，就已经算得上强有力的推动了。这是验证码给我最后，也是最重要的启发。

所以说，一个简单的验证码，背后却并不简单，我们能从中看到设计原则、设计哲学，甚至技术演化改变用户体验的过程。

在你熟悉的产品中，是否也有像验证码这样，虽然用户习以为常，却并不合逻辑，而且暗含机会的产品形态呢？不妨在留言中讲出来，我们一起讨论。

02 | 产品经理工具指南

产品经理在日常工作中会用到大量的软件工具，每种工具都有它适合的场景。所谓“工欲善其事，必先利其器”，恰当地选择不同的工具，对产品经理来说非常重要。每种工具的背后也对应着产品经理相应的技能以及思考。

今天我就跟你分享一些我在工作中常用或常见的软件工具，以及我的一些思考。

纸笔 + Scanner Pro

选择用纸笔主要有两个原因，一是有沉浸感，注意力比较容易聚焦。纸和笔像是身体的一部分，不需要用额外的精力考虑怎样使用，可以把所有的精力放到内容本身；二是无需过度关注细节，纸的面积有限，而且笔头通常比较粗，所以在画图的时候不会被细节问题牵扯精力，可以把注意力放到产品逻辑骨架上。

用手绘的方式做早期线框图还有个好处。它横不平竖不直，形式上足够随意，不会限制和误导设计师后期对页面的重新布局和设计。有时候即便是用软件画产品线框图，也会用素描风格，就是为了避免过早在设计上有所倾向。

另外，我还有个比较主观的建议，推荐大家可以尝试用铅笔。我每次削铅笔的时候都特别有仪式感，好像暗示自己接下来就要进入一个思考和工作的状态；而且铅笔划过纸面的声音比钢笔更舒适，铅笔还可以通过力度和角度调节笔划粗细和深浅。还可以买一堆彩色的铅笔，画一出喧闹舞台剧。

纸面的原型或流程画好之后，最好可以扫描存档。我平时会使用 Scanner Pro，这是一款手机扫描工具，可以识别纸张或白板的角度，提高内容的对比度，生成 PDF 或者图片，效果跟扫描仪基本一致。类似的工具有很多，比如印象笔记、扫描全能王之类，大家可以挑一个趁手的使用。

手绘稿可以高效地确定方向和抓住创意，但一旦进入后期，整个业务流程便清晰、庞杂起来。这个阶段，还是要正儿八经画图，因为扫描稿很难被频繁修改，不方便传播，也会显得不够正式。这时候，我们就需要用到原型工具和流程图工具。

原型工具

Axure/Keynote/OmniGraffle/Sketch/ 墨刀 /POP 等

我最常用的工具是 OmniGraffle（Mac），它的功能强大，组件众多，产品原型和逻辑、流程图都可以胜任，不过只能做静态。它的价格确实不便宜，不过，考虑到是吃饭的家伙，还是忍痛剁手了。

用 OmniGraffle 的话，你需要尽量记住快捷键，这样效率提升就会很明显。另外就是广泛地收集各种各样的组件库，用 OmniGraffle Stencils/OmniGraffle Templates 做关键词去搜，很多资源可以用，千万不要自己憋着画，这样会太浪费时间。

Axure 一度是最流行的原型制作工具，它基于动态面板和变量功能可以做出动态 Demo，如果多花点精力更是能把 Demo 做得几乎乱真。虽然横跨 Windows 和 Mac 两大平台，它的价格实在不菲（大概比 OmniGraffle 贵十倍），不过拥护者众多，所以也是产品经理简历上被提及最多的技能。

我先前曾用过 Axure 一段时间，当时可谓是沉迷其中难以自拔，后来发现自己将越来越多的精力放在把 Demo 做得更逼真、更动态上了，这一点实在有些舍本逐末的意味。后来刚好换了一份工作，公司没有买许可证，自己买又舍不得，所以一咬牙就戒了，守着 OmniGraffle 天荒地老。

如果你用 Axure，我觉得，你有必要学会这套动态机制的用法，但需要注意一点，不要像我曾经那样深陷其中。有可能你花一下午在 Axure 里做一个精细的动效，人家工程师两行代码就搞定了，这不是你的活儿，要记得适可而止。

后来有段时间，好像是从硅谷传过来用 Keynote 做动态原型的方法。具体方法就是把幻灯片尺寸设置成手机屏幕大小，然后摆放元素，通过点击元素跳转，串起整个使用流程。

因为 Keynote 可以直接使用的组件很多，目前又有了图层视图，再加上是苹果免费的 App，所以还真是挺适合做原型的。我用过一次，它没有太复杂的布局和流程，用来确实挺顺手，而且做演示也很方便（毕竟 Keynote 是专门做演示的工具），大家也可以尝试。

Sketch 是近几年开始流行起来的产品设计工具。这种工具已经不止可以做原型了，甚至可以直接输出视觉稿。Sketch 的生态很完整，教程够多，各种插件和组件也非常丰富，比如可以用插件来直接在输出图上做标注等。

我们创业初期那会儿，没有设计师，就是产品经理直接用 Sketch 出图，前端工程师拿来就切了上线，基本也能凑合看。

Sketch 是订阅制，一年几百块，如果作为产品设计的主力工具，这并不算贵，可以考虑。和 OmniGraffle 一样，如果用 Sketch ，一定也要记得多去研究组件和插件，不要吝啬花钱，买模板能极大地提高工作效率。

还有两个值得提及的工具，一个是国产的墨刀，另一个是轻量级的手机应用 POP。这两款工具都非常适合做移动应用的前期架构和流程设计，效率很高。

墨刀做出的原型可以在各端做动态演示，而且完成的作品可以存储在云端，不用发邮件就能保持版本同步。POP 则是直接拍照，通过设置热区来串起使用流程，适合在纸上画好原型之后做一些交互流转路径，一般也用于早期。

除了上述的工具之外，还有很多做原型的应用。比如 Origami、Justinmind、Figma ，这几个都算比较知名，但我用过之后觉得 Origami 和 Justinmind 都有点难上手。

大半年前，我看到几篇报道说 Figma 要凭借强大的团队协作功能替代 Sketch，还可以直接导入 Sketch 的模板，但因为 Figma 是基于 Web 的，我试了一会儿卡到吐血，默默地就退了。

这些工具的对比和评测介绍特别多，我倒觉得其实都大同小异，大家没有必要在工具中花费太多精力。选一两款自己拿手的，作为主力工具使用，同时可以经常试用一下新出来的工具，大概有个了解即可，一定不要被工具限制或捆绑。

还有要提醒的就是不要自己对着菜单摸索，而是花点时间看几个教程，充分地了解工具的能力，这么做可以大幅度提高工作效率。但千万不要花过多的精力去研究工具，工具玩得再溜也不可能成为产品专家。

思维导图

MindManager/MindNode/XMind

产品经理经常需要结构化拆解一些思考，很多人会用到思维导图。思维导图是一种很好的结构化发散思维的框架。你可以天马行空地想，然后对这些想法聚类、连接。我主要会把思维导图用在产品设计和项目的前期，用做详细分析前的收集工作，通常是为了保证整体逻辑的完整和穷尽。

制作思维导图工具很多，比如 OmniGraffle、Keynote 都可以胜任，甚至 Sketch 也可以；但术业有专攻，专门的思维导图工具会有很多快捷操作。比如，回车键是在同一级上加入新节点，Tab 键是在下一级加入新节点等等。

熟知快捷操作可以让精力更多地停留在思维和图本身，而不是经常被画图动作打断。这也是工具的本质：工具应当与人融为一体，让使用者意识不到它的存在，得以全心全意聚焦于目标本身。

我在用 Windows 的时候用过 MindManager，在 Mac 上用的是 MindNode，这两种大同小异。我觉得思维导图工具比较关键的一点是：节点布局蠢不蠢。某些思维导图工具自作聪明，非要自动布局，有时候手动排了半天觉得布局上合理了，结果多加一个节点，又被工具彻底打乱掉了，这种情况总会让人气得挠墙。

MindNode 基本不太会出现这样的问题，而且它的样子简洁好看，但是用 MindNode 不太自由，不能很随意地添加浮动的节点。

这一点 XMind 做得好一些，而且 XMind 模板众多，还免费，所以我通常都会优先推荐 XMind。不过我对 XMind 之类的跨平台应用总是印象不太好，尤其是这种基于 Eclipse 的结构和样式，一看到界面和布局就让人想直接下班，可能我还是比较适合用纸和笔吧。

UML 图

StarUML/Visio/LucidChart/ProcessOn

UML 是随着面向对象兴起的，主要还是应用在技术场景，但 UML 中的很多语法非常适合产品经理做概念模型、流程、状态设计等；所以产品经理应当掌握 UML 的基本概念，并应用在产品设计中（将来我们会有文章专门讲这个）。

早在用 Windows 的年代，我最喜欢用的 UML 工具就是 StarUML，因为足够轻巧，组件丰富使用简单，后来换到 Mac 平台，再也没找到如此简洁好用的 UML 工具。大部分工具都太重了，动辄就要做一个完整的 OOD 工具，不适合产品经理（后来 StarUML 也发布了 Mac 版，试了一下，已经变得非常重了，很失望）。

另一个 Windows 下常用的制图工具是 Office 套件中的 Visio，使用体验和图形的样式都特别 Windows，算是中规中矩吧。但要我说，还不如用 PowerPoint 画，或许还能好看一点。

Mac 下的各种做 UML 的工具也很多。我用得最习惯的还是 OmniGraffle，尤其在熟悉了一些基本的快捷键之后，更是很难更换。我尝试过一些替代性的工具，但如果这些工具没有什么特别抓人的特性，基本用几次就退回 OmniGraffle 了。习惯确实是个很可怕的东西。

另外，也有基于 Web 的轻量级流程图工具，比如 LucidChart 和国内的 ProcessOn 等等，这些工具都有在线协作的功能，有时候应急画个流程图也很方便。

总结

熟练地使用工具是成为产品经理的必要条件，但使用工具本身并不是目的，工具只是通向目的的路径。

画家之所以伟大是因为画出了伟大的作品，而不是因为他能够熟练使用各种型号的画笔。楼下理发店的 Tom 和 Kevin 之所以能升总监，也是因为他们能给人剪好头发，而不是因为剪子玩儿得溜。工具是为我们服务的，不要成为它的奴隶。

我们今天从纸和笔开始，介绍了产品设计过程中常用的一些应用工具，说到了产品原型、思维导图、UML 图的制作工具。

产品经理日常工作中，其实还会用到项目管理工具、文档管理工具、沟通管理工具等，限于时间和篇幅，这一次我就不展开说了。

你有没有对这些工具的独门使用心得，或者有什么工具特别希望介绍给我，欢迎留言分享讨论，互通有无，多谢啦。

!

戳此获取你的专属海报

03 | 产品案例分析·Trigraphy的设计哲学

Trigraphy 是一款图片处理应用。它不同于美图秀秀那种传统意义上的图片应用，没有磨皮或者美白瘦脸之类的效果，而更像是一个艺术工具。它会把照片变得强烈的风格化，加上很多艺术的元素，看起来更像是一个艺术作品。

Trigraphy 值得分享的产品设计方法和原则共有三点。

第一点：利用设计，来管理用户对于进度的认知

打开 Trigraphy，启动屏上除了 Logo 之外下面还有三个框，这是占位符。当应用完全打开之后，可以看到这三个格子里面填充了本地的图片。

看起来，结构已预先在启动时完成加载了，第二步才把这些内容加载到结构中，而实际上，启动屏上三个框是画出来的。对于一个 App 来说，点击它的图标打开应用开始加载，在完成加载之前，用户都没有办法参与。加载的过程究竟需要多长时间，用户没办法预期，这个过程对用户来说是失控的。

通过以上的设计，加上一些看起来是加载过程的反馈，这就管理了用户对于加载进度的认知。

举一反三，在所有产品设计的流程里面，我们都要去思考：如何保持对用户的反馈，让用户对系统有掌控感。

第二点：如何将两个目的不同的页面更顺滑地连接起来

打开 Trigraphy 之后，界面上有一张大的图片，下面可以看到本地的相册。这个页面的主界面像是一个画板，底下的照片是用户准备处理的素材，好像是用户调色盘一样，这是典型的工具操作页面。

这时，如果向上滑动这张照片，下面的部分会收起来，整个页面上变成一个图片的内容流，上面是各种用 Trigraphy 处理过的照片。也就是说，通过这样的操作把原来的工具操作页面，变成了一个信息流结构。

这是一个很聪明的交互设计，通过一个动效将两个页面的元素平滑地连接在一起，就避免了生硬的页面切换。

第三点：通过一个随机效果设计去区分不同级别的用户

在用 Trigraphy 处理图片的过程中，可以看到有几个不同的艺术效果可以选择，每个艺术效果下面都有一些对应的参数，用户可以自行调整。每个艺术效果的图片上也都有一个筛子，当用户点击时，应用会自动帮用户选择一个参数组合。

全新的用户进入应用后，通过点击筛子，可以立竿见影地看到这个 App 可以做什么，而无需费心调试参数。

当新用户不断按这个筛子，去随机调整参数的时候，会对应用效果有一个比较清楚的预期。此外，这个操作还会勾起用户进一步探索更高级参数设置方法的欲望。

平时在设计用户体验的时候，产品经理需要去注意区分不同级别的用户，不同的用户对 App 流程和功能的了解是不一样的。产品设计最好可以帮助那些第一次使用这个 App 的用户设计一个门槛非常低，可以直接上手的功能通路。

!

戳此获取你的专属海报

04 | 如何当好AI时代的产品经理？（学习篇）

“唯一能持久的竞争优势是胜过竞争对手的学习能力。”——盖亚斯

在如今的科技行业中，人工智能的普及已成显著趋势，资本布局初具规模，从业者的梯队也逐渐形成。可以预见的一点是：在接下来相当长的一段时间内，人工智能会渗透到整个互联网行业中，成为业界标配。

这种规模的技术变革，很可能会改变游戏规则，从而产生大量的新机会。作为互联网从业者，我们应该想办法跟上节奏，不要浪费科技浪潮带来的红利。

目前，人工智能还是一个学术密集型以及技术密集型的领域，其中最耀眼的角色当属研究人员和工程师。这样的背景下，大量的资讯和材料都指向了工程师受众。那么，对于产品经理来说，如何在这个领域中调整自己的认知和状态，跟上发展的节奏呢？

今天，我会和你介绍一下，我自己学习人工智能相关知识的方法和过程，下一篇文章我会结合工作中的实践总结一些思考，以期达到抛砖引玉的效果，希望能给你带来启发。

在加入无码科技之前，我对人工智能基本是陌生的，对于机器学习、深度学习之类的概念半生半熟。于是，作为产品经理，我面临的第一个问题就是：要不要学算法。

第一个问题：AI 时代的产品经理，要不要学算法

在过去的时代里，技术体系相对成熟，技术的发展和迭代主要集中在工程层面。对产品经理来说，有很多手段可以了解技术的能力和边界，比如移动时代到了，高强度用个百八十款 App，这个东西能做什么大概就心里有数了；在这个基础上，再去补一些浅显的相关介绍，请工程师吃几顿饭，基本就可以做产品设计和可行性判断了。

然而，在人工智能时代，很多手段失效了，比如，我们想通过使用产品的方式去了解人工智能，我们能干什么呢，是跟 AlphaGo 下棋还是跟 Siri 唠嗑？

这些都没什么用，原因是至少在当前的阶段，人工智能的能力大都隐藏在我们能感知到的功能之下，我们很难从场景出发，理解内部机制，获得认知。

在这样的前提下，我认为，想要做人工智能的产品经理是必须要了解算法的。那么，这就引出了接下来的一个问题：怎么学算法？

第二个问题：产品经理怎么学算法

我们先假设产品经理没有很强的数学和工程背景（当然，如果有更好，但谁忍心给产品经理提这么多要求呢），这就需要给自己理性地设置学习目标，调整学习心态。

首先，目前能在网上查到的大部分人工智能学习材料和书，对于产品经理来说，都没有必要读懂，也很难完全读懂。

大部分的算法介绍都涉及数学原理和实现方法，作者在描述中会特意省略大量的背景知识介绍，因为已经默认读者知道这些学术常识。我们在阅读这些材料时，经常会看到类似“显而易见可以得到 XXX 结论”的描述，这就让我们做产品经理的一头雾水，很难理解书中显而的是哪门子易见。

那怎么学呢？我的建议是：从视频开始。

目前行业中最受欢迎的视频是吴恩达教授（Andrew Ng）在 Coursera 上的机器学习教程，你可以在网易公开课上找到带中文字幕的版本。这一教程深入浅出介绍了机器学习的分类和方法。吴教授是一个喜欢板书的老师，所以整个过程非常有引导性，消化起来不是特别难。

不过，我在这里更想推荐你的是台大李宏毅教授的课程。李教授的课程很轻松，他经常会选择生活化、不枯燥的案例娓娓道来（比如在深度学习课程里，就用了宠物小精灵举例子）；课程的内容也比较新，会结合最新技术讲解；又是用中文授课，所以不存在语言上的理解难度；对数学基础的要求不是特别高（当然不可能完全没有），涉及公式的推导也讲解得很细致。

不论哪个视频，初看的过程确实还是很痛苦的，因为会不时碰到一些确实听不懂的内容。不要担心，先囫囵吞枣，坚持过去。随着后续不断地接触、学习和实践，之前那些听不懂或不理解的内容，会在某个时刻突然贯通。

看完视频，你基本可以对人工智能有个大体的认识，再趁热打铁读些机器学习相关的书，这样会对巩固知识更有帮助。这里就不具体推荐读什么书了，不过可以建议你一次多买几本，交叉阅读，效率更高。

有了视频课程的基础，这时你再去读书已经不像看外星文字了，通过读书这一步，可以进一步强化对先前概念的了解。当然，如果感觉视频读完之后不需要强化，你也可以跳过这一步，以后回来再看书。

在这之后，你就可以开始在网上大量地阅读各种与实践相关的文章了（建议中英文并重，英文材料有时更细致一些）。这时整个领域概念都已经在你脑海中了，你基本不会被文章中的关键词或背景知识绊住，当遇到数学推导时，还是老规矩，可以跳过去，不要沮丧，谁让我们是产品经理呢。

读文章的过程中，你可能会遇到一些感兴趣的应用领域或学术方向，这时建议你读一点论文。读论文听起来很难，不过我们已经做好了读不懂也很正常的心理准备，所以不要有畏难的情绪。

那么说如何从网上的文章中抓出关键领域呢？

读论文的时候，我们可以先读综述。综述的意思是综合介绍整个行业中对某个学术问题的研究发展现状，搜索“关键词 + 综述”或者“关键词 +Review”就可以。比如我想了解命名实体识别这个主题，就搜“命名实体识别 综述”或“NER Review”。

这时候不要太贪高级，非要看顶级会议或期刊上发表的论文，可能一些国内高校学生的综述就有很丰富的信息量，因为他们写论文需要凑字数，所以会做大量文献收集和阅读工作，这样就节省了我们自己的检索时间。

综述中会有很多针对同一主题的方法罗列和发展轨迹，也会包括每种方法的利弊和特点，针对你感兴趣的方法，可以从综述追到具体论文再做详细地研究。对于产品经理来说，读论文最重要的一点是点到为止，不要太求甚解。如果遇到不懂的，也可以跳过去换一篇看，千万不要死磕。

进展到这一步后，后面继续怎么学，学什么，你完全可以自己做一个判断和规划了。建议你可以开始关注一些前沿的东西，比如去听一些演讲，不论是学界还是工业界，只要了解整个行业的动态，大部分演讲你就可以听懂半数以上的内容了。

第三个问题：要不要真的写程序

还有一个问题，是产品经理要不要真的尝试写一点简单的机器学习代码。我的建议是，如果你之前就有工程能力，就尝试着写一点；如果完全没有相关背景，不写也罢，别给自己添堵。

如果要写，千万不要写具体的算法实现。比如你打算从头开始写一个支持向量机，或者写一个神经网络，纯粹浪费时间。直接调用一些成熟的框架，比如用 Scikit-Learn 跑个聚类，或者用哈工大、斯坦福的 NLP 框架跑个 NER 看看结果。如果研究深度学习，TensorFlow 里面有个识别手写数字的工程，直接就可以搭着跑起来，你可以动一动参数，找找感觉。

但如果没有工程能力，你的大量时间可能会花在跟机器学习完全不相干的事情上，比如我当时就遭遇了 Python 2 和 Python 3 的不兼容问题，还要自己处理各种数据，浪费好多无谓的时间。这时一定要去求助工程师，让他们把算法跑好，你拷过来直接看结果就可以了。

比如当时我们做 Word2Vec，我们的工程师看我可怜，花了十几分钟直接把训练好的模型拷给我，我只要去用两三行代码去加载模型看数据结果即可，比如探索各种词之间的距离等等，很容易就能直观判断出这个算法可能存在的产品化空间。

另外，有很多用图和动画演示算法过程的产品和网站，而且机器学习算法可视化的研究发展得也挺快；说不定用不了多久，我们不需要写真的代码，就可以用更简单的方式去直观地感受和理解算法过程和结果。

总之，产品经理与工程师最大的差异就是：我们不需要写程序。我们的核心价值也不在这里，所以我们要掌握的，不是细节和实现，而是要明白每种算法背后的原理、机制和边界。只有这样，我们才能跟工程师站到同一个话语空间中，去实际推进具体的产品工作。

回顾一下今天的内容，我从人工智能的特性出发，提到产品经理一定要了解算法；又介绍了从视频到书，再到文章和文献，这样循序渐进的学习过程；最后建议大家量力而行，通过写实验代码或其他方式去进行算法的实践。

下一篇文章，我会结合具体的工作，跟你分享一些人工智能产品经理实践中的思考。

你是否已经开始学习人工智能了呢？有没有遇到难以逾越的障碍，或有没有什么值得分享的学习经验？欢迎留言，我们一起讨论。

（据说，极客时间会在下周开设人工智能基础课程专栏，我们可以期待一下。）

05 | 如何当好AI时代的产品经理？（实践篇）

“纸上得来终觉浅，绝知此事要躬行。”——陆游

上篇文章，我讲到了如何学习成为一个 AI 时代的产品经理，这篇文章，我想结合我自己的工作，跟你分享一些我在做人工智能相关产品时的实践和思考。我进这一行的时间其实不长，而且目前的主要工作都集中在 NLP 领域，所以难免会有一些局限性，希望你批判地听。

1. 产品与算法的结合粒度要小

产品经理应当把大颗粒的整体性领域算法拆成小颗粒的算法单元，并在此基础上寻找产品化可能。这句话的意思是说，我们不能给算法团队提出一个很大的领域型需求，然后就坐等算法的突破，产品经理应当更小粒度地看待每个具体算法过程和环节，并评估是否有能够被产品化的成果。

比如，我们不能要求算法团队交付一个“聊天机器人”，这个需求粒度太大了，彻底完成会受制于各种因素，更是一个长期的过程。产品经理应该深入到领域内，比如看到自然语言理解（NLU），甚至看到其中本体库搭建和句子的语法树等等，可能部分完成的本体库已经可以包装为一个初级的人机交互引导产品。

我们在无码科技做 Readhub.me 时，产品经理会尽量避免提出像实现命名实体识别（NER）或实现信息抽取（IE）之类，这样大而化之的需求；而是尽量参与到算法过程中，分步去看过程产出。

比如命名实体识别过程中我们需要分词，分词作为一个中间算法，是否可以被直接产品化；再比如信息抽取需要先找到大信息量的文本片段，这个过程的产出，是否可以作为文章摘要或文本标签等等。

过去产品和技术泾渭分明，但在 AI 时代，我认为这个界限应该被打破，产品经理要融入到技术过程中去，不止关注需求，更要关注供给，这样才能做出真正的好产品。

2. 要重视工程的力量

当我们说人工智能的时候，总是希望算法可以解决所有问题，给出一个干净而准确的结果。吴恩达教授在去年神经信息处理系统大会（NIPS）上也提到深度学习会向端到端的方向发展。

这句话什么意思呢？

就是说，比如我做一个语音交互的机器人，过去的思路可能是人说话，先经过语音识别的算法变成文字，然后再用自然语言处理的过程去理解这些文字的意图，最后做出反应；而端到端的思路是直接把输入，也就是人的说话声音灌到算法盒子里，算法输出的直接就是最终的反应，不去编排中间过程。

但是，完全端到端在工业界有效程度没那么高，我们还是需要大量的工程工作去对算法模块做衔接，对算法的输入输出做清洗和筛选。我们不能在工业界套用学界的做事方式和标准，比如算法能做到 63 分，这时我们继续拼命优化算法，努力提升到 65 分，这就不如找个皮实一点的 60 分的算法，加上工程手段，或许可以快速做到 70 分甚至更高。

工程至少可以在三个方面快速提高产品的价值分值，一是通过规则在算法的基础上对输入和输出数据做筛选和过滤（很多时候体现为大量的正则表达式）；二是通过工程帮助算法做降维，比如做人脸识别，我们不用把摄像头拍下的整张图片送进神经网络，而是通过工程的方法把图片中的脸截出来并且特征化之后再往算法里送；三是协助算法的训练，比如做手写数字识别，样本量不够的情况下，可以用工程的方法添加旋转和噪点，生成一些新的训练数据。

3. 利用产品最大化算法和工程的产出结果

产品经理的职责是用产品为用户创造价值，至于这个价值有多少分来自算法，其实并不是成功的核心（除非你是做纯算法产品，比如一些对外提供算法接口的纯技术性公司）。刚才我们提到可能算法做到 60 分，加上工程可以做到 70 分，而一个常见的问题是，产品经理将一个 70 分的能力用到了 90 分或者 50 分的场景中，结果是造成用户的失落或技术能力的浪费。

比如，我们都知道自动驾驶有几个不同的级别，从完全不能自动化的 L0 到完全自动驾驶的 L5。如果现在我们的技术做到了 L4，非常牛了，这个级别下，大部分情况下都可以达到完全自动驾驶。

结果产品经理在此基础上，做了一个没有方向盘和窗户的产品，用户吃着火锅唱着歌把车开到村里，结果在田间地头，车翻了；又或者，产品经理做了一个传统的汽车模式，有方向盘有档把，还需要人来操作，完全没有把 L4 的技术能力用上，浪费了技术的输出。

所以说， AI 时代的产品经理应该非常了解算法的能力边界，并设计出恰如其分的产品，同时也要管理好用户的期望值，既不让用户觉得失落，也要发挥算法的最大价值。

4. 做好数据规划

人工智能产品经理还有一个非常重要的职责，就是规划、收集以及组织算法所需要的数据。如何保证训练、测试集中的数据特性分布和最终场景中的数据一致；如何获取足量的数据，并对它们进行低成本高效率的标注；用什么样的方式清洗数据，甚至基于数据做出统计学分析，为算法提供参考，这一切内容都需要产品经理去完成。

业内有一种说法是：当前的人工智能效果，2 分靠算法，8 分靠数据（剩下的 90 分靠运气，开玩笑的）。尤其是大量的深度学习应用，对数据的质和量提出了很高的要求。

产品经理应该要理解算法的数据输入要求和未来的算法应用场景，找到合适的数据源，合理合法地把这些数据收集下来，清洗干净；并有规划地划分开发、训练和测试集，以保证数据价值的最大化。

当然这个过程不能单靠产品经理一个人，需要有配合的工程团队一起。在无码科技，我们有一个兄弟算是半个全栈工程师，专门跟产品经理配合做这个事情，他能写脚本、能做数据、还懂业务，但愿你也能遇到这样的特种部队型选手。

另外产品经理还应当想办法在业务中设计数据的闭环，通过产品的持续运转，不断生成更多数据提供给算法做训练。目前。大部分的训练过程还是离线的，但如果未来在线学习持续发展，通过这样的业务流程设计，就可以做到在线算法迭代更新。

最后还有一个经验是，盲目扩大数据量并不总是有用的，如果数据的多样性得不到保证，扩大数据规模对算法结果没有太大帮助，甚至如果数据特性分布出现问题导致训练数据有偏，还可能会造成算法的过度拟合和表现下降。

5. 去完美主义，理解算法的不确定性

从某种意义上说，机器学习的不确定性是必然的，它跟传统的面向流程和规则的思路截然不同，在这样的框架下，就需要转变产品设计的思路，摒除完美主义，利用产品机制去消化算法带来的不确定性。

比如，机器学习用在反欺诈或垃圾邮件监测上，就是存在概率的。一封邮件是否是垃圾邮件，在算法完成推理前（尤其是深度学习），即便算法的作者恐怕也无法给出准确的预测。

算法有可能会错判和漏判，这都是产品经理需要理解和考虑的场景，并且要去通过产品设计去消化它。比如反欺诈要准备申诉的流程和入口，垃圾邮件可能需要提醒机制和独立的文件夹等等。

除此之外，我们评价一个算法有效性的方式，也要从局部转向宏观，不能通过一条数据的推理结果去评价一个算法。

有时算法迭代升级，可能整体效果更好了，但单看某一条具体的测试数据，却可能比原来糟糕。比如我们做命名实体识别，算法升级之后，在测试集中跑出来的 F 值更高了，但可能某一条升级之前能够正确识别的语料在升级之后却不能识别了。

这是很正常的现象，尽管有点反直觉，但我们必须要把思维模式转变过来。

总结

随着这个领域的实践和积累，我越来越相信人工智能的发展一定会给这个行业带来颠覆性的变化，就如同 08 年左右的移动，从最初的自成领域，到如今渗透至所有领域之中。我认为人工智能也是一样。

现在，我们看人工智能觉得它只代表智能音箱、智能助理、人脸识别、下棋之类相对独立的应用场景，但在不远的将来，它一定会被打散，渗透到各种各样的应用和场景中，成为新的基础设施，作为产品经理，你不要错过这一波机会。

回顾一下我今天的五点思考。

第一点是产品经理要能够深入理解小粒度的算法，并将其产品化；第二点要重视工程的力量，不要追求完全纯净的算法输出；第三点是利用产品设计，最大化算法和工程的产出；第四点是提到人工智能时代的产品经理一个特殊的职责，就是对数据的规划；最后第五点我说到机器学习算法带来的思维模式变化。

你有没有在这个行业中的实践经验可以分享呢，或者今天提到的经验对你有没有什么启发？欢迎留言跟我分享或交流，谢谢。

06 | 产品案例分析 · The Guardian的文本之美

（视频较大，请稍待加载）

传统的纸媒应用主要依靠大量的高质量内容取胜，在应用设计和信息架构上难免会臃肿复杂，而卫报客户端最近在设计和体验上的更新却让人非常惊喜。

第一点，卡片设计

卡片本身是一个消化能力较强的设计形式，它可以将不同类型的信息比较整齐地排布在一起。

在卫报客户端首页上，你可以看到有很多不同类型的卡片组合排列。

首先有三种标准卡片。第一种是焦点图组合卡片，有图、有标题，下面还有一些可以横向滑动的卡片元素。第二种小型图的卡片，这种卡片尺寸较小，一行可以放置多个。第三种是纯字的卡片，卡片利用文字的颜色、底色和 Icon 区分不同的样式。

这样的设计之下，即便有大量的文字，整体版面看起来也并不死板。

除了标准卡片还有特制化卡片。这种卡片除了文字或者图片之外，会根据卡片具体内容的模板做出特制化的设计。特质化卡片的设计优点是：虽然信息的类型各异，却能够被卡片系统地整合起来，既规范美观，又不影响内容的形式的丰富性。

在产品设计中，当不同类型与内容的信息需要在同样的架构下展示时，使用卡片可以规范整体的页面版式，使之整齐美观。与此同时，卡片设计也有自己的弊端，你需要根据不同的产品做出最佳的调整。

第二点，文章中的扩展阅读

卫报客户端在内容的扩展阅读中也做出了独特的设计，当文中涉及一些延伸阅读的时候，文章里会嵌入像组件一样的东西，帮助用户去理解它的上下文，获取更多的详细信息。

比如，你在阅读一篇文章的同时，可以查看关于某一话题的展开报道，还可以查看到一些常用的问答，在一些文章中，甚至可以直接嵌入 Twitter 的推文。这样一系列的动作会让文章的体验丰富很多，与现实世界的连接也更加鲜活。

在产品设计上，产品经理也可以参考这样的一种方式：以一篇文章为起点，去串连起所有的上下文和背景信息。这样的设计优点可以让读者在一篇文章中获得沉浸阅读，并能够找到更多感兴趣的相关文章。

第三点，手势导航设计

第一个场景：打开列表页后，点击进入一篇文章，如果我们将手指放在屏幕中间向左或向右滑，这样的操作可以切换不同的文章查看详情；如果我们将手指从边缘开始往右划，页面会回到列表页。

从屏幕中间滑和边缘滑动，效果是截然不同的，这是一个非常大胆的设计，优点和缺点都很有争议。

第二个场景：当从一篇文章的链接中跳转到另一篇文章时，如果我们把手指按在中间向左滑的时候，并不会出现更多文章详情跳转；而将手指向右滑的时候，导航抽屉会被打开，你可以从抽屉上定位到后面或者其他类目。

这样的设计十分巧妙，当用户以某篇文章为起点进行探索的时侯常常会脱离整体的信息架构。这时用户是迷失在整个架构里面的，所以当我们在右滑的时候，系统会把导航展示给用户。让用户快速找到回家的路。

手势导航的不同是一个非常大胆的设计。因为它造成了一个应用中同样手势的不同反应，也许这样的设计会出现不稳定和混乱的感觉，但对于沉浸阅读来说，它或许又是一个十分优秀的交互设计。

这种设计是完全根据用户路径去判断场景并给出反馈。或许，你可以将这样的思路用在其他产品设计中，扬长避短。

!

戳此获取你的专属海报

07 | 关于需求变更（上）：需求背后的需求

“唯一不变的，就是变化本身。”——斯宾塞·约翰逊

每当行业中想要黑产品经理时，首个被砸下来的罪责一定是“需求变更”，仿佛需求变更是产品经理最要命的错误，我并不这么看。所谓需求变更其实很复杂，不能一概而论，今天我们就来聊聊它。

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

“需求变更”四个字有个不好的暗示，仿佛变更是来源于产品用户的需求变化。实则不然，从整个团队的角度看，需求变更多半其实是指“实现变更”。

用户的需求通常很稳定，变更是由于产品经理对用户需求的分析出现了偏差，或满足用户需求的手段发生了调整。

比如，产品经理说需要一匹更快的马，后来换成了要汽车。在这个过程中，用户的需求一直都是“更快到达目的地”，变更的是满足需求的方式。

就像“工程师用搜索技术实现了某个查询功能，后来发现索引建立有几秒钟延迟不能满足实时查询的场景需要，又改用查数据库”的道理差不多，需求没变，实现变了而已。

挖掘需求背后的需求

对于产品经理来说，挖掘“一匹更快的马”背后真实的用户动机是最重要的基本功，不要停留在用户自己提出的所谓需求上，这些需求只是真正需求的一个线索。

有句关于产品需求挖掘的名言叫作“用户不需要 1/4 英寸的钻头，他需要的是 1/4 英寸的洞。”这句话后来又被继续演绎成更多版本，比如“用户需要的也不是 1/4 英寸的洞，而是在墙上挂一幅画”，甚至是“用户不是需要画，他需要房间的格调”等等。这些听起来像抬杠的演绎，其实就是不断探索和挖掘真正需求的过程。

这就是我在工作中经常用到的“5 问法”，所谓“5 问法”，就是针对一个问题，连续以“为什么”来自问，连问 5 次，从而追究其根本原因，找到用户背后真正的动机。

这一方法是由丰田佐吉提出的，后来被用在震古烁今的丰田模式里。在需求分析的过程中，这个方法尤其好用。

比如，做公司内部的订单系统，用户提出希望为订单添加根据最近修改时间排序的支持，你不应该直接去实现，而应该问为什么。

可能用户会说，因为每天的订单量太大，审核不完，为了防止订单过期，所以要从最久远的一份开始审核。很多产品经理到这里就结束了，但这还不够，你应该继续就这个问题问下去，比如可以问为什么订单会过期，或为什么一定要审核。

这是我经历过的一个真实案例，随着不断深入挖掘，后来发现有大量的审核工作是可以自动完成的，最终我们做了一个自动审核的功能，彻底解决了这个问题。

如果没有多问几个为什么，只是把需求方或用户提出的要求当作需求列表转交给开发，这就是一个产品经理的渎职，如果又因此引发了需求变更，那么产品经理受到工程师鄙视也很合理。大部分产品经理在实习期以后，就不应该再犯这样的错误了。

除此之外，关于需求变更有一个值得注意的事实：变更通常发生在产品特性上线之前，也就是需求分析结束，开发正在进行或测试正在进行的过程中。如果项目已经发布，一般再改就叫“新需求”而不是“变更”了。

那么，究竟是什么让一个产品经理在项目开发的过程中提出变更呢？

给需求分析留出时间

举个例子，如果产品经理分析需求用了两天，然后工程师接手开发六天，开发到第二天，产品经理跑来了说：“抱歉，有个小小的变更”。

第一个可能就是分析需求的时间不够，在短时间内，产品经理的方案和逻辑没有完全想透，但为了尽快出结果，紧赶慢赶写完需求文档交给下一个阶段。

开发接手后，产品经理坐在那儿反刍的时候，怎么想怎么觉得有问题，于是提出变更。这是因为“需求分析”过程没有受到足够的重视，所以没有给足产品经理足够的时间。

据我所知，有不少项目都是先确定发布时间，然后减去测试和开发需要的时长，反过来倒逼产品经理完成需求文档的时间点。

有意思的是，很多时候这都是产品经理自愿的，因为项目发布的第一负责人通常是产品经理自己，为了上线先插自己两刀，这是行规。他很有可能在内心鼓励自己说：“晚上熬个夜，把文档出一下，用不了多久。”

没错，写个文档是用不了多久，但思考是需要时间的。在整个项目进行过程里，变更出现越早代价就会越小。

如果变更只出现在产品经理脑子里，对团队的伤害其实是最小的，如果都测试完毕，临部署上线的时候突然变更方案，基本上，团队所有的角色都要付出相应的代价。

所以，我特别建议给前期需求分析的过程留点时间和空间，让产品经理能在自己的脑子里跟自己多较较劲，把该变的都变完，交出尽可能稳定的方案。

经常看到行业里有人倡议不要打扰正在写代码的工程师，从没见过说别打扰产品经理的（只有个别好心人呼吁别打产品经理，比心）。其实他们也需要安静，需要完整的时间，因为产品经理最重要的产出不是那个方案文档，而是方案本身，生产方案也同样是一项消耗性的脑力劳动。

另外，我在过去的工作中经常建议产品经理在完成需求分析，写好需求文档之后，把文档放下来，不去想它，做一点别的事情，等个一两天，大脑从需求的情境中脱离出一点之后再重新去读自己写的文档。通常他们都会发现或大或小的问题，我们把这个过程叫作需求文档的发酵。

很多情况下，你需要将自己从需求中拽出来，换一个更冷静的状态去重新审视自己的需求分析。没有比把文档放到那里搁置几天更有效的办法了。

别忘了需求评审

还有一件重要的事情，就是建议增加需求评审。不一定是架上投影仪开大会，找几个人到茶水间聊一会儿也行。尽可能引入外力，比如用户代表、运营、开发、测试、老板等等，千万不要你好我好大家好，一片和气。

在方案交到开发阶段之前，把它挂起来先打个遍体鳞伤，否则开发到一半再变更，就只能把产品经理挂起来打个遍体鳞伤了。

我有一次中途接手别人的需求，需求评审我没有参加。然后开发兄弟们拼死拼活赶工，力保按期发布。部署上线之前，我组织各相关方做了个集中演示，结果需求方找我说其中一个核心页面有问题，要求改一下。讨论权衡再三最终还是没能扛住，决定延期。

我记得自己当时差不多是跪着去找前端团队的负责人，我说：“兄弟我对不起你…”他点着了烟半天没抽，目光看着远方，很久之后才开口，说：“二爷，没有你这么办事儿的。”那一刻我至今还记忆犹新。

事后我总结，问自己是不是不该做那次演示，先发上去再说。但后来还是说服了自己这么做是对的，因为需求分析不是我做的，我并不能很好地把握所有细节，那么把各方叫到一起做最后确认，保证在上线前把问题暴露出来，这是必要的。

虽然高压工作之后，在最后时刻出现延期非常打击团队的士气，但是没有让问题流出团队，或许也是个明智的选择。

回顾一下今天的内容，我们提到需求变更的本质是实现变更，从而引出通过不断追问挖掘需求背后需求的方法，同时建议给产品经理的需求分析留出充足的时间，最后提到了需求评审的重要性。

今天的话题并没有结束，在下次的文章中，我们会接着讨论如何利用具体的力量来提高需求评审的效率，以及如何选择变更时机等。

关于今天文章的内容，你有没有什么想要分享或讨论的？欢迎给我留言，我们一起交流。

!

戳此获取你的专属海报

08 | 关于需求变更（下） : 化变更于无形

“拥抱变化。”——阿里巴巴价值观之一

上一次的文章中，我聊到了需求变更的原因，以及通过引入需求评审来尽可能避免需求变更，并在文章的最后提到了一次并不成功的项目经历。

这次项目已经根据项目流程开过了需求评审会，却没有在这个环节暴露问题，直到临发布的最后一刻才引入了变更。那么，怎样改进需求评审才能避免未来可能的变更呢？

“具体”的力量

大部分的需求评审会都是过场，大家下面玩玩手机，产品经理在上面对着需求文档读一遍，再开开心心散会，除了浪费了时间，什么用都没有。

这里最大的问题不是参会的人员不负责任，而是需求评审时的方案不够“具体”。

我曾听说在微信团队里，不少产品在做出来之后，需要先交给张小龙上手体验一下之后才决定生死。因为只有实际使用才能作出更准确的判断，还听说有不少东西已经做出来了，但没有通过实际使用测试，所以一直压着没能发布。

我想，或许你也有同感，一个东西画在线框图上总是觉得很远，只有在指尖动一下才能有真切的体会和判断。

所以对一些关键性的特性，在资源配置合理的情况下，尽可能做一个与实际情况没太大差异的 Demo 来做评审。数据可以是假的，架构可以是假的，但看起来和用起来要尽量保真。

我记得以前有一次观摩一场游戏 Demo 制作比赛，团队在上面试玩展示，游戏角色在地图上能跑能跳，我特别不解地问旁边人：“这不都做好了吗，为啥还要参加比赛拿投资做开发？”他告诉我，虽然这看起来很完整了，其实后面都是空壳，大头还没开始呢。

在此之后，我经常提醒自己，对于重要的功能也要尽可能在前期把 Demo 做得具体。最好是动态的，让评审的人可以有真切的体验，把可能的问题都尽早暴露出来。有很多工具可以做到这一点，重一点的 Axure、轻一点的墨刀。如果实在不想学，用 PowerPoint 和 Keynote 也可以。

哪怕没有做成动态的，只是一张张截图，在评审的时候你也可以通过讲故事的方法让它变得具体。比如你可以展示一个界面，边引导大家边说：“现在我是一个从朋友圈打开 xx 的用户，我看到的页面是这个样子。”——这样代入具体场景，才能让大家产生真感觉。

变更时机的选择

如果变更在所难免，时机选择就很重要，并不是所有变更都“越早越好”，而是要平衡收益和成本。

最好的变更发生在需求分析过程中，在产品经理脑子里，变更发生多少次都没关系，基本是无害的，所以刚才说要尽可能给产品经理留出足够多的时间，让他先自己跟自己打一架，把方案尽可能想完整。

第二好的时机是在需求文档结束，工程师接手前，这是的修改可能会造成需求分析延期，但因为需求分析主要是通过脑子完成，所以这里返工的伤害并不大，需求评审也是这个作用。

在工程师接手后，情况会变得有点复杂，这时的变更就会产生实际的开发成本了，有的变更很小，比如文案之类的，随时发现随时提，提的同时记得改掉文档描述。

稍微大一点的功能，则最好在发现变更后就立即跟开发沟通，去判断合适的变更时机，有时候工程师还没有做到这一部分，那就不会产生什么额外成本，有时候工程师已经做完了，你要比对一下变更的优先级和可能带来的延期再做决定。

如果你的项目组里有专职的 QA，这时候最好也让 QA 参与进来。如果涉及流程和架构上的重大变更，更要立刻与整个项目组沟通，有可能连设计都要推翻重做，这种情况挨骂是肯定的，态度好点儿，可能可以躲一顿打。

如果项目基本完成开发，箭在弦上准备发布了，那对于变更一定要更加慎重，这时的态度是应该是能不变就不变，可以先上线，通过运营的手段稳一下线上，然后尽快迭代做修改。在这个节骨眼上发生重大变更基本就可以领盒饭走人了。

我在职业生涯里遇到一次特别大的临发布的变更，是因为不可抗力造成的。那个项目涉及一百多人，我当时头皮都是麻的，跟人说话甚至都有些口吃。

总之，原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。

让团队能消化需求变更

虽然大家本能上都讨厌需求变更，但我们永远都不可能彻底杜绝需求变更，更何况我认为有时需求变更也有积极意义。因为变更是响应变化，在互联网行业里，每天刀光剑影，瞬息万变，市场上发生的事情传递到产品和服务上，越快越好。

这个传递过程需要市场行销人员和产品经理的敏感，也需要工程师团队的宽容。如果整个团队抗拒需求变更，甚至建立流程对抗需求变更，久而久之就会越来越不敏感。

我体验过一个叫作“需求基线”的环节，就是需求确认结束以后大家签字画押，承诺绝对不变，连文档的编辑权限都封存，然后开发才接手，所有需求变更都必须审批到高管，启动一个冗长的评审程序。

这个制度导致的直接结果就是大家开始互相推诿，然后文档变得极其庞杂，效率降低，需求冻结以后，即便发现了问题和错误大家也不乐意提，就眼看着错的做出来了以后再说，整个产品线的节奏越来越慢，士气很快就磨没了。

没过多久，这些问题很快有了民间解法，产品经理和工程师在半夜的烧烤摊上把酒言欢，沟通需求变更，产品把变更的内容私下发给工程师，工程师直接改，等项目结束文档冻结解除之后再去改文档。

项目经理睁一只眼闭一只眼，工程师继续调侃这帮产品经理天天变，产品经理自嘲两句，然后咣咣请客吃夜宵，团队士气却一点点回来了。

后来大家慢慢意识到，这个本意用来限制甲乙方权责的流程不该在互联网公司中采用，也就逐渐废掉了。

产品经理脸皮虽然厚，但也是肉做的。如果整个团队都抗拒变更，一出现变更都恨不得把产品经理点了，他们也会慢慢变得保守，变得犹豫拖沓，最终伤害的是整个团队的利益。

尤其在互联网行业，变化是永恒的，你不可能规划好路线一帆风顺，你总要随时准备好用最快的速度追击或躲闪，这才是求胜的不二法门。

记得多年前，我在某次开发过程中又一次变更了需求，于是我主动找到对应开发负责人那里“自首”，我扭捏地说：“不好意思啊兄弟，又变更了。”

他抬头看了我一眼，轻描淡写地说：“正常，不怪你，还是要怪我们自己做得不够快。如果已经做完了，你这就是一个新需求，而不是变更了。”

我喜欢跟这样的硬汉合作。

到这里，我们关于需求变更的分享就结束了。大家有没有在自己的项目中遇到过需求变更，你又是如何处理的？如果重新回到那个场景中，你能不能找到更合适的解决方案？不妨在留言中一起讨论。

!

戳此获取你的专属海报

09 | 产品案例分析：Hopper的“人工智能”

传统旅行机票产品的交互方式一般会要求用户指定往返的时间或地点，在大量的航班信息中做筛选，从而获得有效的信息。

Hopper 的交互方式则截然不同，它不要求用户指定具体时间，甚至连往返地点也无需具体指定；而是希望可以通过自身大数据的分析能力和数据带来的决策引擎，为用户提供合适的旅行计划，同时帮助用户去监控和预测机票价格的变化。

Hopper 的设计非常的场景化，它所有的设计几乎都是顺着场景长出来的。

打开这款应用之后。你会看见两个卡片，上面的卡片有出发和到达地的选择，下面的卡片有个兔子，这其实是两种不同的选择机票和旅行计划的方式，针对的也是两种不同的场景。

** 首先，我们先来试用上面的模式。** 我们选择出发地是北京，到达地选择旧金山。选了出发到达之后，场景直接给出一张日历，这个日历的颜色越浅越便宜，颜色越深就会越贵，这样的设计也是方便用户查看机票价格。

当我们选择 11 月 12 日到 18 日的区间后，跳转画面出现了一只兔子，界面上显示出当前的最低价格是 3860 元人民币，并且，这只兔子在提示：你现在应该预定。底下还有一句话：这不是最好的价格，但如果你继续等，你有可能会要付更多钱。它告诉用户，机票的低谷价格已经过去了，如果有出行的需求，最好尽快预定。

这就是 Hopper 很重要的提示功能。这样的提示以一种非常自然的方式，把信息描述给用户听。整个过程像一个人在跟用户做沟通，而不是一个很生硬的机器去提示用户，并让用户从复杂的信息表格或者图表里去获取到信息。

它用人的口吻去告诉用户注意事项，再配上画面中温暖的大兔子，这样的提示方式会让用户感觉非常温暖。这是这款应用的一个很好的特点，它场景化的设计非常有人情味。

我们选一个其他时间段的机票再看一下，选择 2 月 11 日到 17 日后，当前的最低价格是 5486 元，下面有一句提示：你可以等一等，会有更便宜的价格，但一定要在 2 月 10 号之前买好票。这是 Hopper 监控这段时间，通过分析历史机票价格的变化，给出的一个建议。

这个建议依然是用人类语言自然语言描述的，不是一个非常生硬和冰冷的图表，你会感觉好像真的是一只兔子在跟你交流一样。

在提示的下面出现了三条建议。第一条建议：你可以选择更便宜的旅行时间。如果你在 12 日出发就可以省 525 元，如果你在 11 日之后的一周之内出发，最多可以省 1200 元，跟刚才的逻辑是一样的，反正你没定，我就告诉你，你改一改日期，有可能会便宜。

第二条建议：你可以选择更便宜的出发机场。从北京走，不妨从天津走，如果你从北京走改到从天津走，你就可以省 559 元。

最后一条建议：你可以选择更便宜的到达机场。也就是现在的到达机场是旧金山的机场，如果你改到另一个城市机场，可以便宜 229 元。

在用户恰好想做决定，甚至是心里刚冒出这个念头的时候，Hopper 都合适地出现提醒，并利用数据分析帮助用户做这样的决策，这是这个产品非常场景化的一种表现。

** 再来看第二种场景。** 这个场景中，用户可以作出不定项的选择。出发的日期可以不定，假期的长度也可以不定。从北京出发，去到哪里也是不定的，用户可以多选，可以随意添加很多想去玩儿的地方。比如，日本、欧洲、法国。添加之后，Hopper 会生成很多卡片，根据数据的计算，制定好出游的方案。

这种卡片设计很有意思，就好像做探索旅行的攻略一样。用户可以什么都不用拟定，甚至只有一个出行的打算，那么 Hopper 会来帮你，给出你旅行的建议。

当选定一个城市之后，这个时候会出现一个机票列表，这跟传统的机票预定 App 没有什么太大区别了，需要注意的是，在机票预定的下方，Hopper 依然在给出你提示，只不过换了一种样式，这一次，提示在列表中出现。

Hopper 永远在场景里面去理解你当前的位置，理解你当前的关注点，然后适时地去把它的一些功能嵌入在你实际的使用中，让用户觉得非常不突兀，也很吻合。

在用户选择机票的过程中，Hopper 依然持续地去推荐其他可能的选项，就算是在用户已经决定的情况下，它还是会把一些可能对用户更有利的，可能之前没有关注到的机票推荐给用户。

在选定出发和回程的机票后，在机票的确定界面上，会弹出一个熊的画面去提示：小心。下面有小字：这个航班有可能会有一些比较低的限制。

国内的一些机票预定应用在这个界面会铆足了劲，加一些搭售的选项，比如买保险，买个酒店的抵用券等等；而当 Hopper 出现一些具体限制的时候，它会很温馨地用一句话来提示。并且，这个提示非常的不突兀，它不是弹出一个框，也不是一个巨大的标红，而是用一种很卡通的，很温和的方式来给你这样的提醒。

在 Hopper 中，可以具体化看出产品经理常说的：场景是需求的灵魂，我们需要让产品和功能贴着需求与场景长出来。Hopper 所有的交互过程正是这样，每一处都是与场景相吻合，在用户想做决定的时候，恰好的出现。

谈及人工智能，我们会做很多的交互，试图让机器用人的方式去跟用户交流，去跟用户说人话。但是，事实上很多这样的产品，反倒给人一种冰冷而生硬的感觉。

反观 Hopper 这个产品，它似乎也看不到什么人工智能，但是通过处理文案，处理产品的细节，反倒把这个应用做得非常有人情味，特别温和。当你在使用 Hopper 的时候，你的感觉是在跟一个了解你“正在想什么”的人在做沟通。

在这个人工智能时代，在我们向技术去索要人情味之前，我们可能更多地需要向产品、向用户的场景去要一些人情味，这就是 Hopper 带给产品人最大的启发。

!

戳此获取你的专属海报

10 | 产品被抄袭了，怎么办？

“世界上有两种产品，一种没人用，另一种被人抄。”——邱岳

前些日子，某巨头公司被爆出利用合作之便抄袭创业团队产品，业内一时间人声鼎沸，一方面创业团队义愤填膺，纷纷声讨抄袭者的不道义，另一方面也不乏业内人士认为这只不过是公关碰瓷为了蹭流量，所谓天下文章一大抄，没什么大不了的。

身处在一个节奏快、竞争激烈的互联网行业，抄袭是个逃不开的话题。今天我就从产品经理的角度来聊聊如何应对抄袭。下一次的文章，我会换一个角度，跟你分享如何正确地从别人的产品中借鉴灵感。

如果被抄袭了，怎么办？

有人说，在中国互联网行业创业要问的第一个问题就是：如果 BAT 跟你做同样的事情，你怎么办。其实在 BAT 工作的人们也有类似的烦恼，三家巨头之间互相抄袭借鉴早已经不是什么新鲜事，甚至公司内部不同事业群之间也偶尔会因为某些事情的先来后到发生争执。

在这件事情上，外国的月亮也没有比较圆。Instagram 跟随 Snapchat 发布的 Stories，Facebook 的 Message 模仿 Houseparty，都广受诟病，众说纷纭。

那么面对被抄袭，我们该怎么办呢？

1. 摆正心态，泰然处之

发现有人抄袭你的产品时，先要摆正心态，不要暴跳如雷。被抄说明你一定做对了一些什么，不论是交互还是流程，亦或是视觉设计，运营机制等等。先行者在做出初期尝试的时候，很多东西是建立在一些假设之上的，在得到市场检验之前，没有人可以拍着胸脯保证自己做得都正确。如果业内同行开始抄你的特性，至少说明了他们对方向的认可。

另一方面，人多力量大，整个行业的从业者都用相似的方式做事情，可以更快地教育市场和建立生态。

有一张图展示了 iPhone 发布前和发布后各厂商的手机设计，可以看到 iPhone 发布前，手机的设计五彩斑斓，奇形怪状，很丰富，而 iPhone 发布后几乎所有的手机都是一块黑色方形砖头，从某种角度来说，各个手机厂商其实是身体力行帮助 iPhone 更快地确立了智能手机的标准。

就像 Sony 当年发布 Walkman，这一品牌名后来甚至演化成了品类名，所有试图抄袭 Sony 创意的厂商都逃不开 Walkman 这个名字，结果彻底奠定了 Sony 在便携式录放机领域的竞争优势。

2. 别担心，抄不走的是气质

大部分的抄袭都是界面和交互的抄袭，能抄走的是“ What ”和“ How ”，抄不走的是背后的 “ Why ”和产品的气质。我们产品的每个特性背后都应该有深入的思考，产品的气质应该是一以贯之的。

比如我们在做 Readhub.me 时，很多交互细节设计都是经过取舍的，信息流里面哪里点击展开，哪里点击跳转，这些都是具备整体性的，我们需要牺牲一部分页面访问量换取体验和信息密度的一致；后来看到有网站抄这个交互，影响了他们本身的信息密度一致性，还牺牲了流量，很可惜。

还有团队看到做内容能够产生粘性，觉着没什么难的，也跟着做内容，结果发现内容是个重运营的事情，没有相应的经验和团队，看起来都是相同的一条时间线，做出来却是截然不同的效果。

除此之外，我们还要保证自己的产品是活水，每个线上的版本永远都是中间态，是我们沿着产品规划往下走的一个节点，是我们过去的思考结果。竞争对手即便能抄走，也无法理解你背后的发展规划和逻辑。你当前的思考应该领先于产品，你清楚当前的问题在哪里，接下来应该如何调整。而抄袭者却只能等着你做出来才能跟进，永远落在身后。

所以说，没有像你一样揪头发捶桌子深入思考的抄袭者，绝不可能带走产品的气质和团队的 DNA，更带不走产品未来的持续迭代。

3. 不要将产品的护城河建在脸上

我们在产品规划设计之初，就要清楚自己的相对优势和可能的成功路径，一腔热血“打造好用的产品”未必能成功，所谓“不要将护城河建在脸上”，意思是说不要将产品的外表作为护城河，因为外表太容易被抄走了。

比如有的团队优势在于廉价获客，有的团队可能在技术上有壁垒，或者有行业资源门槛，或者有些特别偏门的优势，比如我认识的一个创业者有个神奇的技能是 ASO 做得非常厉害，别人即便抄走他的产品也抄不走他的获客效率，他做了很多应用，并从不担心别人抄袭。

所谓大公司抄死小公司的说法，也正是大公司在规模上的相对优势。如果一个产品只有基于规模优势才能长起来，那它本就应该交给有规模优势的企业去做，或者能用极快的速度在大公司反应过来之前利用巧劲儿建立规模优势或其他的壁垒。不要明知道在规模上打不过还要去硬拼，历史上基本没有靠正面硬干以弱胜强、以少胜多的故事。

作为产品经理，一定要清楚产品 Idea、产品界面和功能流程都无法成为真正的竞争壁垒，认为自己设计出了天才的界面就能立于不败之地，其实是在设计之初就将自己置于非常危险的境地，把命运放到了别人手里。

4. 做有积累效应的事情

抄袭者能抄走产品特性，却抄不走数据和用户。产品设计中一定要考虑数据的积累和用户的卷入，要设计出一套机制：让用户使用产品越多，产品对用户的价值就越大，或者使用产品的用户越多，产品的价值就越大（也被称作网络效应）。

比如买东西，大部分用户会选便宜的，所以迁移成本并不高；而淘宝通过用户的购买行为积累下买卖双方的信用记录，无形之间提高了用户的迁移成本，形成了积累效应。毫无疑问，现在即便有哪个公司一夜之间抄一个和淘宝一模一样的产品，也无法对淘宝构成任何威胁。

即时通讯应用也是一样，当你的朋友都开始使用微信的时候，会有一种无形的拉力让你开始转向微信，而随着你的加入，你的朋友们对于微信的粘度就变得更高，这便是产品的网络效应。

在产品设计中，还要尽早让用户“卷入”，也就是在产品中做出投资。比如当你的名片都印上了某个电子邮件地址，就很难再换一个电子邮箱服务提供商了。同样的道理，在某款音乐播放器中标记越多“喜爱的歌曲”，你就越离不开它。

反观打车软件，除了一些会员体系之外，似乎之前没有找到特别有效的具备积累效应的机制。前段时间看到了一些类似月票的产品，也算是向着这个方向迈进了一步。

这样的积累效应一旦建立，而且能够滚雪球一样滚起来，抄袭者便很难通过抄袭占到什么便宜了。

5. 有条不紊，不要情绪化处理

不论如何，如果抄袭者越过底线，开始直接伤害到我们的利益，我们也不能任由事态发展。在这时，保持冷静，不要情绪化很重要。

你需要找到靠谱的律师，先做好一些准备，比如整理和收集侵权的证据，去做相关的公正，以及准备相关的资质等。这里也提醒你，对一些比较核心的产品机制，能申请专利和著作权的最好尽早申请，因为专利审批需要一个比较长的周期，临时处理肯定来不及。

随后最好可以和对方直接对话沟通，消除不必要的误会，或许很多事情可以化干戈为玉帛。处理这样的争端非常花费心力，不到万不得已，不要将事态扩大。

最后如果确实不得已要开战，除了法律武器之外，也应当恰当地利用好公关渠道发声，利用舆论向抄袭者施加压力。同时别忘了很多平台方有仲裁机制，比如 App Store 和一些流行的安卓市场，或者电商网站等，都可以直接发邮件要求下架抄袭者。

总之，一定不要让愤怒冲昏头脑，只拿出一部分精力处理就可以了，互联网历史上还没有哪一家企业是通过搞死竞争对手赢得成功的，成功只有一条路径，就是赢得用户，赢得市场。盯紧你的目标，把更多的精力放到迭代产品和服务用户上，让抄袭者永远跟随你的步伐。

总结

面对抄袭，一定不要慌，也不要绝望，抄袭者总是追随者，只要我们能思考和找到我们的相对优势，在产品内设计有积累效应的产品形态和机制，保持我们自己的节奏，被抄袭没有什么可怕的。

在你的工作中，有没有经历过竞争对手的抄袭？你又是如何应对的？不妨在留言中跟大家一起讨论分享。

下一次，我会从另一个角度来聊聊如何能有效、恰当地从别人的产品中借鉴灵感，而不是不怀好意的抄袭。今天的分享就到这里，谢谢。

!

戳此获取你的专属海报

11 | 如何借鉴灵感？

"The Early Bird Catches The Worm, But The Second Mouse Gets The Cheese." ——Francis J. Kong

上一次我聊到如何应对抄袭，提到了我们需要找到相对优势，建立积累效应。这样就会让抄袭者陷入被动，盲目抄袭对于抄袭者来说非常危险。

可是在产品设计的过程中，我们却需要大量地从其他产品中获得启发，就连 Facebook 都在内部新增了一条备忘，嘱咐员工：“不要骄傲到不屑于抄袭（Dont be too proud to copy）”。今天我们就来说说：如何能在不伤害别人，也不伤害自己的基础上正确地借鉴他人产品中的灵感。

不要像素级抄袭

乔布斯在一次访谈中引用毕加索的话说：“能工抄，巧匠偷”，并表示他并不觉得借鉴别人的创意可耻。

我们在做产品设计的过程中，确实需要从各种各样的产品中吸取灵感。我一直鼓励团队中的产品经理可以大量地安装和试用应用，并且自己也是这么做的，但是，在这个过程中，应该如何把握好借鉴和抄袭之间的度呢？

在我看来最关键的就在于：杜绝像素级抄袭。大部分引起民愤的抄袭都是像素级抄袭，比如是流程、界面或文案一模一样，前些日子吵得沸沸扬扬的某抄袭事件中，被抄袭一方列出的抄袭证据中，有一项就是文案抄袭，可以看到大量文案一字不改地抄走，这么做就很不合适。

除了界面之外，直接抄代码，抄文档，都算是某种意义上的像素级抄袭，这样的抄袭背后通常都藏着懒惰和不负责任。

或许有人会反驳说，在某个场景下，界面的优化效果最终会收敛一致，比如天下所有的登录页面都几乎是像素级相似的。

诚然，形成固定模式的页面确实很容易相似，这样的相似是合理的，而且像素级抄袭个登录页面也不会对其他人造成什么伤害，因为这张页面上没有什么业务逻辑。但是，每个产品都有其核心业务或核心机制，越是核心的东西，越是具备别人有独特创意的地方，我们对待这一部分的借鉴，就应该越加谨慎和克制。

脑子里带着自己的问题

一个产品经理有没有抄袭别人，其实他自己心里很清楚。借鉴别人时，其中一个关键点就是脑子里有没有带着自己的问题。当脑海中有问题时，看到别人的方案是钥匙，可以打开自己脑子里的锁，最终内化成自己的武器库。但倘若脑海中没有问题，看到别的方案就是另一把锁，你只能把它照样搬过来，却永远无法打开它。

齐白石曾经说过的“学我者生，像我者死”便是这个道理，我们一定不能用别人的工具去解决自己的问题，而是应该研究别人的工具，体会到它的精妙之处，变成自己的工具，去解决自己的问题。

比如我们在做 Readhub.me 时，希望尽可能在不抢占信源流量的前提下提高信息消费效率。我们带着这个问题看了很多设计之后，最后在 Telegram 的 Instant View 中找到了灵感。

Instant View 通过积累大量的网站规则，理解对应网站的内容结构，从而使得用户可以在 App 中按照统一的格式快速查看目标页面中的信息。这个方案中的格式内容标准化和在当前页面快速即时反应给我们带来了启发。我们将通过算法筛选的内容利用 RSS 协议格式化后做预加载，并设计了在当前页面快速打开的阅读层，解决了此前困扰我们的问题。

这里更多的是灵感上的借鉴，而非功能和场景的照搬。

追本溯源，知其所以然

很多手机端信息流产品都有一个特性，当页面到达顶部后，如果继续向下拉页面，则会触发页面刷新。这一交互特性来自于 Twitter 的客户端 Tweetie（其开发商 Atebits 已被 Twitter 收购）。

这个特性流行起来后，越来越多架构非纵向信息流的产品也采用了这一交互方式去触发刷新。其实，这一特性并不适用于所有的场景。从用户的角度来说，一方面最好的体验应当是不需要主动刷新就可以看到最新的信息（比如股票应用或直播应用）；另一方面，因为没有纵向滚动的信息流设置，如果缺乏明确的提示，用户或许很难知道如何才能触发刷新。

如果我们可以追本溯源，找到这个下拉更新交互的源头，知道它应用在纵向信息流中，而且其实是在苹果的惯性滑动特性基础上建立的，或许就不分场景的“借鉴”这一交互方式。

跨领域、跨行业借鉴

同样的行业中通常聚集着许多思维模式和思维习惯类似的人，当我们需要借鉴灵感和启发的时候，我们应当尽量向行业外探寻，盯着同行业的产品“借鉴”也很容易陷入抄袭的漩涡中。毕竟是面对类似的用户群体，做类似的事情。

深泽直人在设计无印良品的 CD 机时借鉴了换气扇，他在自己的设计笔记中说，当拉动电源线时，碟片像扇叶一样旋转起来，音乐迎面吹来，像风拂过脸庞。

我们在做产品设计时，也应当去寻找跨越行业或领域去寻找灵感，最基本也要做到从别的领域应用中找灵感。

比如我们在做社区的过程中，不仅在社区产品中观察学习，还要诸如新闻、图片处理、音乐软件甚至游戏中吸取灵感。在音乐播放器中点击“喜欢”，可以默认加入音乐列表这个特性就曾经被我们借鉴到社区的收藏功能中。

如果视野可以再开阔一些，不止在应用中找灵感，而是可以去看各种各样的工业设计甚至更加宽泛的艺术作品。据说 Snapchat 阅后即焚功能的灵感来源于酒吧聊天，而 Twitter 的灵感，则是来自性格孤僻的杰克·多西在收听警察监控广播时，对于警察执行任务时的简单对话产生了极大兴趣。

致敬与付费

我在上家公司的时候，有一次我的主管 Fenng 叫我到他办公室，让我看一款应用，说打算把它买下来，把其中的机制引入医患问答领域。我看了一下说这个产品的 Code Base 跟我们不同，而且当时整体的业务逻辑还没有做完整。

我跟 Fenng 说：“买了也没什么太大用处，迟早要重做，给我几个人我很快就能做一个类似的。”他瞪着我说：“你去抄一个，别人怎么看你，怎么看我们？我们应该为创意付费。”

我一时哑口无言，非常惭愧。最终我们还是支付了费用，将这个产品买下来，虽然在一两个版本之后就完全重写了。

所以最后想跟大家分享的是，当你从别处借鉴产品 Idea 的时候，如果条件允许，不妨支付一些费用，不论是购买版权，还是向社区捐款。最不济也应该心存感激，在博客或产品公关稿中致以敬意。

这样把自己放在阳光下，不但光明磊落，也从根源上杜绝了恶意抄袭的倾向——毕竟恶意的抄袭不好意思拿出来晒。

总结

写到这里，在借鉴和抄袭的一线之间，我们一定要把握好度。不要不顾职业操守像素级抄袭，也不要因噎废食，闭门造车。多思考自己的问题，带着问题去透过别人的方案看背后的逻辑，把别人方案背后的方法变成自己的，而不是直接照抄。最后，要记得在条件允许的情况下，对给你带来灵感和帮助的人心存感激，表达敬意。

在你的工作中，有没有过从其他产品中借鉴灵感的经历？有没有值得分享的事情？不妨在留言中一起聊聊。谢谢，再见。

!

戳此获取你的专属海报

12 | 产品案例分析：LabRdr的设计实验

LabRdr 是一个非常精巧的新闻阅读应用，它是由卫报的移动创新实验室负责设计和研发的。它和我之前介绍的卫报客户端属于同一东家，不同的是，LabRdr 是一个完全实验性的产品。

从用户场景出发，贴着场景设计产品

在第一次使用这款应用的时候，LabRdr 会问你几个问题。第一个问题是你早晚的通勤开始时间，也就是上班时间和下班时间；第二个问题是问，你花在早晚通勤上的时间长度，你可以分别作出选择。在此之后，LabRdr 会根据你的选择，为你挑选适合你通勤长度的文章集合，在你每天早晨和晚上通勤开始的时候推送给你。

在这里，LabRdr 有一个有趣的特性，就是它的文章同步是在后台进行的。这应对的是一个什么样的场景呢：我们出门坐地铁或者其他交通工具，手机有可能会没有信号。这时我们一般会在上地铁之前先打开离线一些数据，然后在地铁上读；LabRdr 在后台同步的功能就会离线下载，用户也就无需打开应用手动下载。

这是 LabRdr 整个的设计起点。就像我在之前分享 Hopper 的时候提到，越来越多的产品在改变自己的设计起点，产品不再从我们有什么出发，而是从用户需要和用户场景出发。LabRdr 就是这样，它不是将大量的新闻分类排序，和盘托出摆在用户面前；而是去理解用户阅读新闻的场景，从场景里面长出功能。

我们可以看到 Labrdr 上的文章并不会一直保留。当一天过去后，这一天文章集合就会消失不见，这跟传统的新闻客户端永无止境拉不到头的时间线形成了鲜明的对比。

这个设计跟我们做的 Readhub 有些类似，我们不希望对用户来说，信息是无尽的，它只会让用户消耗更多无意义的时间，并陷入到信息焦虑中。

用户收集数据的透明化处理

除了场景化的新闻阅读功能之外，LabRdr 还有另一个我认为非常出色的处理，它会将用户数据的收集透明化。

我们刚才提到 Labrdr 会根据用户的喜好给用户推荐新闻，这类功能又叫个性化推荐，很多的新闻客户端都能做到。但以往的个性推荐算法通常是个黑箱。有时候我们误点了一些文章，导致算法认为我们喜欢这样的主题，然后时间线里头不断会出现更多此类文章。进而又增加了误点的风险。最后，误点越来越多，推荐也越来越飘逸。

Labrdr 会将你阅读过的所有文章，按类别放在日志里；并且明确地告诉你，这是根据这些数据来对你的喜好进行猜测的。这种将逻辑和规则开放给用户的设计，会让用户有控制感和安全感。

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

很多应用并没有讲清楚自己为什么需要请求推送权限，只要一打开应用，它们就要求用户开启这款应用的通知推送设置，这样的做法其实会让转化率会受到很大的影响，而 Labrdr 请求用户开启通知推送的时机却选择得十分巧妙。
﻿
选择向用户请求推送的时机十分重要。我们首先需要让用户了解到：推送是可以带来直接价值的。这时一定要说清楚，应用会在什么样的时机推送什么样的内容，对用户有什么样的好处。

产品和用户的每一次互动。其实都是一次交易。不论是购买一个产品，还是使用一个功能，我们需要用户付出他的时间、精力或者其他资源。这时候，我们就必须要说清产品究竟可以给他带来什么价值，只有当这个价值高于用户对于自己所付出资源的成本预期时，交易才会顺利地进行。

!

戳此获取你的专属海报

13 | 无用却必要：产品规划（上）

"In preparing for battle I have always found that plans are useless, but planning is indispensable."

——Dwight D. Eisenhower

大部分的产品经理都需要定期做产品规划，这些产品规划包括了年度规划、半年规划、季度规划甚至月度规划。每个规划需要画产品路线图（Roadmap），做幻灯片，先逐级汇总，向上汇报，然后再向下分解落地。如果速度慢一点，可能还没来得及彻底落地，就要开始新一轮的规划了。

就像艾森豪威尔所说的“作战计划书没什么用”一样，产品规划书通常也会跟现实情况有出入，用户的反馈、市场环境的变化、竞争对手的策略、组织架构的调整等等都会导致产品规划被修改或推翻。

刚做产品经理的时候，我很反感频繁地去做规划，感觉全世界的人都知道那是个谎言，但是还得一本正经地把谎说完。后来我逐渐意识到了规划的重要性，也在实践中总结出怎样做出有价值的规划。今天，我就围绕这个话题来展开分享。

自上而下还是自下而上？

不同的公司有不同的产品规划方式。有的公司是自上而下，从最高管理层制定战略开始，分解到各事业群，再向下细化到产品线，最后拆解到每个职能的头上。还有一部分公司是由每个具体的组发起，汇总到产品线，不断向上传递，最终形成公司战略。

前者更利于公司资源的战略安排和协调，也方便战略安排在组织内部的沟通和传递，因为产品经理和开发都比较容易弄清楚自己做的事情跟公司方向有什么联系；后者则能够给团队成员更多的发挥空间，能够激发主观能动性。

但是，这两者的弊端也显而易见。自上而下的拆解导致一线员工的判断和认知很难融入公司战略，很难做到所谓的“让听见炮声的人做决定”，这可能会导致公司错失机会。自下而上又比较散乱，缺乏一致性，可能不同的部门想做不同的事情，互相之间又需要彼此的支持，结果协调起来很困难，有种各自为战的感觉。

从这两种方式的利弊中，我们也可以看到产品规划的两个重要目的，一是针对产品的愿景和公司的战略进行自上而下的沟通，让每个人清楚组织接下来一段时间的方向和重心，并在公司战略和自己的工作之间建立清晰的联系。二是激发大家的积极性和能动性，也可以给前线“可以听到炮声”的员工足够的话语和决策空间。

从这两个目的出发，我们或许可以尝试做一些结合。我认为可以先自上而下，由公司管理层明确下一阶段战略方向，然后向具体的事业部拆解，但这个时候，不要下到太底层，只要有基本的框架就够了，再自下而上进行具体的策略填充。

举个例子，比如某个面向 C 类市场的产品，公司管理层在某一阶段认为用户增量红利基本没有了，而且竞争对手该死的也都死了，没死的基本也都成气候了，一时半会儿打不死；所以公司决定会在接下来的一段时间内，集中资源改进和完善用户体验，公司重心不再放在增加用户量上。

在这样的方向和战略下，服务部门可能会确定关注服务质量而非服务数量的规划框架。至此，自上而下结束，自下而上开始。比如，服务部门下属的呼叫中心会基于自己的职能范围确定自己部门的策略，让客服人员群策群力，讨论通过哪些方式可以提高整体的服务质量，并且明确哪些数据指标可以反映服务质量的提高。

产品和技术部门也是一样，先根据所在的事业群做自上而下的拆解，然后再根据职能特点进行自下而上的细化。假设我是做支付的产品经理，基于用户体验的大方向，我可能会提出像“支持更多的支付手段”，或者“提高用户交易安全性”等具体的规划；而对于工程师来说，他们或许会考虑提高产品的响应速度和可用性等。

在类似的过程中，我们能清楚地知道公司接下来的业务重心和希望达成的目标，同时又有自由的决策和发挥的空间，是一个自上而下和自下而上两者综合的过程。

当然，具体问题具体分析。公司的阶段、规模和迭代速度不同，都会大大地影响产品规划的方式和粒度。比如在产品非常早期的阶段，我并不建议做太多规划；对于复杂组织架构和成熟产品线，可能只选择自上而下的规划方式等。总之在做规划的时候要灵活，选择适合自己的流程。

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

很多的产品规划文档是由若干项目的简述和预计发布计划构成的，我自己也做过很多这样的规划。这样的发布计划很重要，但它却不能算是好的产品规划，它相当于跳过了为什么和怎么做，直接描述做什么和什么时候做。

当大家聚焦于具体的项目内容和发布时间时，很容易就会忽视产品规划最重要的目的。大家不太容易从一堆项目中去猜测背后的公司战略及部门阶段性目标，而且在这样的沟通框架下，真正拥有第一手讯息和经验的同事会有一种“被告知”的感觉，这样就会对产品和公司没有参与感，失去主动性。

好的产品规划应该从更宏观的视角和判断入手，尽量避免过分关注具体的项目和特性列表。

比如之前在做某条社区产品线时，我们分析认为当时的短板在于内容生产不足，于是决定接下来先投入力量，提高整个社区的内容生产能力，下一步再提高内容分发与消费的效率，然后再关注社区用户的互动氛围。

在此基础上，下一件事情是去明确检验每件事情是否做到的标准，比如通过监测新发的帖子数量来判断社区的内容生产能力是否有所提高。至于具体的“做什么项目来提高内容生产”，则是更进一步的具体实施阶段才需要关注的事情。

因为迭代比较快，而且每一步策略以及表现数据会影响下一步的方案设计，所以通常项目的发布计划不会规划很远。经常会出现“在项目进行过程中意外发现了机会，立即调整计划跟进，或项目启动后发现效果不好，中途止损取消”的情况。

更不用说组织架构调整、关键人员休假之类根本无法预期的意外情况，所以，在做产品规划的时候给出准确的时间点是非常困难的。

有人会说：“既然大家都知道不靠谱，我随便说一个到时候再调整是不是就可以了？”我的建议是：万万不可，宁可不给承诺，也不要承诺了却交付不了。

前者别人最多说你怂，后者可是会丧失信任的，信任是产品经理的身家性命，一定要想办法守好。

当然，在某些公司（尤其是大公司）里，确定产品规划时，如果没有项目及时间点会被挑战得比较厉害，为什么别人都有时间点你没有？除非你已经是话事人，或者有绝对的影响力，否则这时就要考验你在夹缝中生存的能力了。

我的经验是尽量打个提前量，提前进行战略的沟通和团队群策群力的讨论，在此基础上去做一些笼统的项目规划，具体的特性能多模糊就多模糊，交付时间范围能多大就多大。

我举个例子，比如我们的产品规划是增加用户支付手段，不要去规划类似“支持微信、支付宝和银联支付，11 月 20 日前上线”这样的项目，写成“支持 3 种以上主流支付方式，在 11 月下旬至 12 月上旬完成”，甚至“支持主流支付方式，Q4 完成”更好。这样做不但会让团队聚焦于业务目标而不是项目列表，也可以为团队争取足够的空间。

总结

今天的内容，我首先分享了产品规划的目的，以及自上而下和自下而上指定产品规划的两种方式，建议你根据自己组织和业务的特点，选择做产品规划的方式；之后，我区分了产品规划和发布计划的异同，这里建议你不要用做发布计划的方式做产品规划。

你在自己的工作中有没有做过规划呢，你是怎样做的？欢迎你在留言中讨论，我们下一篇文章还会围绕产品规划继续展开讨论，我们下次再见 。

!

戳此获取你的专属海报

14 | 留白与节奏：产品规划（下）

"No battle plan ever survives contact with the enemy. "

——《Donnybrook : The Battle of Bull Run, 1861 》 by David Detzer

这篇文章我会继续聊聊产品规划。上篇文章的最后，我提到了在产品规划中要加入项目发布计划时，可以尽量写得模糊化，不要把项目内容和发布时间写得太精确。

这并不是叫你蒙混过关，模糊化其实有两个好处，一是出于尊重承诺的考虑，产品经理的影响力来自于交付承诺，所以不要轻易承诺做不到的事情，这个话题我以后会专门讲；二是可以通过这样的方式给产品规划适当留白，给自己和团队争取足够空间释放创造力，以及应对一些环境的变化。

产品规划的留白

产品规划的留白可以分成空间上的留白和时间上的留白。

Ruby on Rails 的创始人 DHH 曾经说，当你面前有艰巨而冗长的任务队列等待实施时，你的创造力将会被严重的抑制。

对于大部分人来说，当面前摆着一长串待办事项，而且待办事项上全都是具体的执行性工作任务时，我们会比较容易沉浸其中，就像在快餐店操作炸薯条的机器，照着一二三做就可以了，这时我们很少会有创造性的想法。

举个例子，如果规划文档中的项目任务是“支持 VISA 和 Master Card 信用卡支付，12 月 30 日之前发布”，我们脑子里想的一定是先去查接口文档、申请资质，以及整体的技术架构和页面流程。

这是一种本能反应，但是，我们其实更需要知道的是这个项目背后的动机。这种动机是有很多种可能性的。比如可能是为了增加支付渠道，也可能是为了提供跨境支付能力等。

当我们关注这些动机和目标时，我们的思考会上升一个维度，从研究“怎么做”转向“该做什么”。

比如，目标是为了增加支付渠道，那我们或许可以直接接入第三方的支付组件，一次性增加包括各种信用卡在内的多种支付渠道；如果目标是为了提供跨境支付能力，我们或许可以直接去接 PayPal。

关注这些动机和目标也可能会让我们考虑得更加周全，比如是否需要在境外增加服务器节点或缓存等相关基础设施。

所以，我们在做产品规划的时候，最好能把这些细节留白，到了具体操作实施的时候，让处在那个环境里的同事去决定具体的策略。

关于时间的留白，说起来挺文艺，其实就是指尽量别把时间点定得太精确。精确必须以具体为代价，而提前规划出来的具体十有八九都不靠谱。在这里，我建议最好先写成 X 月上旬 / 下旬这样的形式，到时候根据具体情况再决定怎样执行以及何时交付。

定期回顾和更新产品规划

产品规划的作用不是一次性释放的，在实际的业务进展过程中，我们应当不时地把产品规划拿出来回顾和更新。

回顾产品规划的目的是经常性地帮助团队换换脑子。我们在工作中通常是低头盯着手头的活儿，这样的状态保持久了很容易忘了抬头看路；所以每隔一段时间把当初的规划拿出来看看，能让大家时刻记住要达成的目标，而不是仅仅关注执行。

有很多书和文档建议每周就要回顾一次，在实践中我觉得这个频率挺高了，一般季度规划两周回顾一次，年度规划一个月回顾一次就差不多了。

在回顾的过程中，应该讨论规划中的目标实现状况，这包括了尝试了什么策略，哪些策略是有效的，接下来打算尝试什么策略，完成的进度等等。

这时候的讨论除了能互相同步信息之外，还可能会碰撞出新的火花，我曾参加过一次回顾会议，我们团队中的运营分享了一个效果惊人的运营活动，产品经理获得启发，把它做到了产品里面，后续的反响热烈。

我们在回顾产品规划的时候，还需要关注环境和形势的变化，再根据这些变化调整产品规划。

有人会觉得这种调整没必要，其实不然，产品规划也会有破窗效应，一旦其中有一条失败了却没有被拿出来严肃地讨论更新，就会让大家觉得整个的规划是否能实现无所谓，规划也就彻底流于形式了。

产品规划到项目交付的节奏感

产品规划是一张蓝图，它的作用在于为具体的项目实施确定路线图和方案，所以最后它还是要靠做出来实打实的特性和功能才能产生价值。经常有人会提到产品线迭代的节奏感，其实说的就是把规划不断地变成项目过程中的节奏。

音乐中的节奏是曲子行进的基础，音符千变万化，丰富多彩，但总有一个稳定的律动。芯片制造品牌英特尔的产品迭代策略有个很有趣的名字叫 Tick-Tock，就是钟表摆动的滴答声。它表示英特尔会以两年为一个周期，第一年提升工艺，第二年更新架构（后来好像因为工艺发展遇到瓶颈周期改为了三年）。

好的项目节奏应该也有类似的节奏感，大家要能大概判断多久会有一次项目发布，多久会有一次重构升级，多久会有界面的更新等等。整个团队的流程和资源就会慢慢地形成惯例，同事之间的配合也会跟着这些惯例越来越默契。

另外就是在每个阶段都要专注，尤其在战略思考已经明确的情况下，尽量在每个阶段聚焦做一件事情，不要做着东还惦记着西。比如在决定在当前阶段针对老用户全面提高留存，那就尽可能不去做拉新的事情。

战略上有决议之后，执行要尽可能凶悍，不要绣花，该低头拉车的时候就低头拉车。我以前跟心思特别缜密的运营合作过，周一确定方向，周二设计方案，周三该执行了，突然又重新开始思考方向，说还不够完美，急死个人。

规划方向时要谨慎，尽可能地想周全想清楚；可一旦落定，就应该坚决、激进，不要完美主义，接受 80 分，边做边迭代，快速调整，这样才是优秀的节奏和状态。

总结

今天，我首先谈到了产品规划中空间和时间的留白，这部分的重点是规划尽可能从业务和战略层面去设计，把发挥空间留到临场。其次是我们要定期回顾产品规划，当环境发生变化时要即时做出调整。最后我们聊到了产品迭代的节奏感，这部分的重点是团队的节奏默契，以及规划落地时阶段性专注的重要性。

你所在的产品团队是否有自己的节奏吗，你们的流程和工作习惯又是如何配合这样节奏的？欢迎大家在留言中分享讨论。今天我就聊到这里，谢谢，再见。

!

戳此获取你的专属海报

15 | 产品案例分析：Mimo与Learn Python的导学之趣

Mimo 和 Learn Python 是两款针对基础 IT 教育的应用。

教育类的应用是最难做的应用类型之一，尤其是需要学习者自我驱动的教育类应用更是难上加难，在 IT 这种实践性非常强的领域内，除了要基于用户或者说学习者自我的驱动力之外，还需要产品的设计者给出足够循循善诱的学习计划。除此之外，设计者还需要在学习者使用的过程中，随时观察他的状态、设计复杂的成就系统，给予他恰如其分的鼓励。

我们就从做题开始体验一下，Mimo 是如何了解用户并且推动用户学习的。

** 首先是题目的设置。** 这个专栏读者应该都有简单的编程基础，知道要把编程这件事情从易到难、由浅入深地讲清楚并不容易。这里的题目设置很巧妙，它会给用户讲一点内容，然后要求用户互动。

这就是通过内容设置引导用户学习的过程，在这里，应用像是一位老师在给你讲课，怕你走神儿，所以讲一句就问一点问题，让你一直跟着它的思路。

其次是答题反馈的设置。 当用户在答题和反馈的过程中，每一个正确或者错误的时刻，对设计者来说都是一个关键时刻。在这个时刻应用如何反馈非常重要。它是否可以在正确的时候，给用户积极的反馈，在错误的时候，给用户鼓励，引导用户继续向前，这是一个学习型应用能不能持续黏住用户的关键点。

在答题的过程中，用户不断会触发一些成就系统的提示，获得一些鼓励。

应用的成就体系有两部分组成，一部分是根据你的学习情况，系统根据规则给出的勋章和奖励；另一部分是系统引导你去设置的，自己的学习目标；这样一来，自己设置的目标相当于自己给自己的承诺。从心理学的角度来讲，人会倾向于前后一致，这也是也是一种黏住用户的手段。

Learn Python 这款应用则是利用社区的方式增加用户的黏性。

和 Mimo 不同，Learn Python 每种语言各自是一个应用，这样可以让用户更独立地聚焦场景，另外，也可以从应用的层面，天然地隔离了付费模式。

它的题目设置跟 Mimo 类似，但加入了社区的属性。在每个题下面，甚至每一个选项，都会有评论。你可以看到其他的学习者在这里的留言。并对他们的留言进行点赞。

Learn Python 还为学习者们提供了各种交流的机制。比如有 Play Ground，在这里大家可以写下自己的代码，让别人来运行甚至编辑，还有讨论区和问答板块，看起来十分丰富。还有 Leader Board 也是一个社会化的成就体系。

应用甚至还提供了加好友，以及跟好友之间互相做编程任务挑战的功能，为了能让学习者保持学习热情和粘性，Learn Python 煞费了一番苦心。

总之，利用学习工具，把学习者聚到一起。形成社区；然后由社区的力量持续地黏住用户，这就是 Learn Python 一以贯之的设计思路。

!

戳此获取你的专属海报

16 | 在内部产品中找到产品经理的价值

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

——鲁迅

当提到产品经理时，大部分人都会想到用户产品、商业产品或者平台产品。然而，有一类产品经理总是处在产品领域的阴影中，这就是内部产品的产品经理。

大部分的产品经理其实都不太愿意做内部产品，觉得这份工作受气还没有出头之日，而且也很难开口向亲戚朋友介绍自己的工作。

其实，做内部产品不但可以帮一个产品经理打下扎实的产品基本功，也能磨炼一个人的心性。我刚入行时，做的就是内部产品，并从中收获良多。

今天，我就来讲一讲做内部产品的方法和挑战，这些内容不但适合内部产品经理，对非内部产品的产品经理也会大有帮助。

什么是内部产品

首先我们定义一下什么叫内部产品。内部产品通常是指自己公司内部员工使用的产品，比如 CRM、ERP、CMS、广告管理系统、法务合规、财务系统等。有的公司会选择采购其他公司的产品来用，但有的公司会开发自己的内部系统，这其中有的是基于开源框架的，有的是自己旱地拔葱，从零开始写的。这两种情况，通常都会有对应的产品经理来负责。

用户离你很近

内部产品最显著的一个特点就是：产品经理和用户的距离很近——你甚至能看到你的需求方，他们通常坐在你工位附近。这也就意味着他们不再是你脑海中设计的用户模型，而是随时能冲到你位置上跟你争个面红耳赤的同事。

这直接导致你很难在产品设计中说不。所谓见面三分情，你经常看到你的用户，甚至跟他们一起吃午饭。这很容易让你融入他们的立场和喜怒，保持不住冷静和理性。

这个问题在我过去的工作中尤为显著，因为我媳妇就在我的直接需求部门工作，稍有不慎，麻烦就大了。我花了不少精力克服这样的问题，跟大家分享三条对我帮助很大的经验。

1 资源显性化

第一个方法就是把仓库的门打开，将技术资源显性化。让业务部门清楚地了解到整个技术部门有多少人力，多少工作任务。我们当时的做法是会推算整个部门每个时间段的可用人力情况（比如每周 100 个人日），扣除一部分做日常 Bugfix 和重构之外（一般是 20%），剩下的和盘托出，让业务部门看到我们的人力情况和交付能力。

另外，我们会尽可能地跟业务部门去介绍系统的基础架构和实现原理。比如我们当时做订单系统，需求方认为更换订单标的很容易，改一个字段就好了，但对系统来说，这涉及一系列的上下文修改和流程的逆向处理。这种情况下，如果能从技术的层面解释清楚原委，就完全可以避免不必要的压力和对立。

2 项目流程化

有的内部产品收集需求比较随意，用户可以随时向产品经理提要求，所以用户会泥沙俱下地提出一大堆想法，提出想法之后还会有期待。于是，我经常会看到产品经理被用户围着问，上次说的某某某功能怎么还没做完啊？

所以不论研发团队是否采用敏捷开发，都建议内部产品的需求收集与确认可以周期化。比如根据业务的节奏两周或者一个月一次（如果节奏很快每周一次也可以），大家拿出专门的时间来确定下一个阶段的交付计划。这样有仪式感的流程可以合理管理需求方的预期，让产品的进度更理性一些，避免失控。

3 用户研究的最佳试验场

有人说内部产品不太重视用户体验，基本不配用研甚至交互设计师，所以内部产品的产品经理这方面能力都很弱。

对此，我倒不是这么认为。内部产品对交互和用研的要求或许确实不那么苛刻，也很少配有专职的交互设计或用户体验设计师，可对于产品经理来说，这其实提供了自己亲手做交互设计的空间。

在内部产品环境中，我们收集用户反馈的效率变得非常高，不用精心设计问卷，挑选投放渠道。你可以约好时间直接走到用户的工位上，坐着聊上三五分钟，问题没有设计好也没关系，随时可以返回去多问一句。

产品可用性研究成本也变得非常低廉，不需要单向玻璃，不需要送什么充值卡，直接坐到用户旁边看他的操作即可。

我曾经负责过服务部门的一套系统，当时的我可以直接拿着秒表坐到呼叫中心的同事身边，去找提效的关键节点。这是一种拳拳到肉的用户参与，不是通过一张问卷或者一封邮件隔靴搔痒。

不要成为功能经理——变被动为主动

内部产品的产品经理容易遇到的另一个问题是缺乏主动性。刚才我们提到内部产品的需求通常会铺天盖地袭来。

在这样的情况下，产品经理稍有不慎就会处在一个消极应付的局面中，即便开足马力，需求列表也会越来越长。

在这个过程中，产品经理会逐渐开始放弃思考，只是把业务部门提来的需求转发给开发，变成一个传声筒。我们有时会将这样的产品经理称为“功能经理”，他所有的工作都是由功能驱动的，关注的只是特性和功能逻辑，而不再是产品层面的价值和取舍。

那么，怎样避免在内部产品中成为一个功能经理呢？我也在这里给你介绍几个方法。

1 跳过方案，寻找背后的动机和诉求

在之前的文章中，我也提到过，产品经理要从用户的需求中，寻找背后的动机和真正的诉求。我也跟大家聊过“5 问法”——抓住一个问题不断追问为什么，找到需求背后的需求。在内部产品中，这一要求更加重要。

由于对系统的深入了解，内部产品的用户在提需求时通常都会直接提出“解决方案”。比如，像之前提到内部用户会提出“订单列表增加按时间排序的选项”这样的要求。甚至，我曾经还接到过类似“订单号字段增加至 128 位”这样具体的方案式需求。

这时产品经理一定要避免不假思索地将类似的需求直接交给工程师团队，你需要多追问几个为什么。比如订单号字段增加的需求，背后可能是整个订单号体系的变更，远不止改一个字段长度这么简单。作为产品经理一定要把这样的动机挖掘出来。

2 统一战线，成本收益一致

内部产品线的产品经理经常会抱怨没有话语权，甚至不被业务部门尊重。这一点其实无可厚非，因为业务部门背负着刀刀见血的业务指标，而技术部门只是辅助。

这时候，需要将自己推到业务部门、甚至整个公司的立场上，从业务的角度而非工程的角度考虑公司的投入产出比。

将技术成本并入业务成本，同时把业务收益和内部产品技术团队的收益绑定，这样，产品团队才能跟业务团队绑定起来，产品的思维模式也从微观的产品技术团队上升到业务模块甚至公司层面。

这样的环境和状态，才能够变被动为主动，不再局限于成本中心的定位，扭转弱势地位。

除此之外，还有一个非常重要的提醒：想要与业务紧密绑定，内部产品的产品经理必须要深入了解业务。

如果是做财务系统的，要了解财务部门的职责、流程，甚至去了解一些会计师准则。如果是做 ERP，就要深入了解供应链相关知识。能与内部业务部门合作其实是个难得的机会，你可以向业务专家请教学习，丰富自己的见识。

我的第一份产品经理工作是做阿里巴巴内部的业务管理系统。借着这个机会，我了解到很多互联网企业商业产品的市场、销售和服务套路，这是一笔非常宝贵的财富，也是单纯做用户产品的产品经理很难得到的经验。

3 发挥强项，用技术帮助业务

内部产品是个金矿，里面有大量的流程和业务数据，这些数据极具分析价值。业务部门或许会经常提一些数据分析的需求，但内部产品的产品经理应该同样了解，甚至比业务部门更加熟悉系统的数据结构以及这些数据的业务含义。

这时如果可以主动出击，经常分析数据，将简单的数据统计进化为数据洞察，就可以极大地丰富业务部门的视角。倘若再进一步，做出能够直接帮助业务部门做决策的数据产品，就可以进一步放大产品和技术的独特价值。

比如，对于支撑客户服务的内部系统，就可以在基础数据需求之外，提供更加完善的服务效率报表，甚至通过数据挖掘和建模做出服务量的预测，从而帮助服务部门根据业务的进展，弹性规划服务人员的储备。我还听说，很多客户服务支撑系统通过人工智能的方式，挖掘客服人员记录的服务小计或服务录音，利用数据统计去反推服务模式甚至产品的迭代发展。

总之，越是内部的产品经理，越应该努力往外走，通过自己的竞争优势（对产品、技术和业务流程的理解），去站到业务里面去成为一个攻击型选手，而非一个后勤补给选手。

总结

最后，我们来回顾一下今天分享的内容。首先，我们提到了内部产品有自己的特点，也就带来了独特的挑战和机会。

用户太近带来的压力和混乱，我们可以用资源显性化和需求流程化来应对，并且把握好这种“近”的特点，去学习和尝试做用户研究。然后我分析了如何通过挖掘动机、绑定立场和利用技术力量推动业务来最大化内部产品经理的价值，避免内部产品经理沦为功能经理的窘境。

你有没有过负责内部产品的经历呢？内部产品设计的经历又是否给你带来了不一样的技能和优势？你不妨在留言中写下来，我们一起交流讨论。

!

戳此获取你的专属海报

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

“何况异形体，信任为股肱。”——（唐）孟郊

我曾看过一篇文章，里面提到了 Google 的产品经理招聘要求里有一条，大意是：“无需通过汇报关系或权利，就可以影响技术团队和其他跨职能团队，完成任务”。

这个要求其实也让不少产品经理很郁闷，没有胡萝卜也没有大棒，不能威逼不能利诱，如何才能对团队施加影响力，让大家聚在一起做事情？

我记得之前有个同行私下里跟我吐槽，说他们 CEO 给他打鸡血说，产品经理就是没有权利的 CEO，他很激动，说没有权利还 CE 哪门子 O，让他自己来试试。

其实，在我看来，这一要求并非不可行。产品经理不依靠权利和汇报关系建立影响力的最好办法，就是建立信任。当大家相信你在推进正确的事情，自然也就愿意聚在你周围，配合你去交付产品特性。

今天我就来讲讲产品经理如何建立信任。

在我看来，在不同职能组成的团队中建立信任的唯一办法，就是持续地、保质保量地交付承诺。产品经理的大部分工作都带着未知，是否有成果要在未来才能检验出来，而这些成果的前提，是需要各种其他角色投入大量的资源和精力。

设想一下，如果一个人现在要你投一笔钱到某个基金，什么因素会让你更愿意做出投资的决策？最重要的就是信任，你对这个人，以及这件事情的信任。

1 建立信任是个长期的过程

建立信任不是一蹴而就的，好多资历稍微深一点的产品经理刚到一个公司，就想要大刀阔斧地进行改革，重构产品模式，推出新的产品计划。除非你已经是行业内非常有名的产品经理，做成过很多产品，否则这个过程通常会经常碰壁。

之前有同事或朋友换工作，问我到了新的环境怎么落地，我都会建议要从小事做起，多做少说，死磕自己少磕别人，先建立一定的好感与信任，然后再琢磨干大事儿。

这其实就是建立信任的过程，先从小事做起，哪怕就是发个数据日报，甚至帮人整理个产品文档。干干净净，妥妥当当地做好，做到超出期望。坚持一段时间，事情自然就会升级，公司会倾向于交给你更难的任务，也会愿意给你更多的资源。这时继续把新任务做妥当，超出期望地交付，周而复始，信任就会建立起来。

我记得之前看过一句鸡汤，说什么叫人才，人才就是交给他一件事情，他完成了，再交给他一件事情，又完成了。

这其实就是建立信任的过程，给你一个人日的开发资源，做一个小需求，你按时交付，做得非常漂亮，那下次给五个人日，又保质保量地交付，再下次试试十个人日，你或许就有机会做项目了。

但注意，很多时候并不是一帆风顺，也会有做砸的时候，做砸的时候会影响你的信任分值。有个公式，说的是每做对一件事情，信任分值可以加 1 分，但做砸一件事，分值会降 10 分。所以一个人在团队中的信任和影响力也是个动态的过程，要时刻保持重视。

拿前面投资基金的例子来类比，如果一个基金经理干了十年，每年收益率都高达 30%，另一个虽然以前收益率也挺高的，但最近三年每年都亏 20%，第三个则是新手，还没有任何业绩历史，你会选择投资哪个？

我想，答案一目了然。

2 如何试错

或许有人会问，产品发展不就是个试错的过程吗？总要有做砸的时候，如果做错就会扣分，会不会让大家宁可不做事，也不愿做错事，最终整个团队没人敢于尝试，都缩起头来自保？

首先，一直不做事也是会减分的。如果你长期没有实实在在的产出，大家也一样会丧失对你的信任，而且还耽误了你自己宝贵的时间成本，得不偿失，所以一定不要成为这样的人或待在这样的环境。

其次，对于所有尝试，都一定要进行提前沟通。把目的、逻辑、数据、可能的风险和不确定性因素都提前交代清楚。

比如，我们决定为一个内容产品做文章分享功能，我们要说清楚目的是让用户帮助我们筛选和传播优质内容，吸引更多潜在用户；逻辑是用户愿意分享好的内容，而内容可以吸引潜在用户通过二维码或者链接进入产品，最终注册激活成为新用户；数据是我们通过测试发现分享的比例比较高，而且分享内容的用户转化率也不错。

于是我们定了一个目标，会有 5-10% 的内容消费用户做分享动作，每个分享的内容可以吸引 5-10 个用户进入，其中 10% 转化为我们的新用户。风险当然是数据估测过于乐观，或许还有分享渠道可能被封禁等等。

把这些沟通清楚之后，哪一环可能会出问题，可能会出什么问题，大家都清楚并且达成一致，万一真的出问题，对产品经理信任度的影响相对小一点。

我们还拿刚才的那个例子来看，如果基金的投资策略和风险都交代的很清楚，比如告诉你其中 80% 投资企业债券，20% 投指数基金，即便是最终赔了，或许你对基金经理的责难就能轻一些，毕竟策略和假设早就说清楚了，你对风险和收益有预判。

最后还是要说，即便所有的提前沟通都非常充分，错了，依然要扣分，还是会影响信任，这就是职场的丛林法则，必须认。

3 要重视承诺，不要找借口

有的信任是完成被动任务，而更重要的信任是来自于你的主动承诺。你开口承诺一件事情，然后按时成功交付了，这个过程对于建立信任非常有价值，这意味着你的下一次承诺更有力度了。

对产品经理来说，承诺重于生命，在没把握的时候，能不承诺尽量少承诺。可一旦承诺了，就要尽一切可能交付。不要随口答应，也不要态度暧昧，如果做不到就礼貌地拒绝。

比如业务部门来提你需求，当面你不好意思驳人家面子，或许说得模棱两可，结果人家误会了以为可以做，等了两个礼拜看没动静来问你进度，你说还没做，对方对你的信任程度就会降低，你说冤不冤。

或者你拍着胸脯说项目一定在某天发布，到了那个点儿没发，可能本身不差那一两天，但下次你再定项目计划的时候，别人就要打个折听了。

我之前的公司有个开发，偶尔会做项目经理，可是答应的时间基本没兑现过，后来每次他做项目经理，公布项目计划发布时间的时候，大家都会半开玩笑的说我们照着这个时间往后加一个礼拜做准备就行，都形成固定人设了。

可是，总有意外，万一承诺了没做到怎么办？牢记三点，第一不要找借口，第二要提前反馈，第三要有耐心在未来逐渐找补回来。

不找借口这个挺难的，我对曾经经历过的两次项目延期印象很深，每次延期的时候，项目负责人都会专门做个幻灯片，列出一大堆客观理由，理由中很多一部分都是在推卸责任，让人感觉很糟糕。

如果承诺是你给的，就尽可能自己出来背锅，该道歉道歉，把精力放到寻找解决方案上，而不要找借口。说其他人不配合你交付这个承诺，只能说明你没有能力罩得住这么多合作方的大型任务，依然是失职。

提前反馈的意思是，当有风险出现，影响到了承诺交付时，尽可能提前进行沟通，发个预警。不要到最后时刻才报告，那样会显得既控制不了局面还缺乏责任心；而且，提前的沟通会暴露问题，更方便尽早引入外力，把影响降到最低。

当然，每一次失信还是会有伤害，但是没必要自暴自弃，洗把脸重新出发，依靠未来持续不断地交付新承诺去挽回损失，照样是一条好汉。

4 不要在不重视承诺交付的环境中工作

最后多啰嗦一点，就是大家要学会识别工作环境。如果你发现你的工作中，那些不交付承诺的人没有受到组织的惩治和淘汰，而相反，交付承诺的人却经常受到伤害；发现大部分人都不重视信任，而你对信任的追求也并没有给你带来更多的机会和不断提高难度的挑战；那这多半不是一个成长性的环境，建议你可以考虑换个地方了。

总结

好了，今天的分享就到这里。我从产品经理的影响力说起，讲到如何建立自己的信任，怎样避免试错带来的伤害，以及承诺的重要性，最后还提到了对成长性环境的识别，希望大家能在自己的工作中通过建立信任，为自己赢得更多的影响力。

你有没有因为信任做成事情，或因为不信任错失良机的经验呢？欢迎你留言讨论。

!

戳此获取你的专属海报

18 | 产品案例分析：WWF Together的情怀设计

WWF Together 是这个基金会的一个推广应用，一般非营利性组织做的应用一般不太有什么特别的想法和创新，可能都是比较古老的设计风格，万年不更新；但是 WWF Together 的交互方式非常丰富，内容设计也花了很多心思，有不少值得分享的点。

1 用动效传递暗示

打开应用，首先看到的是一个折纸的过程，开屏结束以后，通过一个过场动效，给我们展示了完整的内容列表。注意看这个动效，一方面它很好看，另外一方面它明确地给我们暗示，这里的内容是水平布置的，我们想要看更多动物的时候，就会知道要左右滑而不是上下滑。

这个小动作非常有效，我们要暗示用户继续探索的路径的时候，可以用这样的动效，也可以露出一个边，看到一个不完整的边，我们很容易理解这个边是向水平延伸还是垂直延伸的，也就自然知道接下来的操作方向。这里我们用极客时间举个例子，可以看到左边留出一点，就是这样的一个暗示。

动效绝对不是花里胡哨的东西，它在很多时候能传递暗示，再讲一个题外的，就是苹果系统中输错密码的一个摇头的动效，OS 和 iOS 都有类似的东西，也很有意思。

2 望向镜头的眼睛

WWF Together 有一个很小的细节，你可以注意到，这里每个动物的照片都是包括眼睛的局部构图，这些眼镜是望向镜头的。这样的设计其实也是有心理学依据的，眼睛给人的心理暗示非常强烈。曾经有一个心理学实验，说的是在街上画一些眼睛，甚至是眼睛形状的图案，都能提高行人把垃圾丢到垃圾桶里的概率，而不是随地乱扔。

我还看过一篇文章说。如果在你的工作环境中。贴上一些有眼睛的图案或照片。或是放上镜子，让你可以看到自己的眼睛。都能提高你的工作效率。在一些 Landing Page 优化建议中。文章也提到了可以在首页中放置人物的照片，其中有一个要点，就是说这些人应该应该直视镜头，会特别有冲击力。

3 沉浸式交互

其实仔细翻下来，你会发现这款应用的数据量并不大，这跟我们之前提到的一些应用不同，那些应用是要把大量内容条理化简单化，但这个应用却是要把单薄的内容有机丰富地整合在一起。

我们可以看到，它利用了非常丰富的交互方式，来表现形态各异的动物的习性和特点，每一种都不同，很新鲜，吸引人们不断地探索，去了解每种动物。

比如我们打开熊猫，第一个有趣的交互是，当你按住这个折纸的时候。会有熊猫的叫声，上面的文字也会随之扭曲。我们继续往后看。会发现一些更有趣的交互，比如通过旋转一个控件来推进内容的继续加载，或砍掉竹子才能看到后面的文字。

我们再来看两个动物，你会看到具体的交互方式设计与动物的习性是紧密结合的，比如展示老虎的视力，是通过两个亮度不同的滤镜，还可以打开相机去通过这两个孔看自己周围的环境。再比如展示大象的生存环境，有 360 度视角的图片，非常用心，恰到好处。

应用不断地用这些交互形式吸引你的注意力，让你跟它去进行互动。让你的手不要离开屏幕。也让你的视线和精力沉浸在信息和内容中。

4 引人深思的传播与分享

最后还有一个拍照的功能，可以将这个动物的折纸形象和你的生活环境相结合做出一张照片，然后鼓励你把它分享出去，影响更多的人来保护野生动物，关注野生动物。

这个设计有一个特别好的隐喻，就是这些动物跟你身边触手可及的环境是息息相关的，它们就在我们身边，与我们共存。而且我们知道，当我们想要促进某个用户去进行分享和传播的时候，最重要的事情是要保证这个分享和传播的东西是跟他有关的，一张自己身边环境的照片，就是跟它有关的内容，这样的相关性，理论上也会提高分享的意愿。

而且我觉得难能可贵的是，它并不是通过站在道德制高点来胁迫你分享和呼吁对野生动物的关注，而是通过这样有趣的功能，来推动你去做传播和分享，很克制，也很体面。

与此类似的是另一个叫做 Story of Life 的应用，它的内容都是 BBC 关于动物的纪录片，整个 App 是横板和全屏的设计，沉浸感很强，像打游戏或者看电影，里面的内容主体都是视频。这些视频的选择和播放方式挺有趣。

比如我们过去都是横向去拖拉进度条，而这里的纪录片快进式进度条是圆形的，你可以看一下里面的筛选，也是横向滚动和滚轮旋转筛选相结合的，很有趣。总之，给人整体的感觉很有冲击力，不像是一个普通，死板的纪录片架构。

国内有一个也很有名的叫榫卯的应用，它也得过不少设计的奖，它把木艺中的榫卯结构，用图文并茂的方式展现出来，制作非常精美，交互也很棒。

这几个应用或许都不具有什么特别的商业价值，但却让人觉得充满情怀，也很有趣味。尤其是世界野生动物保护协会的那款应用，我个人非常喜欢，让人眼前一亮。

!

戳此获取你的专属海报

19 | 产品经理如何与开发打交道（上）：打破思维的边界

“横看成岭侧成峰，远近高低各不同。——苏轼”

在产品经理的日常工作中，开发工程师可能是我们打交道最多的角色，可是，这两个角色之间却有很多难以调和的矛盾，网上开发工程师怒怼产品经理的艺术作品很多，各种吐槽图片和文章俯拾即是 。

今年的 QCon 会议我也听一个段子，据说在大会的中午自助餐厅里，不同公司相互陌生的工程师，都靠吐槽自己公司产品经理迅速建立了友谊。

我自己写过程序，又成为产品经理，对这个问题有一些自己的理解，今天我就根据这个话题来谈谈产品经理如何同开发打交道。

为什么与怎么做

首先，我们来一起想想是什么原因导致了这两个角色之间的对立。

在面对产品或者特性时，产品经理和开发脑子里的东西是不同的。对于产品经理来说，他想的可能是客户、市场、盈利、竞争优势、政策风险、从哪里获客等等，这些东西想清楚之后，他的产出可能是 PRD，对产品功能需求的描述。开发一看，你折腾半天就这么一个东西，三页纸，没什么难度嘛。

开发脑子里关注的是什么呢？开发会关注手头的系统是不是遗留系统、系统架构有没有限制、公司的技术栈是什么样的、整个链路架构有没有问题、需不需要重构等等。这些东西产品经理可能不关注或者不懂，所以就看着一个挺大的开发团队做了很长时间，推出了一个特性，好像也没什么难度。

作为产品经理，有时我们会低估一个特性背后的技术成本。看什么都觉得简单，人家淘宝也有这个特性，为什么工程师说做不了呢？

尤其是通常在业务初期的时候，为了快速推进，工程师在实现上会做一些比较临时的东西，后期逐渐流量和复杂度提高，即便功能没变，也要花费大量的精力去调整技术架构。

所以你可以看到，产品经理脑子里的东西偏向“为什么”，而工程师脑子的思维方式会比较偏向于“怎么做”，两者的交集在“做什么”上面。也就是说刚才说到的，工程师看到好像产品经理背着手写了三页纸的 PRD，产品经理觉得工程师忙活半天就是一个简单的小特性。

久而久之，就会由不理解变成不信任，越不信任就越缺乏交流，演变成对立。

甲方乙方

关于这个话题我采访过我媳妇，她是做运营的，我说：“开发和产品之间矛盾这么激烈，你怎么看这个问题？”我媳妇觉得很奇怪，问我，你们不是一伙儿的吗？搞不懂为什么天天吵。

其实大部分公司中，最初设计组织的时候都会把产品和开发放到一起来看，希望这两个角色能够合力完成产品的设计和实现；但是在这个团队内部，随着人越来越多，就会有角色的分化，进而有了流程的分化，慢慢形成了甲乙方，或上下游。

如何去分辨团队从合作关系变成甲方乙方的关系呢？

有几个非常明显的信号，第一个是留证据，就是说了什么不算数，要发一个邮件签字画押；第二个是开小会，也就是在跟工程师开会之前，先自己角色内部开个小会，商量怎么对付对方，准备好对策之后再开大会；第三个是用词的方式，当你发现大家的用词越来越谨慎，并且开始在闲聊的时候区分我们和他们，设置大家开始试着从第三方了解彼此在干什么，了解对方对自己的评价等等。

类似的信号如果反复不断地出现，通常就意味着双方开始逐渐走向了对立，如果不加干涉，合作氛围就会出问题，一定要及时发现、及时处理。

加强沟通，互通有无

接下来我们要说怎么去克服双方可能出现的矛盾和对立，第一个要提到的，也是最重要的方法就是沟通。刚才我们说到产品经理脑子里是“为什么”和“做什么”，工程师脑子里是“做什么”和“怎么做”，过去产品经理和工程师的沟通通常会集中在做什么这里；更好的沟通就是要让产品经理把为什么告诉开发，让开发把怎么做告诉产品经理。

彼此说清楚自己的顾虑和困难，英文里有个说法叫做“ on the same page”，就是指产品经理和开发能看到彼此可以看到的东西，互诉衷肠，互相温暖。

专程交代业务规划和产品价值

对于产品经理来说，一定要专程交代产品价值。所谓专程交代，是指不要只在需求评审和需求沟通的时候才去介绍产品的来龙去脉。这是不够的，一定要拿出时间和精力去做专程沟通。

比如平时闲聊的时候，下午茶的时候，一起吃饭的时候，我之前经常会跟合作的工程师在吸烟室里聊，不说项目和需求，而是讲目前产品的状态，为什么要做现在的东西，之前做的东西的近况如何，业务目前是什么状态，接下来可能会向什么方向发展等等。

如果你在做项目的时候去沟通这些，工程师会本能地有所防备，因为你是有企图心的，你想说服工程师投入时间和精力做项目嘛。但当你专程去讲的时候，这个企图心就被放下来了，讲得多了，就会慢慢开始有共鸣。

一开始这么讲的时候会看起来像个神经病，但久而久之，工程师会理解你是真的在沟通，在共享信息。最后达到什么效果呢？就是当你真的开始提需求和项目的时候，工程师会非常理解，有种心照不宣的默契感觉。

掌握技术概念和技术语言

产品经理要掌握技术的概念和语言，这个蛮有意思的，每个公司都有技术栈，技术栈有不同的特点，我刚开始做产品经理的时候，主管知道我有写程序的经验，就让我去看代码，甚至让我去写代码，给我代码库的权限。他的目的就是要我知道，当时的技术栈是什么，基础的架构是什么。

看代码是个效率不太高但非常扎实的办法，还有个办法是去写非功能需求。因为工程师的“怎么做”有很多是在水面下的，比如他要保证可用性，保证安全，比如做一个简单的文本框让大家写东西为什么要花那么多时间？可能就是为了保证不要被黑客利用它做注入攻击。

如果产品经理把这些非功能性需求一条一条写下来，比如浏览器适配，做一个功能可能很快，但要保证在各种各样的浏览器下都表现稳定，就需要花费额外的时间，可能比做出这个功能花费的时间还要多。这些东西写下来，产品经理就可以大致了解真实的开发工作量。

另外就是作为产品经理要跟工程师多接触，让他们多给自己讲一些技术，优秀的工程师提到技术通常会滔滔不绝，如数家珍。当你了解基本的技术常识之后，就会理解技术成本和技术的局限性，知道哪里是技术的边界，如何跟产品更好地做搭配。

总结

我们从产品经理和工程师矛盾的原因开始说起，提到产品经理会更多地关注为什么和做什么，而开发会关注做什么和怎么做，可能彼此之间并不尽然理解对方的思维方式，另外角色的分化又会导致双方逐渐成为上下游的对立关系。

接下来介绍了一些加强沟通，促进相互理解的办法，建议产品经理多向工程师解释产品的来龙去脉，也要多去了解技术领域和技术语言，下一篇分享还会继续聊这个话题。

如果你是产品经理，你在工作中是如何与工程师保持合作的？如果你是工程师，你会反感产品经理的哪些行为？你心目中理想的产品经理是什么样子的？欢迎在留言中分享讨论，我们下次分享再见。

!

戳此获取你的专属海报

20 | 产品经理如何与开发打交道（下）：合作与共赢

“兄弟阋于墙，外御其务”——《诗经》

上篇文章，我提到产品经理与工程师之间隔阂的原因，主要是思维方式的差异，以及关注领域的不同，然后聊到了几个加强沟通的方法，比如让产品经理向工程师介绍业务，以及主动去理解和学习技术等等内容，今天我们继续聊这个话题。

之前我提到过，因为角色的差异，产品经理和工程师变成了上下游。也就是产品经理折腾半天，做需求收集、分析讨论等等，然后做出 PRD 交给工程师之后就不管了，工程师拿到 PRD 之后做系统设计研发实施。我们希望工程师可以尽量早地参与到流程中来，产品经理则尽量晚地从流程中退出去。

全流程参与

对产品经理来说，首先要做到尽可能在项目的早期去跟工程师沟通。我们在安排一些项目的早期，可能因为很多东西没有最终确定，也不太想跟工程师说，觉得等确定了再沟通；但这样做很容易导致说的时候已经来不及了。比如 11 月 3 日通知工程师说：“咱们 11 月 11 日大促，这是三个需求你尽快做一下”，工程师会非常反感这种带着截止期限的突然袭击。

最好的方式是当某个业务有苗头的时候，产品经理就应该开始跟工程师交流，但这时候不要正式地去提需求，而是做一些非正式的沟通，否则后期如果有变化会让工程师觉得你出尔反尔。

除此之外，一定要邀请工程师来参与项目前期的需求收集和需求评审，不要觉得这种场合不需要工程师，等确定了再转述或者产品经理去宣讲就可以了。你需要尽可能让工程师参与，他可以更全面地了解项目和特性的目的，和不同利益相关者的顾虑和立场，也可以让工程师理解一些产品经理对产品细节的坚持。

除了让工程师往前走参与需求过程之外，产品经理也要主动往流程的后半部分延伸，去参与设计、开发、上线中的技术部分。比如在产品上线过程中出了 Bug，服务不可用了。

这时候产品经理应该干什么？可能有的人不参与，等着工程师自己处理，还有的在群里吵，谁的 Bug，什么时候修好等等；但是，其实更合适的方式是能够参与到问题解决中，去问一下具体是什么问题，需不需要帮助。

很多时候工程师在考虑故障的时候，主要会去想如何把出现的问题修好，而产品经理在考虑问题的时候，可能会考虑怎样把问题规避过去。比如说付款流程走不下去，工程师会想着去修复它，而产品经理或许可以协调一些资源，直接在某个时间段内就免费掉，先把付款流程绕过去，不损失用户。

但要注意的是，产品经理可以参与，但不要添乱，人家工程师在紧急地写补丁，你拉着人家说：“别写，先给我讲讲。”这样做就很不得体了。

多听工程师的意见

我们在产品设计的过程中要多鼓励工程师给产品经理提意见，这里产品经理和工程师都要摆正心态。对于产品经理来说，不能听不得反对意见，觉得工程师都是在指手画脚。对于工程师来说，不能觉得产品做成什么样子跟我没关系，反正做不好是产品经理背锅。

跟我合作过的工程师，让我最感动也是印象最深的都是那些能够在业务上跟我有不同意见，提出自己想法的工程师。你会发现工程师角度提出来的想法有时会非常有价值，他们有时候会帮忙指出逻辑中的缺陷，或者从可行性的角度中提出更有创造力的实现方法。

作为产品经理，如果总是不愿意听取工程师的建议，时间久了大家都不愿意跟你提建议，状态也会越来越被动，隔阂就会越来越深，造成双方的对立。

还有一个办法，就是让工程师和产品经理轮番做项目经理，当希望工程师尽可能早一些参与的时候，就让工程师做项目经理，因为需要约各种会议，判断利益相关者，还要理解功能的轻重缓急，这就会推着工程师去完整地了解业务。

如果需要产品经理了解更多技术细节，就让产品经理去做项目经理，他要组织和参加各种技术评审，有时候还要判断是否通过，也一样推着产品经理关注到流程的后半段。

不要强迫工程师做评估

这也是我之前犯过的错误，我有时会强迫工程师给出发布时间点，不给的话我就说他不负责任；但是，你要理解很多时候工程师是没办法给出具体发布时间点的，那这种情况下该怎么办呢？

有时候就会有冲突，我很强势必须要，那工程师就随便定一个，结果还是会延期，而且关系闹得很僵，所以如果确实很难确定工期，就不要定非常精确的时间点，可以做个模糊处理。比如 7 月 1 日交付别定成 7 月 1 日，就定成 7 月第一周，留一点缓冲。

另外，产品经理也不要代替别人做评估。比如跟业务部门交流完了之后，随口给个承诺，说一周做完；毕竟不是你做，不要越俎代庖，最好让工程师自己来做预判。

更不要在工程师做评估的时候去讽刺或者评价，产品经理经常会犯一个错误，工程师说某个功能有点难，我们就会说这有什么难的，你看腾讯早就做出来了。工程师会很反感这种沟通方式，技术基础不同，技术积累也不同，不能这么简单去做横向对比。

背黑锅与争取利益

产品经理有一个天职就是背黑锅，产品经理要勇敢地、毫不犹豫地在第一时间站出来帮工程师承担责任。要有这样的姿态，不要往后躲。

并不是说工程师不能自己去承担责任，工程师一般也都不是软蛋，但产品经理应该有这样的意识和态度。让大家知道这个产品经理是敢去担当的，不能跟人家看月亮的时候叫人家小甜甜，出了事儿又喊牛夫人，长此以往工程师就不愿意依赖和相信你了。

还有一个特别重要的事情，就是产品经理一定要帮工程师争取利益，很多时候产品经理是有这个渠道的，产品经理会跟技术主管有更多的接触。

这时候你要想办法给优秀的工程师争取利益，努力帮他做背书，施加你的影响力帮他晋升，给他加薪。尤其有些工程师会比较腼腆，在争取利益上很儒雅，那产品经理就应该要去帮他争取，可能他很多优秀的地方或许只有你有机会看到，要勇于去表达。

互背 KPI，同仇敌忾

产品经理的 KPI 一般都是产品指标，业务指标，而工程师可能会是可用性，特性交付等等。我一直鼓励产品经理去背一点工程 KPI，比如稳定性和可用性。这样做一来可以让产品经理对工程师的顾虑有切身的理解，不能说不在乎系统挂不挂，随意上线什么的。

另外也是防止立场的对立，跟工程师谈具体项目的时候，有时候开发会以影响稳定性作为推脱，如果稳定性也是产品经理的 KPI，那很多事情就容易沟通一些，因为这个事情也会影响你的绩效。

另外一个办法叫做寻找外敌，这个说起来有点腹黑，但确实非常好用。产品和开发也是，如果你们找到一个“外敌”，这个外敌可能是竞争对手，甚至是整个领域的一个敌人，比如我是一个制药公司，我们共同的敌人可能是癌症和肿瘤，比如我是一个做新零售的，那我们共同的敌人可能是传统的供应链巨头。

当有共同的敌人时，团队就更容易结合在一起，科幻电影里也是，人类之间互相打，一来外星人，马上团结起来同仇敌忾。

所以有时候大家可以适当地去树立外敌，有些公司，具体不说什么公司了，会故意在外面引发一些与竞争对手之间的骂战。本来这个业务团队内部闹得一塌糊涂，一看老板在外头被人欺负了，怎么办，立刻变得特别团结。

当然也不是一定要骂架，对于一条产品线，你完全可以在内部找一个具体的竞争对手，把一些业务指标对标起来，大家本着这个指标去努力，这时候可能很多内部矛盾会被消解掉，团队空前团结。

建立良好的个人关系

最后一个建议，是鼓励做产品可以多跟工程师交朋友。我工作这么多年，结交到的朋友大部分都是工程师。当跟他们真的成为朋友时，你会本能地考虑他们的立场，担心他们的担心，当然他们也会用心理解和帮助你。

我之前工作中偶尔会有自己没处理好的事情，或者因为任性捅的篓子，有时候对应的工程师可能就会加班，甚至通宵帮我处理掉。甚至也有朋友为了保护我，帮我承担了一些东西。这些工作量和付出其实都算是友情赞助的，也都不算是他们的绩效，这些感情我一直都记在心里。也想借着专栏的版面，向他们表达我的感激。

总结

到这里我们关于如何与工程师打交道的分享就全部结束了，这次我们提到尽可能让产品经理和工程师都全流程参与到一个产品的规划和实施中，建议产品经理多去听取工程师的建议，不要强迫或代替工程师做评估，尽量帮工程师争取利益等等。

所有的这些方法都只是方法，最重要的还是要始终重视打造与工程师之间合作氛围，与工程师相互尊重，始终保持合作的态度和意识，只有这样才能发挥各自的优势和长处，把产品做好，把事情做成。

你有没有让你印象深刻的，产品经理与工程师之间合作的故事？欢迎你在留言中分享，今天的文章就到这里，谢谢你。

!

戳此获取你的专属海报

21 | 产品案例分析：Fabulous的精致养成

Fabulous 不同于其他培养习惯的应用，有很多强制的提醒和计划，它给人的感觉就是很克制，淡淡地、循序渐进地帮助用户培养一个习惯。

这款应用设计得非常漂亮，从图标到内容，整个视觉风格很像纪念碑谷那款游戏，它的设计语言是经典的 Material Design, 得过不少设计的奖。

从新手引导开始说起。第一次打开 Fabulous。我们可以看到他的新手引导，并不是简单的教给你怎样使用这款应用的所有功能，而是把所有的功能构建在一个使用向导上。

你可以看到很多种不同的任务，但他强制要求你只能从第一个任务开始，后面的任务全都是被锁住的；整个的新手引导是以非常丰富的交互对话方式进行的，而不是简单的一个模板，告诉你点哪里操作什么。

它的交互也很人性化，我们之前在分享 Hopper 的时候，也提到过类似的风格。交互不是冰冷的说明书，而是人性化的交流。

藏在姓名中的细节

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

我们在这里写的小池，他就会一直以小池来进行第二人称的描述。这个细节虽然没有什么技术含量。但确实会让人觉得亲切。你可以看到他的一些流程和内容是以写信的方式推送给你的。在信中可以就可以开启一个习惯。

之前看过一篇文章。说每个人都会本能地关注自己，所以当你和用户谈论他自己的事，你就会比较容易获得他的重视。

早先在做邮件营销的时候，有一个技巧，就是在标题中插入用户的姓名，这样的邮件更容易被用户关注到，从而获得更高的打开率。邮件时代结束以后，自媒体命名也有类似的诀窍，很多人会在标题中使用第二人称你，因为从读者的角度来看它与自己的名字指代是相同的，所以更容易引起关注。

循序渐进的引导

这款应用虽然有很多的功能，但是并没有让用户操作，而是逐渐给用户弹出对话框，在某种程度上只会把整个应用的复杂性降低。你也不会特别急于去探索整个应用的完整的架构，他也限制了你的探索。而是逐渐地引导你进入到整个流程里面来。就像是在挖掘一个丰富的宝藏。

我们到其他的几个模块里面看看，他也会告诉你，在未来的某一个时机才能解锁。

我们可以在这里操作打开一些希望养成的习惯。我们的操作可以完全跟着他的引导，一步一步来。它会引导我们从每天早晨喝水开始，逐渐增加自己好习惯的数量。这里的设计非常的克制。不像其他的应用，一股脑的可以加上许许多多的习惯。

替用户“负责任”

很多时候我们在产品设计的时候，感觉可以把我们的功能完全交给用户，他自己爱怎么用就怎么用。这其实是不负责任的，因为用户在看着这些应用的功能的时候，尤其是这些习惯养成类的应用，很容易眼高手低。

用户没有办法意识到设置的每一个习惯养成，在未来的日子里会给自己带来多高的坚持成本；而且这个时候他是心血来潮的，所以他很有可能会一股脑地设置一堆目标。

当未来真的需要他付出大量努力来完成这些目标的时候。他的热度已经过了。而且可能又付不出这么高的坚持成本。那就有可能放弃，一旦他开始放弃，就会产生破窗效应，破罐子破摔，干脆全都不坚持，也不想再打开这个应用，看到自己的累累败绩。

所以不要想着全都交给用户，让用户为自己负责任。有时候用户是没有办法为自己负责任，这些习惯养成应用的存在。不也本来就应该肩负起这样的责任吗。

说到这里，我们也可以看到 Fabulous 的增值点。 它是订阅模式的应用，是在为自己养成习惯的方式和计划收费。在官网的自我介绍中。我们也可以看到这个团队除了在设计上下了很大的功夫之外。也在如何帮助用户培养良好习惯上。花费了很多的心力。

这个产品是在杜克大学的一个中心孵化的。这个中心的负责人就是那本著名的怪诞行为学的作者。他们确实是从科学的角度来打造这款应用，而不是简单粗暴的定一些闹钟，到点叫你喝杯水，活动一下筋骨这么简单。

我很喜欢这样的立意，也希望能有越来越多这样的产品。因为能够提供更专业系统的价值，而获得尊重和盈利。不像现在的流行趋势那样，要大流量，要做生态，做平台做大生意，才能赚钱才能存活。

每一个提供自己独特价值的应用和产品，都应该有充足的生存空间，也希望能够看到越来越多独立开发者或小的开发团队，通过这样精致、独特的应用，生活得很好。

!

戳此获取你的专属海报

22 | 产品经理的图文基本功（上）：产品文档

“没有内容的形式和没有形式的内容，都是不能存在的；即使存在的话，那么，前者有如奇形怪状的空洞的器皿，后者则是虽然大家都看得见、但却不认为是实体的空中楼阁。”

——（俄）别林斯基《论人民的诗第一篇》

产品经理的大部分工作是无形的，比如思考、分析、协调，在日常的工作中，我们能交出来的、唯一看得到摸得着的产出，就是各种各样的产品文档或产品原型，所以才会有人戏称产品经理就是写文档或做 PPT 的。

文档（包括原型和 PPT 等等）是产品经理重要的基本功，也是产品经理的脸面，很多时候会决定别人跟你合作的初始心态；而且从某种意义上来说，产品文档也是产品经理设计的一个“产品”，也是有用户（阅读者），目的（文档的目的）和特性设计（如何表述，用什么逻辑和工具等）的。

虽然现在越来越多的流派在提倡削减文档，用更敏捷和直接的方式驱动产品发展，我依然认为产品经理需要掌握做出漂亮文档的能力，这也是对产品设计过程的尊重。

接下来，我会分几篇文章，从产品经理日常工作需要用到的几种文档、模型和图示类型入手，分享怎样做出优雅、易读、清晰的产品文档。

平时说到产品文档，我们第一个想到的就是 PRD（Product Requirement Document），但其实在不同的场景下，基于不同的受众和目的，产品文档的种类很多，我们常用到的产品文档包括以下几类。

1. BRD/MRD

BRD 是商业需求文档（Business Requirement Document），MRD 是市场需求文档（Marketing Requirement Document），BRD 和 MRD 的出现机率并不高。通常在启动全新产品线的时候才需要用到 BRD。

顾名思义，BRD 描述的是商业级别的内容和判断，通常逻辑和内容会比较短小精悍，但背后要有广泛的调研和思考基础，而且 BRD 是站在公司和股东层面的，它回答的问题是我们要不要做，比如我们是否需要面向所有用户新增一种新的商业产品，或者我们是否需要将一次性收费模式变更为订阅模式。

我在过去的工作中，大部分要用到 BRD 的机会都伴随着重大的战略决策，需要比较长时间的周密推演和讨论，最终一般会是高层非常慎重的决策过程。

从另一个角度来说，我觉得大部分的项目是不需要 BRD 的，尤其是有些项目，都已经决定要做了，还要去准备 BRD 论证其合理性，就很形式化，没有太大价值。

MRD 一般会在既有的产品路线上启动比较大的项目或者新功能时用到，但我在过去的工作中却很少专门写 MRD，我自己的理解是： MRD 是 BRD 和 PRD 之间承上启下的一种形式，交代市场机会，竞争情况，产品和运营策略和计划等等，有点像是对 BRD 的拆解和细化，也有点像是高度概括、没有细节的 PRD；所以我会选择干脆把这样的内容拆到 PRD 或 BRD 里面去。

如果说 BRD 回答的是“我们要不要做”，那 MRD 回答的就应该是“我们怎么做”，它会比 BRD 多了很多细节，却又不涉及详细的功能逻辑和流程。在大部分项目中，我的习惯是把 MRD 的内容放到 PRD 中去，在不同的场合着重讲不同的部分。

比如在对业务和运营部门宣讲的时候，我会避开产品特性的细节逻辑，着重讲偏向 MRD 的部分，而在向工程师宣讲的时候，则会反过来，主要精力放在讲具体要实现些什么特性，只需要简明扼要地交代商业背景。

2. PRD/UC/FSD

PRD 是 Product Requirement Document 的缩写，意思是产品需求文档。PRD 是产品经理写得最多的文档，按照惯例，它一般是写具体的功能逻辑和细节，给工程师看的；但正如我刚才提到的，在操作过程中，产品经理还是应该在 PRD 中写一些包含商业、业务背景、市场机会等等内容；也就是交代清楚“为什么做”，而不是简单地描述流程和功能。

网上能找到的 PRD 的模板有很多，除非有强制文档格式要求，否则大家完全没有必要拘泥于其中的任何一种。最好是可以把各种模板都研究一下，根据不同的产品或项目类型挑选合适的框架。比如重操作的 To C 产品可能需要交互流程描述和线框图，而 To B 的产品可能注重的是概念模型和业务流程。

记住所有的模板都是为文档服务的，我们的目标是清晰和准确的文档描述，而不是把文档模板的空档填满。我看到过不少照着模板写的 PRD，其中有些部分明显就是为了避免空白硬填的内容，比如“数据字典”，作为一个操作类的特性，不涉及什么数据字典，去掉这部分就好了，完全没必要硬着头皮往里面填充没有意义的内容。

UC 是指用例文档，通常是以用户角度的完整功能单位为粒度，描述用户跟系统的交互过程以及系统的输出逻辑。如果项目是重交互，以用户场景驱动的话，我会推荐用 UC 来组织 PRD，也就是 PRD 里面按照用例的方式来描述功能实现，这样做更容易向工程师交代产品价值。

用例文档的模板比较简单，网上一搜一大把，最核心的部分是流程，通常会把主流程和分支流程分开描述，再复杂的业务，主流程一般都简明扼要，所有的复杂度最好都放到分支流程里面去，分支流程里面的一些限制和规则，可以整理一下，在业务规则的那个部分重写一份，便于工程师在开发过程中去查阅。

具体的细节我就不赘述了，但我建议你去仔细研究用例模板中的每一部分（比如背景、涉众、主流程和分支流程、业务规则等等）存在的价值。它给我们提供了一个研究用户以及思考用户行为的框架，能够帮助我们去有条理的从用户角度出发理解场景和系统功能。如果你有关于这些内容的想法可以在留言里提，我们再仔细聊。

FSD 是功能详细说明（Function Specifications Document），有时候我们也称作 FRD，我们经常说“写 Spec”，其实就是指它。这时的文档就偏向实现了，交代具体的数据字典，概念模型结构，业务接口规范等等，一般 FSD 会跟 PRD 合并，不会单独拆出来。

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

在我看来，大部分项目其实不需要这么多类型的文档，我的建议是尽量简化，对于大项目，BRD 加 PRD 足够，中等项目或者小需求直接写 PRD 或者 UC 就可以。

3. 产品原型 / 交互稿

不论是否有交互设计师，产品经理通常都需要出不同保真程度的产品原型，这也是产品经理干的最多的事情之一。随便打开一份简历，技能一栏里都可以看到各种原型制作工具的名字，比如 Axure，Origami，OmniGraffle，墨刀，Sketch，Visio，Keynote 等等，我们之前有一篇文章专门讲了这些工具。它们一般分成两种，一种是静态原型，一种是动态原型，动态原型会带一些简单交互效果。

在“产品经理的工具指南”一文中，我提到自己经常会用纸笔画线框草图，拍照贴在文档里。在跟交互或者视觉设计师达成默契的基础上，这么做的效率其实还不错。

（Readhub 早期的线框图手稿）

关于产品原型有两个提醒，一是记得把事情做到刚刚好就够了，很多产品经理喜欢炫技，把原型做得极其逼真，细节、动效俱全。大家要想清楚做原型图的目的是什么，做到什么程度可以达成这个目的，有时候原型做到八十分，把逻辑和框架表达清楚就足够了，结果产品经理非要做到一百分甚至一百二十分，这样一来会耗费没有必要的精力（但这不是你做一个不及格原型的借口）。

《团队之美》里面有对 Mike Cohn 的一段采访，他提到：“一个应用中所有的代码不一定要处于同样的质量水平”“不是每件事都要做到第一流，在大多数情况下，我们根本没机会做到第一流”。

同样的道理，一个产品所有的相关产出不一定要处于同样的质量水平。我们要克服“事事都做到完美”的倾向，这种完美主义倾向很多时候来源于对目标的不清晰和对真正产品价值思考的逃避。专业的事情交给专业的人，让设计师去完美产品的样子就够了。

另外一个提醒是，除非面对面讲解，否则产品原型需要一个明确的阅读线索。很多产品经理画完原型图就完了，往文档上一贴，不解释不说明，让开发自己去读图。开发读完做出来的东西有偏差，产品经理会从图上里挑出一个并不引人注目的细节说：“你看，我早就画在图上了，你没看见怪谁？”这种行为就挺招人恨的。

大部分人很难系统性地读完一张产品原型图，因为图不是一个线性信息，需要引导。在这里跟你分享一个方法，就是在产品原型图上齐整地加上标注：可以用数字标记，在下方注释，或是用细线引导在原型图边上加注释。

用这样的方式，将原型图中的组件逻辑和数据规则说清楚，读图者也有线索依赖，不会让一个人对着图不知所措。

如果没有交互设计师，可能产品经理还要做交互稿，交互稿要描述元素布局和交互流程，这个我不是很专业，大力推荐我曾经的同事 Heidi 多年前的一篇文章“如何写一份交互说明文档”。我后来的工作中需要做交互稿的时候，基本就是按照这篇文章来操作的，很多思路也被我借鉴到了做产品原型上。

4. 其他各种因需创建的文档

还有很多根据不同需求创建的文档形式，比如需求收集文档、需求进度文档、需求评审报告、发布通知，有时要做验收测试，还有验收测试的文档等等。在任何需要文档来规范思考、引导书面沟通、存档留底的场景中，都可以建立相应的文档机制。

总之，只要有明确的目的，而且在保证沟通效率的前提下，文档不是一个坏东西。但千万不要为了文档而文档，变成形式化的东西，禁锢了流程和创造力，就糟糕了。所以我一直提倡要会写文档，同时提倡不强制要求文档，在你认为合适、需要的时候，能写出恰如其分的文档就好。

今天我们的分享就先到这里，感谢你的收听，我们下期再见。

“如何写一份交互说明文档”
链接：http://heidixie.lofter.com/post/b8226_168d4b5

!

戳此获取你的专属海报

23 | 产品经理的图文基本功（下）：产品图例

“世间无限丹青手，一片伤心画不成。”——唐·高蟾

上次我们讲到了一些产品文档的模式，以及应用场合和特点，这部分内容实践性挺强的，好多人经常会到处找到一个“好的文档”模板，其实模板根本没那么重要，了解文档目的，能把逻辑表达清楚才是第一要务，只要你能表达清楚，不写文档，拍个短片也可以。所以跟我们之前说到一些工具软件一样，不要本末倒置。

今天我们接着产品文档的话题，产品文档中经常要用到各种图例，我们来介绍几种常用的图例，以及他们的功能特点。

1. 概念模型图

概念模型的目的是要将产品中的业务概念分门别类的整理出来，并在同时确定概念之间的关系。在复杂业务的系统中，这一工具非常重要，它是一切业务流程的基础。

抽取概念模型的过程并不复杂，但需要一些时间，我们可以首先去尽可能详细地描述系统各种场景和逻辑，然后注意描述中的所有名词。比如我们说用户可以创建账号、设置用户名，登录系统，系统管理员为其指定一个角色。

这样简单的一句话中就包含了用户、账号、用户名、系统、系统管理员和角色等名词，我们把这些名词不断地取出来，去分析他们之间的关系。

比如一个用户和账号之间是对应关系，这是就要去确定对应方式，是一个用户只能有一个账号，还是可以有多个账号，或多个用户共用一个账号。基于这个关系，可能就能长出用户识别、同账号登录互踢或子母账号管理的需求。如果再考虑账号和角色之间的关系，可能就是一套完整的权限系统。

而有的名词可能是其他名词的属性，比如上面提到的“用户名”便是账号的属性，属性跟概念之间也会有对应关系，比如是否唯一，是否可变，是否是与其他概念产生关系的“键”等等。技术可能会据此去做系统设计。

越是基础的东西，在这时越需要谨慎设计，比如有多少系统错将用户名作为主键，导致未来有用户需要更换用户名时无比复杂（我职业生涯中至少遇到过两次）。

所以概念模型的梳理最大的作用是来回答系统的根本性问题，从而可以帮助工程师设计数据结构，也帮助业务找到设计出发点。一个产品的架构扩展潜力，很多时候就受限于概念模型的设计。比如订单管理系统在最初设计中，订单和标的之间的关系被设为一一对应，那将来要多产品搭售的时候，整个产品技术团队就会无比痛苦。

概念模型图通常是用 UML 中的类图或传统的 E-R 图的结构来绘制，突出概念和关系，去询问自己每个概念实体和另外一个概念实体之间可能有的关系。

也有人会说，这样的概念模型应该是工程师在做概要设计或数据结构设计时才应该考虑的，产品经理考虑早了点。

我不这么认为，我认为这是一个产品经理和工程师需要共同关注的地带，甚至产品经理的职责更重，因为它背后更多的是业务上的前瞻、取舍和判断。工程师在设计中会讲 DDD、OOD，进而去理解和重现业务架构模型，那产品经理就更应该把业务背后的逻辑关系抽丝剥茧整理清楚。

我们在招产品经理时会要求产品经理具备“抽象和建模的能力”，其实指的就是抽象概念模型的能力。有些公司甚至会在复杂系统中设立“业务架构师”岗位，专门做这件事情，有点像传统软件行业里的“系统分析师”。

概念模型有一点偏技术，又不是一个酷炫的东西，很难拿出来做展示，而且它的作用不那么立竿见影，所以没有得到应有的重视。但它在业务逻辑复杂的产品设计中确实非常重要，希望你动手去尝试一下，挖掘它的价值，为自己所用。

2. 流程图 / 泳道图 / 时序图

所有的业务系统都有流程，我们的文档中一定会或多或少涉及“流程图”，最基础的流程图是面向过程的描述性流程图，有些图形规范，比如开始结束是圆角矩形，数据操作是矩形，判断是菱形等等，还有些其他的一些形状代表的意思。但我很少见过真的完全按照标准格式画的，基本就用到矩形和菱形，有时为了加以区分会有颜色上的差异。

但如果流程比较复杂，涉及的角色或子系统、模块多起来的时候，传统的流程图就会开始捉襟见肘，应接不暇；所以除非描述单一功能模块内部的流程外，我一般很少会用传统流程图。而是用泳道图和时序图。

泳道图很好理解，就是在传统的流程图上加入角色，因为每个角色之间是平行的，从图上看起来每个角色就像是一个泳道。通过这些泳道去标识每个动作是由哪个角色（或子系统）做出的。这种图形一般用于比较宏观的流程描述中，比如划分各业务角色之间大的流程步骤，或描述子系统之间的边界和职能。

当进一步细致到具体的用例或方法时，则可以用时序图，时序图也是 UML 标准里面的一种图示，也是面向对象设计的一种工具，本来是工程师用，后来被产品经理借来描述业务流程。

时序图整体看起来像很多根竹签，每根竹签代表用户、业务对象、子系统甚至“时间”，凡是可以向其他竹签发出请求的都可以表示为一根竹签，而有些过程是需要定时执行的，在时序图上，我们就可以将其表示为“时间”。每根竹签向自己或其他竹签发起请求，然后响应请求的竹签则根据这个请求开始一个过程，这个过程可以是同步，也可以是异步，可以是判断过程，也可以是循环。

总之时序图可以表达的逻辑非常丰富，能将复杂逻辑梳理得很有条理，而且读图成本很低，既能一目了然，也有引导按图索骥。我有一段时间非常迷恋时序图，连项目管理中的不同角色的流程安排都用时序图表达，强烈建议你深入学习一下，把它用到你的流程分析中。

3. 状态图

系统中所有的概念实体都应该有状态，用户有状态，订单有状态，账单也有状态。在数据结构设计时，经常会在业务对象表里加一个“状态”字段。产品经理有时不会将状态显式地单独表达出来，而是让工程师自己通过读业务逻辑去区分和判断业务对象的状态。

这样的沟通断层会产生一些风险，有时描述同一个状态用了不同的用词，导致工程师记录成了两个状态，比如前一条业务逻辑写的是“完成对账后系统进入休眠状态”，后一条写成了“完成角色更新后系统挂起”，这可能来自于产品经理的不严谨，结果系统里就出来一条没有必要的脏状态。

更吓人的是有时产品经理描述不清，导致本来应该是不同的状态，被开发理解为同一个，未来需要再做拆分时，难上加难。比如用户欠费挂起和用户到期挂起应该分开不同的状态，但产品经理在文档里都写着“挂起”，导致未来给用户开通服务的时候不知道该怎么直接从数据表里区分，还要去关联行为日志的表。

建议产品经理对于比较核心的业务对象，把状态画成状态图，每个节点是一个状态，每两个状态之间是一个行为，描述的是出发状态转变的可能。这么做还有一个好处是，可以帮助你从状态的角度出发，去穷尽所有状态之间可能的变化，保证不会遗漏用例。

4. 用例图

上篇文章我们提到用例文档，这里我们来说说用例图。

用例图是 UML 的标准图示，看起来特别简单，一个火柴人和一些椭圆。每个椭圆是一个用例描述，然后把椭圆和人连起来。用例图复杂起来很复杂，还有扩展点，互相之间的关联包含关系等等。但开始使用它很容易，只用火柴人和椭圆就够了。

那这么简单，甚至有点蠢的图，能干吗呢？首先是可以让读者一眼看到一个产品或一个项目需要实现的用户价值，以及它可能的规模是什么；另外则是可以利用用例来组织产品文档的结构，很容易理解，也容易作为标准来管理进度。

用例图的一个老大难问题是区分用例的粒度，这是个没有唯一答案的问题，同一个人的用力粒度划分标准可能都不同。比如 CRUD （创建、读取、更新、删除）算一个用例，还是四个用例。比如“账户管理”算是一个用例，还是“账户创建”“角色分配”“账户删除”“账户查询”四个用例。这简直是个哲学问题，这么多年我也没能找到一个金标准。

我最喜欢的标准是来自一场 UML 培训，说的是“以卖点作为粒度”，也就是设想你的系统是按功能收费的，你从兜里一个接一个地往外掏用例，每掏一个用户就要付一份钱，你要保证每个用例用户都是愿意买单的，同时，又要保证用例尽量丰富，以求收到足够多的钱。

假设你现在做“极客时间”，你从兜里掏出一个“修改密码”，用户不会认为它是个卖点。但你假设你现在做的是一个复杂的金融保险系统，很可能“修改密码”就会成为一个独立的卖点，所以用例粒度划分一定是因系统而异的。

总结

我们今天从概念模型开始，说到流程图、状态图和用例图，从表面的图讲到图背后的工具和方法，这些东西最主要的作用是可以辅助我们找到思维框架，用完整而有条理的逻辑去把一个业务描述出来。他们就像是工具箱，只有熟悉了这些工具的效用，同时又足够熟悉环境，才知道什么场合拿出哪一样工具是恰当的。

这也是产品经理的基本功，即便用不上，也不要让自己的工具箱里只有单调的几样工具，因为掌握的工具会影响你解决问题的思路，正像那句古话说的，手里拿着锤子，看起来全世界都是钉子。而这些已经被大量的前人应用和雕琢过的工具，自然带着他们的智慧，研究这些工具本身，也是一种对于经验的学习。

今天的分享就到这里，如果你有关于这些图例的具体问题，欢迎留言讨论，我们下次再见。

!

戳此获取你的专属海报

24 | 产品案例分析：PathSource的混乱与直观

PathSource 是一个关注学业和职场的应用，它的主要目标用户是学生以及一些职场新人，这款应用可以提供参考，帮助你去选择学校、专业，以及帮助你找工作。

围绕这个目的，PathSource 中提供了各种跟职业、专业、学校相关的信息和数据。其实仔细研究下来，会发现内容条理还是比较清晰的，但我觉得它整体的结构设计并不是很好，没有把这些东西很好地组织起来，好像到处都有内容，却不太容易用直觉去分辨他们的类型和结构。

导航的迷茫

这里先说一个 PathSource 导航不是特别清楚的地方。打开它的第一个页面之后，下面有几个 Icon，看起来像某种形式的导航，还可以横向滑动；而在整个结构下面，下面 Tab 的导航，两层导航。这种导航不罕见，但一般在概念上，两种导航尽量不要有交叉，否则就很容易让用户感到困惑。

你可以看一下这里的两套导航，你会怎么理解呢？我们点这几个 Icon 看一下，当我点这个的时候呢会进到一个页面，在这个页面上如果点返回，去到的不是刚才的首页，而是这个页面在信息架构结构上的上一层。

我个人不认为这是一个好的设计，这让我想起 Windows 下的资源管理器，在一个文件夹里面，会有两种回退操作。一种叫做向上，也就是打开当前目录的上一级目录。一种叫后退也就是推倒你的前一个位置。

前一种是基于文件结构的，后一种是基于路径的。这两种功能的差异在 Windows 下并不大，因为 Windows 是严格按照目录结构来管理文件的，虽然有快捷方式之类的，但它把文件结构非常明确地交代给用户。

在 MacOS 中，文件结构其实是被弱化的，我们可以去访问文档、音乐、照片，至于他们存在什么文件结构中，我们并不关心，操作系统也不让我们去关心；所以可以看到 MacOS 中只有后退前进，没有所谓的向上到上一层。当然，你可以用组合键 cmd+ 向上的箭头去到目录上一层，如果不停地向上，可能会看到一个挺出乎意料的文件结构，你可以试试。

而在互联网上，所有的内容都是基于链接的，也就是说那个“后退”动作，应该是路径的后退，而不是结构的向上。如果我们想要表现内容结构怎么办，其实是通过页面上的样式，比如面包屑之类的，去表现结构；点后退的时候，我们的预期就是回到刚才那个熟悉的页面，而不是去到一个没见过的，不在路径中的页面。

有些特别鸡贼的新闻网站，直接进入新闻详情页之后，它会篡改浏览器的后退位置。当用户点击后退时会跳到新闻列表页，而不是回到用户进入这个详情页之前的那张页面。

比如在朋友圈看到一篇新闻，打开看完之后点后退，我们本能地会期待回到朋友圈，结果它不，它打开了一个新闻列表，这样的特性，可以理解为是为了用户的留存和访问深度。但它确实是一个意料之外的跳转，体验并不好。

PathSource 这个导航，可能确实是好意。为了让用户更快速定位到这个应用中所拥有的概念，但却容易给用户尤其是新用户带来困扰。

视频的直观感染

第二点说另一个我觉得值得一提的东西，是 PathSource 的采访短视频。

这里的采访内容主要是让受访人来介绍自己的职业，目的是让学生或职场新人可以充分了解这个职业。

我非常喜欢这样的形式，这应该是这个应用的一个很大的亮点，我们虽然已经看到太多的短视频，但印象里都是搞笑的或者感人的，或者讲情怀的，似乎都是经过“设计和制作”的。

PathSource 中的视频制作并不是非常的精良，长度也不长，但却特别有价值。它能理解还没有进入这个工作岗位的人，对于这个岗位的好奇；而这样的采访视频，远比通过文字更加简单和有感染力，可以让用户获取一些对这个职业比较直接和感性的认知。

这样的内容也让这款应用变得特别有活力。我们其实有很多做内容的应用，或是一些产品中的内容模块，完全可以用这样形式的视频，来增强内容的丰富程度和感染力。不一定非要制作精良，特别系统性的视频，或许一些简短的，甚至看起来有一点粗糙的视频，只要在内容上有价值可能就很好。

最后想要特别提一下的是他的学校详情页，每张页面上都有这个学校的一些数据展示，整个页面组织得非常齐整，但并不枯燥，很多设计细节给了我不少启发，在移动端呈现大量数据，其实是一件挺难的事情。

!

戳此获取你的专属海报

25 | 产品世界的暗黑模式：操纵的诱惑

“卑鄙是卑鄙者的通行证，高尚是高尚者的墓志铭。”——北岛

2018 一开年，支付宝年度账单运营活动流程中，默认选中 " 我同意《芝麻服务协议》"，这一举动被指利用运营活动套取用户数据使用权，在社交网络引起轩然大波，芝麻信用官方随后出面澄清并向用户致歉。

在此之前，由于变着法搭售旅行产品，携程受到了一位知名女艺人的公开炮轰，之后不久携程调整了订票流程，去掉了一些哄骗用户做捆绑的机制。

类似的事情我们并不陌生，早在互联网时代的前期，各种客户端软件通过不体面的捆绑安装手段，占领用户电脑的把戏就很成熟了。

腾讯、百度、搜狐、 360 等等大厂都不能免俗，安装软件步步惊心，你本来想装个输入法，结束以后发现从杀毒软件到浏览器到防火墙甚至电子词典，一应俱全，恨不得连屏幕保护都给你顺便换掉了。

这样的例子不是中国特色，著名的职场社交平台领英 LinkedIn 一度以哄骗用户的方式拿下邮箱通讯录权限，而后对其中的好友进行狂轰乱炸，我之前有个同事不幸中招，悲剧的是公司的邮件列表在他的通讯录里面，有段时间几乎所有人的邮箱里都满是 LinkedIn 发来的垃圾邮件，气得人咬牙切齿。

产品设计的暗黑模式

这样通过网页或 App 的界面或流程的有意精心设计，诱导用户做出本不打算做出的举动，比如购买、注册、点击广告、发送垃圾邮件等等，被统一定义为“暗黑模式”（Dark Patterns）。

一位叫做 Harry Brignull 的设计师还专门创建了一个叫做 Dark Patterns 的网站，用来收集和传播这类把戏。Brignull 将各种暗黑模式分成 11 类，包括隐形费用、强制续费、垃圾邮件等等，其中有一类以 Facebook CEO 扎克伯格命名，叫 Privacy Zuckering，指的就是利用一些手段让你无意间泄露更多个人信息。

你有空可以去这个网站上看看，感受一下来自全世界的暗黑招数。不得不惊叹于一些暗黑模式设计者的聪明才智，相比之下支付宝默认勾选阅读并同意协议甚至显得非常清新。

这其实也是大部分暗黑模式设计者为自己找的借口：别人也是这么做的。当时携程搭售事件被讨论的时候，很多人觉得携程委屈，出来为它鸣不平，他们的解释就是：大部分的机票预定工具都是这么干的，凭什么要单骂携程，另外平台不是做公益，当然要赚钱云云。

这个观点逻辑非常奇怪，首先，很多人都在犯的错误依然是错误，小时候就应该知道这道理了。另外，用户反感的是各种鸡贼的隐藏搭售，而不是一个正经商人的合法利润。我们当然知道不是做公益，为什么不大大方方教育市场，用光明磊落的方式赚钱呢？

为什么不？其实这个问题的答案很简单，就是因为暗黑模式确实有效率。

操纵来自于基因

如果你仔细去 Dark Patterns 网站上研究 11 种分类，或许会发现，大部分蒙骗用户的手段都是在利用人与生俱来的一些弱点，或者说特点。

比如我们每个人都有节省脑力和体力的倾向，再说直白一点儿，就是懒，比如懒得去仔细阅读用户协议，懒得把漫长的表单一个接一个填完整，懒得仔细分辨每个按钮的文案而是直接点击最大最醒目的那一颗，我们也懒得探索订单详情里的每一个收费条目，会天真地以为在列表页看到的那个数字就是最终需要付的费用。

所以当我们落入设计者精心设计的陷阱中时，我们的第一个念头是自责，哎呀，都怪我自己没看仔细。如果你愤怒地打电话投诉，对方也会用一句：“我们界面上写着的啊，您自己没看仔细”，云淡风轻地化解。

别急着自责，这样的特点是漫长的进化带给我们的，从远古时期开始，我们就自觉不自觉地学着给东西打标签，因为事无巨细地分辨每一个细节是非常耗费能量的，我们的大脑需要建立捷径，只要这样才能在能量摄入匮乏的环境中存活下来。

想象一下，那些听到巨大的声响却不逃跑，站在原地仔细分辨跑来的是什么东西的祖先，很容易就被自然选择淘汰掉了，而那些懂得在大脑中建立捷径的基因得以幸存，所以我们会忽略写在页面底部的小字，或跳过冗长的用户协议，或直接点击那个最大最醒目的按钮。

人类眼睛的进化也遵从类似的逻辑，有一本叫做《设计中的视觉思维》很详细地分析了视神经与进化的关系，比如，我们现在望向任何方向，只有视线中心很小的区域是清晰的，其他地方都非常模糊，靠大脑的低级神经活动填充，这是视神经的结构决定的。

而这些模糊的视觉区域对应的生理结构对物体的移动非常敏感，这也很容易从进化的角度来解释，当我们待在野外时，远处突然靠近的危险需要立刻捕获我们的注意力。现代设计利用了这一点，所以互联网世界中一度充斥着飞来飞去的旗帜广告和动画广告。

对这些根植在人性中的特点进行操纵总是有效的，它诉诸于本能，可有效的设计一旦用到暗黑模式中，就像落到魔鬼手里的权杖，让人心生厌恶和绝望。

尊重和磊落的用户感知价值低

用这样的方式操纵用户，用户自然会感到不被尊重、沮丧受挫，进而流失，难道这不会让这些软件设计者们知难而退吗？很不幸，答案是不会。

迄今为止，我们很少听说大量用户因为这些暗黑模式的小把戏而放弃某个产品，转投他选。用户的选择主要会源自更优惠的价格、更便捷的操作、更熟悉的流程等等。

换句话来说，当 A 平台能买到比 B 平台更全、更便宜的机票，那么 A 平台是否会变着花样的搭售保险，或是否会偷偷地收集和利用你的私人数据，似乎就不是那么重要。即便我们感受到了被冒犯，或许还是会忍着恶心选择 A 平台。

难道我们真的这么怂和傻，面对着各种如同当面羞辱我们智商的产品形态还要奴颜婢膝地选择对方的服务吗？

其实当面对服务提供者时，我们脑子里面自然有一架天平，我们不会因为任意一个侧面而选择接受或拒绝它，我们会综合判断和比较，从而决定哪些方面的收益对我们更加重要，值得我们牺牲其他方面的收益。

在做类似分析的时候有个模型叫做“价值曲线”，这个话题我以后会找机会展开来跟你详细地分享。在这里我们只需要思考一件事，就是对于大部分用户来说，尊重和磊落，并不能成为相对重要的价值。

这样的价值判断是主观的，我们就用整改前的携程来举例子，如果有一天携程去掉所有的搭售，轻轻松松一键就可以订到最合适的机票，但所有的机票价格比原来上浮 100 块钱，你会愿意吗？上浮 200 呢？如果与此同时，去哪儿保持机票价格不变，却暗藏各种操纵性的猫腻，你又会怎样选择呢？

无意奉承，我相信能读到这些文字的你，或许会说尊重无价，愿意为一个道德水准更高的产品付出更高的费用。但市场竞争的结果已经告诉我们，大部分的用户其实并不是特别介意，他们甚至不会把它上升到“尊重”的高度来考虑问题。

不成熟期的劣币逐良币

我用类似的问题问过不少人，我说你看这个产品这里会不怀好意地默认选中发送邮件资讯的选项，你会反感吗？如果有一个其他功能一模一样的产品，只是这里没有这个默认选中，你会不会选择后者？

我得到的答案都不温不火，很多人会勉强反感一下，更多的人则是无所谓的态度，同时大家都会很无奈地表示，这难道不是行业潜规则吗？

这让我想起锤子科技早先的一系列产品设计，完全从尊重用户知情权和隐私的出发，整个产品几乎没有道德瑕疵，这样的特点即便在面对精英用户时，似乎也没有构成一个足够强的卖点，而只是一个不错的有传播性的话题。

但这样的克制和磊落却势必会导致服务提供方的利益受损，比如无法利用垃圾邮件制造更大范围内的传播等等。在同样的功能特性面前，一个尊重客户的，具有美德的产品，却处在了竞争劣势之中。

作为一个产品设计者，这样境况让人有些难过，这意味着在很多情况下，选择的天平会被利益所驱动。就像北岛的那句诗：“卑鄙是卑鄙者的通行证，高尚是高尚者的墓志铭。”

除了大肆鼓吹尊重用户的设计，抨击那些暗黑模式，或像 Harry Brignull 一样把公开羞辱这些设计之外，似乎并没有什么系统性的解决方案。还有别的希望吗？

我想希望就存在于这个行业发展的未来，当混战期过去后，行业变得更加成熟，竞争不再像现在这样粗放，用户的基本需求已经被满足得很完善之后，尊重才会显得愈加重要。

正如同早先的餐饮行业关注的是能不能吃饱，没有人关注口味、卫生和服务，而随着行业和用户的发展，如今我们挑选餐馆时精神和心理的满足感变得越来越重要，当然也一定会选择那些不在菜单和用户协议上动手脚的餐馆。

这样的状态还有赖于充分竞争，设想一下如果天下只有一家餐馆，那么所有的比较都不再有意义。好在庞大的需求量和天然的地域区隔拦阻了餐饮行业的绝对垄断，可是对于万物互联的网络呢？未来会不会产生垄断，垄断会不会带来更多的暗黑模式？

甚至有一天巨头不必再装模作样地掩饰自己的企图，利用垄断地位提出不容辩驳和选择的诉求，比如直接去掉“我已阅读并同意《用户协议》”前面的复选框？

怎样阻止这一天的到来？至少当他们开启暗黑模式时，我们应当表达愤怒和抗拒，而不是当做某种惯例，悄无声息地任它发生。

没错，我指的不光是产品设计。

总结

我们今天从复选框说到互联网的暗黑模式，也分享了一些关于用户价值判断的东西，以及我对这个问题的看法、我对未来的希望在哪里。

如果你对这个问题有一些观点的话，请你给我留言，我们一起讨论，谢谢你的收听。

!

戳此获取你的专属海报

26 | 写好产品文档的诀窍

“产品文档是产品经理交出的第一个产品。” —— 邱岳

我们之前的两次分享，聊到了产品文档以及图例的类型和作用，当时我说文档也是产品经理设计出来的一种“产品”，所以做好产品文档的诀窍其实跟做好产品的诀窍一脉相承，也讲究用户、场景、目的和体验。接下来我就结合自己的经验，跟你分享写好一份产品文档的诀窍。

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

第一次写产品文档的时候，我拿来文档模板就开始照葫芦画瓢，模板上有什么就写什么，好像只要把模板中所有的空位填满就能写出好文档了。

其实不然，好的产品文档应该有非常强的针对性。就像做产品要先明确用户一样，写产品文档的第一步就是要明确文章的目标受众是谁。知道谁是文档的主要受众或者读者，结合他们的思考维度，才能知道该用什么样的语言、逻辑和形式。

之后，我们是要清楚每个文档的目的，而不是把写文档本身当做目的。去设想一个文档的读者在读之前的状态和读完之后的状态，你希望他能获得什么信息，做出什么决定，以及有些什么后续的动作。

弄清楚受众和目的之后，你就可以判断用什么形式来呈现文档，是静态的产品原型，动态的 Demo，一张流程图，幻灯片还是一篇 PDF 或一封邮件，大概是什么长度等等。

比如 BRD 通常面向管理层和业务部门，目的一般是要获得支持和授权，申请到足够的资源，那就应该避免说产品实现细节，不要用技术的语言，而是从潜在的市场机会和风险解释要做什么，文档的形式可能是幻灯片。

幻灯片也分阅读型和演讲型的，阅读型要把逻辑写下来，演讲型则写提纲或放图，通常要准备两份，因为很多时候是既要做演讲，也有时候是发邮件的。

而 PRD 通常是面向工程师，让他们知道要做什么，以及为什么做，进而驱动他们设计和实现具体功能。PRD 通常是写成文档，PDF 或者写在 Wiki 上（建议不要用 Word，很多工程师如果不用 Windows 系统，排版会失控），工程师不喜欢长篇大论，最好能图文并茂，如果有机会能给现场给他们讲解一下，就更好了。

2. 知其所以然，然后知其然

在面向职能部门的文档中，目的主要是为了推进执行，所以很多人只在文档中交代其“然”，不交代其“所以然”。比如只告诉开发要做什么功能，只告诉运营要推什么入口，却不交代为什么。很多文档模板里有“项目背景” 一项，结果产品经理只是随便写一两句话就算充数。

这是个非常糟糕的习惯，有句话叫做：“想让人造船，应该先激起他们对大海的向往”，执行层面的策略如果不能跟宏观的判断一脉相承，就很容易在落地的过程中走样。

另外交代背景和原因还有个好处是可以得到职能部门的建议和反馈。没有人比一线的工程师更了解系统实现，他们或许可以给你更好的解决方案。

比如我曾经设计一个订单项的排序规则，目的是为了让销售可以更灵活地安排订单行的位置。我把场景讲给工程师听之后，他给我做了一个直接用鼠标拖动排序的功能（那个年代这个交互效果在 Web 上还很罕见）。

3. 打造良好的阅读体验——金字塔原理、逻辑及格式

文档的阅读体验也非常重要，有的文档逻辑杂乱无章，东一榔头西一棒子，不忍卒读。要保证文档的可读性，不能随性起笔写到哪儿算哪儿，而应该有提前的谋篇布局。

有个著名的方法论叫金字塔原理，就是从一个论点出发（通常是文档的目的），找到支持它的三到五个方面，每个方面再向下拆分，形成一个逻辑上的金字塔。每一层的拆分都要尽可能保证观点是相互独立，同时又完全覆盖的。

写文档就是一个不断拆分，再向上合并的过程。比如我们举个常见的例子，现在要给 ATM 机写 PRD，首先第一层拆分是 ATM 机的不同角色，用户、维护管理人员、系统（有时我们会将系统也当做一个角色）等。

从用户这里拆分下来，有存钱、取钱、汇款、账户管理之类的用例，继续从存钱这个用例去拆解，可以分解出“校验身份，完成取款，退出系统”的主流程。

如果我们看“完成取款”的流程，可以继续拆到“用户输入金额，系统从账户上扣款，系统吐出钞票，用户取走钞票”的具体交互步骤，任何一个交互步骤又可以长出各种分支流程，比如系统扣款失败，或者扣款成功后，吐出钞票失败等等。

如果像写故事一样，想到哪里写哪里，这就很容易遗漏关键流程，也会让读文档的人陷入混乱，不知所云。对于上面的拆解过程，我们通常的做法是：对每个角色给出一系列用例，每个用例有一个用例文档，用例文档中先描述正常流程逻辑，然后单独描述正常流程每个节点上可能出现的异常情况。

在文档描述过程中可能会出现一系列商业规则，比如取款每次不得超过 3000 块钱，每天每张卡不得超过 20 万等等，这些规则在流程中即便阐述了，也最好可以单独在某一个地方列出来，一来方便工程师查漏补缺，二来也方便测试时去设计测试用例，提高效率。

最后还要重点提一下格式，好多人写文档完全不注意格式，包括字体排版之类。虽说这不是关键，可还是建议处理处理，不一定要多好看，起码看起来易读一些，比如增加一点段间距和页边距，该对齐的对齐，该加粗的加粗，这是文档的第一印象，最好还是正儿八经收拾收拾。

4. 先写厚，再写薄

写文档通常不是一蹴而就的，写的过程也是整理思路，查漏补缺的过程。所以一开始的时候可以尽量多写一点，然后不断重读，不断裁剪、重构、修改和调整。可能在写主流程的时候会突然意识到遗漏了分支流程，那就立刻写下来，等到修改的时候再把它摘出来放到分支流程的文档结构里。

另外是写的过程中可能没注意遣词造句，会写得比较啰嗦，或存在二义性。这些都需要在修改的过程里不断地提炼，这个过程跟写作很像，都是先堆后理，先厚再薄的过程。

在堆和理之间，可以尝试引入一个“冷静期”，我在之前的文章中提到过，我会建议同事在写完文档后不着急定稿和评审，而是搁置在那里，放一晚上，睡一觉或者忙一点别的事情之后，等思路开始从深陷其中抽离出来了，再把文档翻出来重读和修改。我们把这个过程叫做文档的发酵。

当你全力写的时候，很容易陷入在写作者的角度抽不出身，有些东西会在你脑子里，但没有落到文档中；而文档的写作最主要的目的还是为了读，当你放下文档晾它一会儿，重新再捡起来的时候，你会更容易站到读者的角度。

另一个更简单的办法是把写出的文档给熟悉的自己人先读读看，获得一些从读者角度来的反馈。就像白居易写完诗会念给隔壁大妈听一样，这也是一个精进文档写作的方法。

我以前偶尔会把初稿文档发给我媳妇让她帮我看看，一来她之前在业务部门工作，大概能理解业务，二来她不太会担心我的自尊心，会比较直接地指出她看不懂的地方。

总结

正如同我们做产品的套路一样，我们从用户、场景出发，通过挖掘文档读者的需求和背景来撰写文档。强调了文档逻辑结构的完整和条理，最后又一次建议你不要急于求成，写好的东西放下来冷静发酵一下，进行一个二次加工。

我们今天的分享就到这里，你在做产品文档的过程中有没有什么心得可以分享？欢迎在留言区讨论，谢谢你，我们下次见。

!

戳此获取你的专属海报

27 | 产品案例分析：Quartz&Hooked的对话式交互

Quartz 是一款新闻应用，这个应用跟普通的新闻应用差异很大，它是完全基于对话的。

聊天式界面的黏着力

我们打开它的第一感觉像打开了一个聊天界面，看到聊天界面的时候，你的第一感觉是什么？可以体会一下，我也是最近才发现，自己在看到一个微信聊天的时候，是会有本能反应的。最近越来越多的广告和线下活动的海报上，会用聊天记录作为图片，聊天的内容就是营销的内容。

我有一次在看一个长长的列表时，本能地盯住了其中一个聊天界面的图片，然后仔细读了一下，读完才反应过来，这个过程几乎是下意识的。当看到聊天界面的时候，似乎开了自动挡，眼睛钻进去读里面的文字。

所以你可以再回忆一下，打开这个应用之后你的第一反应，很可能也是像我一样开了自动挡，去看文字，这个反应究竟是为什么，我没有找到很完整的分析。

我自己的理解是两个方面。一个方面是我们的阅读习惯已经被手机和即时消息应用切分得非常细碎，每天在微信或者短信中进行大量的练习，已经在脑子里形成了思维模式和肌肉记忆。所以一旦识别到对话界面的模式，就会自然而然地开始从上往下读内容。

另一个就是人性有比较阴暗的一面，我们可能会下意识地认为这是别人的聊天记录，而聊天场景又很私密，可能会激发我们想去偷看的欲望。

模拟人类的对话感

你可以看到 Quartz 中的新闻，它不会是在一个气泡里把所有的内容都写完，而是会分成好多句话，为什么这么做？

这其实也是在模拟我们的聊天对话场景。读起来的负担非常轻，还有循序渐进的这种感觉。我们去看里面的内容，完全也是模拟聊天的语气，像是一个人在告诉你什么事情，连信息出现也不是一下出现很多条，而是模拟一个正在输入的效果，再出现内容。

现在 AI 很火，我们都知道有个很大的领域就是人机对话。人机对话的应用很多时候是在这里放一个对话框，你可以随便打字，或者说话，这是个对算法能力要求极高的暗示，因为在框里我们可以输入任何东西。就像在 DOS 时代，打开操作系统，C:>_ 一个提示符，暗示你可以随便输入任何东西， 但其实你只有输入一些系统能识别的指令才能有反应。

人机交互机器人其实也是一样，目前算法很难像人类一样跟你唠嗑，它可能只能对特定的内容和领域反应很好。你看 Quartz 中，对人的互动预期是有管理的，只有选项，通过对选项的设计，有一些人情味，是一些不同的短语，或者表情，让你不至于觉得乏味。

接下来我们在看 Hooked，这个应用也是基于聊天体验的，它是一个对话式的小说 App，在去年一度超过 SnapChat 冲上 App Store 的榜首，活跃度非常高。它的理念就是设计一个移动优先的故事分享平台。

建立在对话模式上的小说阅读

比较有趣的是，我以前读到这个公司创始人的一个采访，她说当时做了一个测试，让年轻人在手机上阅读，找了一些特别引人入胜的小说，长度大概是一千个词，结果发现最好的情况下，只有三分之一读到了最后，后来她把这种小说改成了这种文本消息的展示方式，几乎所有人都读完了。

你可以看到这个应用是把故事建立在对话中的，通过对话去推进故事的进展，而阅读体验是极其碎片的。读一句话，然后用产品形态去隔开，顿一下，切得很细，但这样确实非常容易沉迷，尤其故事中充满悬念的时候。

它的付费模式也很容易让用户接受，按照一定的阅读时长做限制，读到一定时间之后，就不让你读了，过一段时间才能继续读。

我第一次试用的时候，看的是一个悬疑故事，看到一半被卡住了，因为我知道自己以后也不大会用，就没买，干等着冷却时间过去，那段时间非常煎熬，几次有冲动充钱进去。

对话式交互怎么用

说到这里，我们会想，既然这么好，是不是我们也应该把自己的应用改成这种纯对话式的交互。不要这么极端，对于已有的应用，全盘推翻不是个好主意，但可以在一些需要跟用户循序渐进交互的过程中，使用这样的方式。

我以前看到过一个应用，但现在实在想不起来是哪一个了，就是用这样的对话的方式来做新人引导，很像 Quartz，说一句话，然后你按一个键反应一下，再说一句话，让你了解这个应用是做什么的。

其实对产品经理来说也是一样，比如做一个新人引导，或者一个表单提交，都可以改成这样的方式，在局部利用这样对话交互的优势。另外，最不济，可以学着在营销中用这样的方式去提高转化率。

!

戳此获取你的专属海报

28 | 产品分析的套路（上）：谁是利益相关者？

“自小秦楼望巧，吴机回锦，歌舞为谁。”——（宋末）刘辰翁

在平时做产品设计的过程中，产品经理会从各个地方收集到大量的需求，也会产生许多关于产品的新想法。

在面对这些琳琅满目的需求时，我们需要一个套路，对需求进行快速地分析和决策。我自己常用的套路，就是反复地思考一句话，这也是今天想要分享的主线：“用什么方法，解决谁的，什么问题”，其中三个关键点分别是：“用什么方法”“谁的”以及“什么问题”。

这三个问题的思考顺序应该是：“谁的”、“什么问题”，最后才是“用什么方法”，今天，我先分享第一个，也是最重要的一个要素，就是：“谁的”。

利益相关者，不只用户

首先，“谁的”是了解需求背后主体的过程。每个产品背后都会有多个利益相关者，也就是我们常说的 Stake Holder、涉众。

我们平时最容易关注到的利益相关者可能是用户 —— 也就是产品的直接使用者；但对于产品经理来说，我们不能只关注用户，产品经理的段位高低，很多时候取决于能看到和平衡利益相关者有多少，对他们的了解有多深。

比如在电商领域中，我们要关注作为产品上游的供应商、仓储、物流等等。比如，在医疗行业中，可能有患者、医生、医院、药企甚至一些学会和机构等等，都是我们需要关注的利益相关者。

除此之外，当评估整个产品的效率和盈利能力时，我们还要学会站在投资者的角度去看问题。这是一个很大的话题，从投资者角度所关注的具体指标去看产品、服务，是一个产品经理有没有完成进阶的标志。

需要注意的是，这里的投资者关注的或许不仅仅是财务指标，还有整个产品的健康程度和存续指标。比如一款工具的日启、日活、留存、传播，或者社区型产品的用户数量，用户之间的关系数量等。

可能有朋友会说，我是一个创业企业、小团队，我还没有投资者这个利益相关者。其实这里的投资者算是一个代称，所指就是要对一个产品或者服务的存续、健康和效率负责的那个角度，当然，最直接的就是财务指标。

除了刚才提到的这些容易被漏掉的利益相关者之外，产品经理最需要关注的依然是用户本身。

我们经常提到产品经理的“共情能力”，其实指的是对用户立场和偏好的深刻理解，理解他们的关注点，并把它们变成指标。

这个过程有一些工具，比如做用户角色分析（也就是我们会提到的 persona）、关键人物地图等等，它们是做用户研究的一些基本功。这些对角色的理解除了对单一功能点的分析很有价值之外，也对我们后面会提到的，合理排定需求优先级有决定性的影响。

不论是用户还是其他利益相关者，我们需要了解他们对哪些事情最为关心，不同的角色关心的指标或许会有关联，甚至有矛盾，产品经理要在其中做出平衡和决策。

To B 和 To C 的不同决策方式

想特别提一下的是，通常面向消费者的产品，也就是我们平时提到的 To C 类的产品，考虑利益相关者的套路跟面向企业用户（也就是 To B 类产品），是相差很大的。

对于 To B 类用户，做出购买决定的人、影响决定的人和使用最终产品的人、甚至是掏钱的人可能都是不同的，他们在购买决策链上的角色和作用，以及发生作用的时机也是不同的。 To C 类产品通常是一人一票，只要打动一个用户，就会投一票，一票就是一个实打实的 deal。

我们许多人可能都见过那种界面超丑又特别难用的银行系统或者医院系统。这种系统的产生有时就是因为类似产品购买决策链上没有具体终端的使用者，或者他的话语权弱一些；当然，也有可能“视觉和交互体验”并不是这些人的核心问题。

你可以思考一个问题，如果再做一个医院的管理系统（HIS 系统），这个系统提供更加先进和优雅的人机交互界面，可以击败现有市场上的其他产品吗？如果做的管理系统不是为医院服务，而是诊所呢？这两个问题听起来似乎很像，但答案或许是不同的。

在医院中，负责采购系统的人可能并不真正使用这些系统，他们会更在意系统是否安全，是否稳定，系统服务商的口碑好不好，甚至是价格合不合适；而小诊所里，做采购决策的人可能就是系统的直接使用者，对他来说，系统的易用性可能就会是一个需要特别关注的方面。

上下游特点与平台价值

对于市场容量比较大的 B 端客户，我们的思考方式和市场容量比较小的 B 端客户也是不同的。这里的市场容量指的不是财务市场的大小，而是玩家数量的多寡。通常 B2B 平台型的产品会偏向于认为市场容量越大、越散，玩家越多，平台越有价值。

这个结论背后逻辑是，当交易其中一方相对集中时，通常意味着该方在交易中掌握更大的议价权，任何一方的相对集中都会导致中间平台退化为其代理。

比如我们想象一个桔子交易市场，如果卖方非常集中，只有一家，所有买桔子的人都要从他手上购买桔子，那他拥有绝对的桔子定价权。

想象你现在要做一个桔子交易平台，你的上游是这唯一一家桔子供应商，你是很难对他有控制力或影响力的，最终你将退化为这一家供应商的代理或技术服务公司，帮助其向下游销售桔子，此时可能你只剩下技术价值，没有平台价值。

现在设想另一种情况，倘若卖家和买家都很多，卖家之间互相竞争争取买家，买家有各自的性格，有人喜欢个头大的，有人喜欢水分多的，有人喜欢便宜的，他们为了买到心仪的桔子需要对比、甄别、挑选，耗费很多心力。

这时，你决定做一个桔子交易平台，把买卖双方都搬上来，卖家可以在这里展示自己桔子的特点，平台提供不同维度的信息筛选机制和认证机制，买家则可以通过这些机制找到自己喜欢的桔子，买卖双方还能够在平台上留下自己的信用记录。

如此一来，平台价值就逐渐地显现出来，正是由于你创建的桔子交易平台，桔子交易成本被大幅度降低，买卖双方都很开心，甚至都有为此付费的意愿。平台也就逐渐掌握了桔子交易市场上的议价权。

我们顺着这个例子再思考下去。如果，平台充分竞争，有一个桔子卖家，假设名叫小池柑桔，以质优价廉，服务周到逐渐占领了市场，吞并了其他卖家，逐渐成为了桔子交易平台的寡头。他的桔子出货量、交易量、收入和利润，都占据了整个平台的较大比例。

最早由于规范上下游的分散而形成的平台价值，会开始逐渐式微。买家到平台来不再根据自己的喜好筛选桔子卖家，而是直接进到小池柑桔的店铺里去买桔子。这时，你作为交易平台方，会怎么想？怎么做？

是顺应市场竞争规律，任由小池柑桔形成垄断？还是杀富济贫，用平台规则和制度打压小池柑桔，扶持其他中小桔子卖家，维护上下游的分散，保持平台价值存续？如果这时出现了其他的桔子交易平台跟你竞争呢？试着从这个角度去理解平台价值，或对平台类的产品做一些观察和分析，或许你会有些有趣的发现。

总结一下，今天，我讲了产品分析套路中“用什么方式，解决谁的什么问题”中第一位的“谁”，“谁”的问题远不止我们平时说的产品用户这么简单，我们需要考虑跟产品甚至生意相关的每一种可能的利益相关者，以及对利益相关者全方位的理解，去分析和理解他们的处境。

最后我们稍微岔开了一下，简单聊了聊平台型产品的思考方式和观察维度，希望可以给你带来一点启发。欢迎留言讨论，我们下次再见。

!

戳此获取你的专属海报

29 | 产品分析的套路（中）：解决什么问题？

“能帮助我们完成进步的，恰恰是人类的天性本身。”——弗朗斯·德瓦尔《共情时代》

上次我们提到产品分析时的套路就是反复思考：“用什么方法，解决谁的什么问题”，思考的路径应当是先考虑利益相关者，再考虑问题和方法。之前我们分享了如何对利益相关者进行列举和分析，今天我们来关注第二点：“解决什么问题？”

搞清楚相关人都是谁之后，我们要考虑的第二个点就是“解决什么问题”。所有的产品和平台的存在，一定都是解决了一个或多个问题。比如 Google 解决了搜索效率的问题、淘宝解决了买家购物效率的问题，还解决了卖家销售效率的问题。

重视解决的问题，而不是解决的方案

产品要做的任何事情，都应该围绕着某一个或某几个利益相关者的具体问题来展开。很多产品经理在这里投入的精力和时间是不够的，大家更喜欢花时间在解决方案上，也就是后面会提到的“用什么方法”上面。这样不妥，应该在理解谁的问题，什么问题之后，才去想解决方案。

这种错误也被称作 X-Y Problem，也就是，我们希望解决 X 问题，然后想到了 Y 方案，随后把所有的精力放在 Y 这个解决方案上，而忽略了对要解决问题本身的理解。 映射到我们的日常工作中，产品经理接到的需求通常不是真正意义上的“需求”，而是提出需求的人，基于某一个需求提出的“解决方案”。

我们举一个例子，比如用户提出所谓的需求——“希望增加收藏功能”，如果你只是拿到这个所谓的需求，画个原型，让开发做出来，那么你最多是一个需求翻译和分发的机器，而不是一个产品经理。

正确的做法应该是：把类似的所谓需求当做一个线索，抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。我们之前关于需求变更的分享中曾经提到利用“五问法”，来挖掘需求背后的需求，就是穿过解决方案抵达问题本质的好办法。

比如关于收藏，不同形态产品的收藏功能背后要解决的问题是不同的，浏览器的收藏可能是为了重复访问，所以演化为书签；阅读工具的收藏可能是为了日后检索，所以需要准备标签和检索功能；社区的收藏有索引和聚合功能，所以很多社区的收藏增加了发布和分享功能，成了另一种 UGC。

把自己放进场景，吃“自己的狗粮”

另外，在理解各种利益相关者的需求动机，尤其是用户的需求动机的过程中，有一个非常重要的概念叫做“场景”。我们常说场景是需求的灵魂。也就是我们在考虑需求时，不应该只是孤立地考虑功能逻辑，而应该把这些功能和流程放到具体的用户使用上下文里面去。

场景这个词来源于戏剧和电影，包含了时间、空间、角色等等许多因素。在考虑功能特性的时候，我们得把自己放到实际场景中去。

我之前经常给同事举过一个例子，就是现在很多 ATM 机是有免卡操作功能的，你可以不用带银行卡就能取款或者查询余额。结果有这样功能的 ATM 机很多时候是锁在一个必须刷卡才能打开的 24 小时银行房间里的。我们试着去模拟一下这个过程，到细节里面去，在脑子里演一遍，就会发现问题。

把需求放在场景中考虑最好的办法是在脑海中把所有的功能过程演一遍，充分地把自己带入，把每个细节都摸到。闭上眼一步步地演进，考虑具体利益相关人的情绪、关注点、好恶，以及所处的环境，所用的终端等等。

我们一般认为，为自己做一款产品是一件相对容易的事情，许多做产品的书也提到建议产品经理“吃自己的狗粮”，也就是成为自己产品的重度用户。

这是因为当你成为自己产品重度用户后，就压根不需要演的过程，不需要“带入”“模拟”或者“共情”之类的过程，便可以全然沉浸在产品的使用场景中从而发现和理解问题。

这里有一个有趣的概念叫“共情”，共情也叫“移情”或者“投情”，大概就是“设身处地”“感同身受”的意思。

一个很著名的研究动物和心理学的科学家弗朗斯·德瓦尔有一本书叫做《共情时代》，把共情这个事情做了很深的剖析和解释，他认为共情是人甚至动物的本能。这跟达尔文和道金斯的观点其实是有些相悖的，是一本很有意思的书，也是一本挺温暖的书，在这里顺手做一个推荐。

转益多师，加深对场景的理解

另外，关于场景的理解，我还推荐大家可以去看一些编剧相关的书，看看编剧是如何构建和表述一个场景的。甚至是一些漫画书，我曾经在公众号中介绍过一本叫做《以图代言》的书，你在有空的时候，也可以去看看，总之所有叙事类的文字形式都会关注场景的描述和构建，可以借鉴。

之前在聊对利益相关者分析的时候，我们提到过用户角色分析、关键人物地图，这些都是来自于一个叫做“服务设计”领域的工具，这些工具可以给出很多解决体验问题的思考框架，在理解场景的时候，我们可能还会用到其中比如用户体验地图、服务路径、问题卡片之类的工具。

对于服务设计，专业做用户研究的人应该会有更深刻的理解，我也只是知道一点皮毛，你如果感兴趣的话，可以去网上搜“服务设计工具”，或者搜英文 Service Design Tools，找一些相关的东西来看，这里有个网站可以作为索引。

（链接:http://servicedesigntools.org )

对于除了用户之外的其他利益相关者，比如投资人，供应商等等角色，最好的办法也是把自己放到他们的角色上，了解他们每天的工作、绩效考核标准、最关注的事情、最怕的事情等等。就像了解男女朋友那样了解这些利益相关者，最终才能做出全盘的平衡。

有时候我们因为习惯了某种流程，所以并不觉得流程中存在问题，比如我们在专栏开始时聊到关于验证码的分析，当我们都习以为常的时候，问题可能就会被掩盖。

有人说世界是不忿的懒人推进向前的，指的就是那些不断对现状表示不满，而且不断试图用新的方案简化问题解决路径的人。所以当我们希望发现问题的时候，不妨激活自己不忿和混蛋的那一面，做一个对现状找茬的人，会更容易发现问题。

好了，我们这次的分享就到这里，接着上一篇对利益相关者的分析，这一篇我聊到了如何针对不同利益相关者去发现问题的一些方法和方向，不妨在留言中说说你是如何发现问题，尤其是如何发现那些你并不了解的人面临的问题，我们下次再见。

!

戳此获取你的专属海报

30 | 产品案例分析：Primer的扑克牌交互

今天还是打算从几款应用出发，跟你分享一种目前很流行的交互形式，以及它在各种领域的应用。

这种交互方式看起来很像在玩儿扑克牌，所以我们就姑且管它叫扑克牌交互，这其实也是卡片设计的一种，所以单独拿出来说一说。

我们从 Google 出品的一个叫做 Primer 的说起，Material Design 是 Google 发布的设计规范，卡片是其中很重要的一个元素，所以我们可以看到 Google 官方的很多应用中都有卡片设计，Primer 就是其中之一。

自然接受的暗示

Primer 是一个技能学习类的应用，通过卡片去介绍和讲授一个独立的话题。它还会要求用户登录，以便做个性化推荐，说实话看到这个要求的时候我脑海中一闪而过，觉得 Google 就是这个时代的老大哥。

我们来看这个应用，结构非常直观简单，Lesson 和 Lesson Sets，Lesson 包含于 Lesson Sets 中，安排很直观、很好理解。一个课程中有说明性卡片和互动式的卡片，这些分类用户是不需要理解和区分的，很自然。

在整个课程推进的过程中，我们要做的就是读内容，翻卡片，卡片会随着手的方向被推走。可以看到有的卡片是一张，有的是一叠。如果我们去分析，会理解一叠是一个知识点，一张是一句话，但在用的过程中，我们很自然地就会接受这个暗示。

独特的信息展示

这里有一个我特别喜欢的交互和信息展示结构，是当我们两个手指缩放的时候，你可以看到完整的课程结构，当然有一些灰掉的是还没有看到的，不能点开看，要循序渐进；但这里把水平和竖直两个方向都利用起来。

我之前在不断探索各种可能的信息关系怎么展示的时候，我有一次做梦就梦到过一个类似的结构，但我梦到的是三个维度的，也就是还有纵向，后来看到 Primer 这个结构的时候，我还挺高兴的。

在我们不断学这些内容的过程中，还有一个值得关注的交互，就是这个 App 会拦住你不断翻卡的过程，让你去做题，这个交互很像是在学校上课考试。而且有一些题目其实是告知的过程，总之，通过让你做选择，强制你思考，而不是开自动挡一张张划卡。

类似的卡片应用

类似这种卡片的应用也很多，比如 Tinycards，这是一款教育类应用，正面是题目，反面是答案，利用卡片的正反面，可以背单词学东西。

Swiipe 则是利用卡片交互来读新闻，右划收藏，左划则不感兴趣，点进去就可以读到新闻的内容，整个过程也是基于卡片来制作的。SweatDeck 则是利用扑克牌健身，也是基于翻卡牌的交互，每个扑克牌都是你需要做的动作。还有 Tinder，跟 Swiipe 类似，是一款卡片交友的软件。

我们利用扑克牌的交互方式不断地推着用户做事，基于这样的架构，人的操作会非常自然，这样的交互下，内容也被划分零碎，用户接受起来不会有那么重的负担。同时，你也可以思考：自己平时熟悉的内容应用，如果改成扑克牌操作，跟现有的传统架构相比会有哪些差异。

!

戳此获取你的专属海报

31 | 产品分析的套路（下）：如何出解决方案？

“知到蓬莱难再访，问何方法得长生。”——（唐）唐求

我最近的两期分享，都在围绕着一句话，就是：“用什么方法，解决谁的什么问题”，前两次分享，我们分别介绍了如何找到利益相关者，以及从他们的角度抓出面临的问题，这一次，我们终于可以开始考虑解决的方案了。

我接触过不少产品经理，很多时候，给出解决方案能力的重要性在整个产品经理的能力模型里面其实是被高估了。但这并不代表我认为出解决方案不重要，恰恰相反，解决方案是一个产品设计者最终输出的东西，你的一切思考、平衡和执行，都会在这里被体现出来。

另外，出解决方案也是产品经理硬技能被体现最多的地方。比如你会不会用 Axure，会不会用 Photoshop，懂不懂领域建模，能不能写出漂亮的文档，以及用各种图来分析流程、逻辑关系等等。

产品经理设计的方案既包括流程上的、逻辑上的，也包括交互和体验上的。提高出方案能力的最好方法就是大量把玩各种各样的互联网产品和服务。但要注意一点，这个把玩的过程不应该是随便用一下、体验一下就完了。

所谓内行看门道，外行看热闹，产品经理需要通过看到特性就能理解背后的问题、用户，尽可能地去抽象考虑同样的问题还有哪些不同的方案。见得足够多了，理解得透彻了，自然出方案的能力就相应地增强。就像一个工具箱，工具越是丰富，你面对问题时就越是游刃有余。

有人会说，这不是纵容抄袭嘛，其实并不是。你可以看我之前在专栏里关于抄袭的分享，在这个行业中，方案和手段上的创新机会并不多，真正困难的是挑选和平衡。另外就是再提醒一遍，不要陷入 X-Y Problem 中，不要忘记要解决的问题和要达成的目标。一旦我们执着于解决方案，就很容易变成一个不合格的产品经理。

我想起一个小故事，有个肥皂厂，因为生产线的问题总是会出现包装盒里没有肥皂的现象，大厂的产品经理解决这个问题的方法是花费很多精力做各种探测装置，在生产线末端去分拣没有装进肥皂的包装盒。

另一个小厂的产品经理没有这么多资源，灵光一现想到了一个办法：弄了俩电扇在生产线旁边儿呼呼猛吹，把那些没装肥皂的包装盒全都吹到一边去，留下没有问题的肥皂盒。虽然，后一种方案未必就一定比前一种方案好，但这个故事还是可以给我们一些启发。

我们互联网产品经理主要是做产品功能设计，所以有时候会本能地想通过做功能解决一些问题，就像我们聊工具的时候提到过的，手里有一把锤子，看到满世界都是钉子，其实产品经理还要学会通过改变业务规则、流程，甚至利用财务手段去解决问题。

比如优化退款流程体验这样的事情，我们可以在经过一些的数据分析之后，去承担一些潜在的财务风险，你可以去研究一下各大电商平台的退货退款流程，很多地方都是在用财务手段优化体验。比如多少天内无条件退款，或者高等级用户闪电退款之类的功能。

这样的优化不是通过把表单设计得更简洁更美观，或者减少提交退货的操作步骤之类的功能完成的，而是抓住了退款体验的核心，用业务的方式解决问题。

关于产品方案设计还有一个非常值得学习和借鉴的领域就是游戏设计，游戏把很多人性的东西利用得很好，做游戏设计和策划的人也都很厉害，有不少做游戏策划的高手把自己游戏设计的经验总结出来，也出版了很多书，比如《游戏改变世界》，还有图灵出的《游戏设计的 100 个原则》、《通关》等等。

我自己不喜欢打游戏，但确实从这些书里学到了不少有价值的东西。比如很多游戏设计的点和原则，这些内容单独拿出来放到产品里其实都会非常有力量。我在自己产品的小特性里有时候会用一两个这样的小花招，其实挺有意思的，后面如果有机会再单独聊。

再分享两个比较有意思的经验。一个是我们需要特别拿出精力来设计“第一印象”，我曾经在团队内部的分享中提到：“我们要拿出一半的精力来打造良好的第一印象”，虽然没有那么夸张，但我们还是要花足够多的精力去关注。

比如第一次打开 App，用户第一次发布内容，第一次尝试支付等等。这背后的心理学依据叫做“首因效应”（primacy effect），就是人们会根据最先得到的信息快速地做出判断，就像认识一个人一样，第一印象基本决定了全部印象。

另一个是破除知识的诅咒，所谓知识的诅咒是指由于你掌握了某种知识，所以无法假装自己不知道这些东西，并重新回到无知的状态，就像被诅咒一样。在产品设计上，通常就是产品经理或者设计师在某种路径或逻辑上沉浸太久，非常熟悉，以至于无法发现其中的错误和遗漏。

传统的用户研究流程会用可用性测试来应对这类问题，这里给你介绍一个成本低很多，效果还不错的方案。就是去找一个不相干的同事，最好比较细腻，而且比较外向，创造一个比较放松的条件，让他来体验整个流程。

我们团队里经常会让行政、HR、法务和财务的同事来做这样的测试，不断地问他，你现在想什么，你想点哪儿，哪里看着别扭，跟你想象中不太一样？如果你想完成某个任务，你会从哪里开始，等等。

在这个过程中，最重要的是要让这个同事放下心里戒备，不能担心自己说错或说蠢话。作为产品经理必须要克制反驳，尤其不要长篇大论地倾诉自己的设计理念，而是要全心全意引导他去讲出困惑。

我们团队每次做类似的事情，产品经理都会说的一句台词是：“这不是在测验你，而是你在测验我们”。每一次我邀请同事来做类似的测试（其实就是简版的可用性测试），都会有意外的惊喜，建议你也试试。

到这里，我们就把“用什么方式，解决谁的，什么问题”中的三个要点全部讲完了，把解决方案这一部分放在最后，是因为我们平时很容易忽略产品的利益相关者和他们的问题，直接跳进解决方案部分。

我今天提到了提升自己给出解决方案的能力，首先要见多识广，多把玩和分析不同类型的产品，另外要能够跳出功能开发来考虑解决方案，以及从游戏设计领域借鉴经验，最后说到了首因效应和简化版的可用性测试方法。

你有没有发现通过非功能特性开发，巧妙的解决问题的案例？欢迎留言讨论，谢谢你，我们下次再见。

!

戳此获取你的专属海报

32 | 从受众规模、需求频率和强度出发：排定需求优先级的方法（上）

“一朝需求不称意，口里驱蛩心上蚝。”——（明）刘基

在之前几次分享中，我说到了分析产品的时候要反复探求“用什么方法，解决谁的什么问题”，从利益相关者、问题和解决方案三个维度分别介绍了产品分析的思考套路。基于这样的套路，或许我们可以列出产品不同利益相关者面临的不同问题，以及解决这些问题的方案。

那么接下来的问题就是，在资源有限的情况下，应该如何取舍，如何安排需求优先级？我这次就从这个话题开始聊起，跟你分享一些我的思考和经验。

避免毫无价值的正确

在排定优先级时，会有一种产品经理很容易出现的错误，就是“做无可争议的正确事情”。

这句什么意思呢，需求列表里永远有这样的需求，虽然没什么用，但做了肯定没错。比如去不断地优化一张页面的视觉和交互细节；把页面改得越来越好看、越来越好用总没错吧？这样的需求确实不能说它是错的，但这样的需求却大都无关痛痒。

之前我在博客里写过一篇文章，提到我认为产品经理需要让正确的事情相继发生，这句话因为池老师的加持变得广为流传。这里提到“正确的事情”，其实背后有一个叫做“机会成本”的经济学概念。

举个例子，如果我们投入 1 人日的研发资源，做了一个功能 A，假设我们用钱来衡量，获得了 1 万块钱的收益，我们算 1 人日的研发资源成本是 5 千块。那算起来 1 万减去 5 千，我们有 5 千块的利润。

但我们真的赚了吗？如果产品经理可以找到另一个功能 B，让收益可以达到 2 万块钱，那这 1 人日的研发资源去做之前说的功能 A， 就会产生一种机会成本，因为产品经理的选择而不得不失去获利更大的机会。

我们简单地把机会成本计算进去，2 万加 5 千是成本，收益是 1 万，这两个一减，就是亏损 1.5 万。当然经济学可能没有这么粗暴，但是要提醒你从绝对收益的概念里跳出来，去考虑收益的相对性。

接着说对需求优先级的衡量和排定，刚才我们说要尽量避免去做无关痛痒的事情，把资源尽可能投入到高优先级的功能中，那么怎样去区分优先级呢？

还是从“谁的什么问题”出发，首先我们去将所有的利益相关者以及他们的问题列出来，逐条分析受众的规模，以及问题的频率和强度。最简单的逻辑是：受益者越多、问题的频率越高、强度越大，则解决这样问题的价值就越大，优先级也越高。

规模、频率与强度

判断规模，有一个概念叫做 TAM（Total Addressable Market），这是指潜在市场范围，每项服务都有受众天花板，比如我们做一个面向中国影像科医生的服务，我们在网上查一下，发现全国从业的影像科医生不足二十万，那这就是当前的规模天花板。

当然这个天花板是会动的，比如我们可以用历年影像科医生的复合增长率估算接下来一段时间的市场规模增量，或者可以用医疗需求的数量作为准绳，去估测可能的市场发展潜力。比如我们根据中国的人口推测国内合理的医疗资源需求，然后根据医疗需求中影像科需求的占比反推需要的影像科医生。

不同的推测结果可能会有差异，但这其实不重要，重要的是要有完整和健全的逻辑链条，在这个逻辑链条中，客观因素越多，可控性就越差，整个产品模式的设计也就越不稳固。

比如上面的例子，如果我们用人口推测资源需求潜力，或许就只能寄希望于医疗体制改革和医疗服务市场化进程，而这种趋势对于一个团队来说，只能期待，很难推动。但如果以当前影像科医生数量做为依据，则会更加清晰和稳固，也更容易跟具体的业务计划建立联系。

另一方面，如果对趋势的判断足够准确或运气足够好，你服务的受众规模天花板可能会在短期内爆发性增长，比如 2010 年左右的移动互联网，原来用电脑上网的人都开始用手机上网了，那么手机应用的规模天花板或者说潜在市场范围，就会快速地大幅度提高。

另外还有地域优势，咱们国家的互联网公司算是占了挺大的便宜，我们随便做个什么 To C 的服务，潜在市场基数就是 10 亿网民，可能在别的国家，算破天也就几千万。这两种其实也是我们常说的流量红利和人口红利。

需求的频率和强度比较容易理解，比如我们知道吃饭和打车跟相亲和找工作相比是高频场景，而结婚和求职比吃饭和打车的强度大。跟规模一样，频率和强度也会随着时代、基础设施以及环境的变化而发生变化。

比如带宽增加和流量成本降低让人们在移动设备上观看视频的频率大幅度地提高，或者随着用户关系链从线下到线上的结构性变化，人们对“在线”这件事情的需求强度也更大了，我小时候只有个别人有 BP 机，平时大家不经常联系非常正常，但现在如果亲人或者朋友微信上一天没回你消息，可能你就会很焦虑。

在规模、频率和强度之外还有一个考虑因素，叫主观的可达性，我们拿吃饭举例子，按理说吃饭这个事情的规模、频率和强度都很高，所有人都要吃饭、每天至少三顿、不吃就饿死了。

但是，显然我们不可能按照全世界人口 x 3 去推算我们自己饭店的业务天花板，这个例子听起来可能会觉得很蠢，但其实很多商业计划和产品规划里的业务模式推算差不多就是这样的逻辑，很无奈。

排定优先级

理解了规模、频率和强度之后，就可以以此来做优先级排序了。我们平时在挑战自己或别人的需求优先级时，首先会关注规模描述的逻辑，也就是刚才说到的，你怎么算出服务的市场规模，这里面的逻辑通不通顺。假设我现在设计一个产品，为一部分的 Python 开发者提供服务，那我如何去计算 Python 开发者的数量，如何对他们进行用户群区分，以及怎样定位自己的目标用户，就会非常重要。

把不同利益相关者的问题列出来，在后面根据规模、频率和强度打分，然后综合考虑。比如当某个用户提出需求期望的时候，我们在挖掘到他背后的动机之后，会考虑他能代表多少人，是一个小众的需求，还是大部分用户面临同样的问题。

然后，我们去客观评价类似的问题出现几率是否高，有的问题虽然确实存在，但因为出现频率足够低，所以有时会策略性地选择暂时不去解决。比如我们做社区，更换会员 ID 这样的需求可能就是一个出现频率足够低的事情，即便有用户真的提出来，可能不会满足，或者线下在数据库里帮他订正一下了事。

最后是从正反两面去评价强度，通俗一点说，就是问自己，如果满足了这个需求，用户会有多开心。以及，如果没有满足这个需求，用户会有多痛苦。我们以前有个同事评价需求的时候有句口头禅是“不做会死人吗？”，后来才知道她原来是做 110 出警系统的，对她来说，这句话并不是夸张。

描述规模、频率和强度的时候，得到结论固然重要，但更重要的是去探求结论的过程，它背后是产品经理对自己产品定位的深入理解，还有对用户的理解、对场景的理解、以及对市场和竞争环境的理解。有时候还会包含产品经理的一些价值取向和判断，比如有人相信薄利多销，有人则愿意高价高质，这并没有对错，选择不同而已。

总结

好了，今天的分享就到这里，我们从规模、频率和强度一起讨论了用户需求优先级判断的方法论，下次我们会讲另一种模型，也就是之前提到的价值曲线分析。你在平时的工作中会怎样安排需求的优先级，有没有什么能够分享的，欢迎在留言中讨论，谢谢你！

!

戳此获取你的专属海报

33 | 产品案例分析：Arts & Culture 的架构之美

Arts & Culture 是一个云端的博物馆，链接了世界各地的实体博物馆，我们可以通过这个 App 观赏这些博物馆中的藏品。

Google 通过自己强大的搜索能力、识别能力，还有知识图谱的构建能力，把这些博物馆艺术品非常工整地串在一起，也提供了与参观传统博物馆完全不同的体验。

这个 App 中有很多细节点都给了我不少启发，我挑出其中的几个跟你分享。

首页是 feeds 流，把 App 中各种形式的内容，快速地打到一个逻辑平面上。

我们先进入浏览作品。在这里，我们能看到的是 Google 如何用知识图谱、用标签，以及整个搜索技术，把这样的内容体系撑起结构来。

这里有各种各样的分类维度，比如，我们可以从艺术家的维度来看艺术品，或从艺术品材质的角度、艺术运动、历史事件等等。

再往下，我们可以看到典藏，就是世界各地的博物馆。这个地方是以博物馆为线索来组织所有的内容。最下面是热门主题。这里就是我们熟悉的标签体系，各个维度是有交叉的。

这几部分还蛮有意思的，上面是比较规整的标签类型，比如说艺术家，中间当然是最规整的，就是博物馆。下面是平铺出来的一堆标签摆在这里，各维度交叉，但同时它又是有意义的。

它背后的东西是同一套，我们可以理解为是平面、散乱的一堆信息，Google 将它们各个维度的属性抽出来，形成逻辑结构。

我们点击任何一个标签，进到的这个页面，都是做过抽取和标记的页面，我们可以理解成一个点击就是一次搜索。只不过不是我们平常的那种关键字搜索，而是基于知识图谱的条件搜索。

在这里，我们也可以看到它背后的知识图谱支撑。比如我们能看到实体有相关的说明，还有实体属性，最重要的还是围绕这个实体的各种关系，当然，在 W3 的标准里，属性也是一种实体到值的关系，我们在这里说的关系主要还是实体之间的关系。

如果知识图谱中的实体是点，那我们相当于可以在这个页面看到所有从这个点出发的边。比如我们可以看到 Arts & Culture，根据这个主题搜出来的其他的艺术品，那我们可以用这个线索去看这些艺术品。

接下来我们在艺术家里面找到梵高，在这里面去看梵高的一些作品。这里面有两个筛选，一个是按年份筛选，通过创作时间来把这些内容串起来。这些属性应用很具体，交互和展示方式都具体化了，它并不是一个摆在那可以点的标签，而是说这有一个标签是哪一年，这有一个标签是艺术家。

我们在做产品和技术设计的时候，有时候喜欢抽象。就是我们想把所有的属性都抽象为交互尽可能统一的东西，比如抽象为标签样式，点击筛选；但这么做会增加用户的理解成本，我们最好是可以用一些特别有指向性的概念标签拿出来做特定的设计。

这里的年份就是一个例子，不是一堆年份的标签，而是一个时间轴，我们用这个时间轴来看这些画作的时候就会特别有年代感，比如说我们拖到最后这里，这幅麦田上的乌鸦，据说就是梵高在生前创作的最后一幅画，我们大概可以看到他创作风格的演化，以及看到他的创作生涯在哪一年。

然后另一个筛选的是按色调，对谷歌来说，它需要用算法去了解一个艺术品，将它们加入到知识图谱中，那它需要取得这个艺术品的很多相关信息。

有一些有可能是结构化的，比如说从某一个表格，或者从某一个网站上，他可以告诉你哪一个字段就代表它的年份，哪一个是代表它的作者等等。另外也会有很多的信息是非结构化的。那么 Google 就需要把非结构化的信息识别和抽取出来。

这里的按色调筛选，其实就是 Google 集成了自己非常强大的图像识别的能力，从图片里面抽取出来的信息的一种。

如果你用这个 App 的时间比较久的话，可能会发现，其实在各种图片分类中还是会有小错误，通过这些错误，我们能够更直观地理解背后的算法，另外也可以看到，Google 确实在用大量的算法驱动产品结构，我们目前也在做一些类似的事情，不得不赞叹 Google 真的非常厉害。

我们再快速看几个有意思的交互细节。

我们快速地定位到一个主题，这是梵高的一幅画。我们可以看到我们在浏览内容的时候，文字是一个一个卡片，在卡片翻动的同时，背景有缩放的效果，非常像有人在给你讲解，先看哪个局部，然后要关注什么，这是一个非常活泼的交互形式。

然后我们再去看这个浏览作品里面的几种观赏方式。建议你自己下载了感受一下，有一个是 VR 观看。然后有一个类似 Google 街景，你可以在这个博物馆里面穿梭，有一个身临其境的感觉，还有一个 360 度视频，在观看视频的时候，我们可以看到全景视角，我之前看到过类似的交互，但在这个应用中，跟场景特别契合。

另外还有一个很小的点，就是它的翻译功能，这个翻译功能做成悬浮的，你可以把他推到边缘。它在结构上是游离于整个信息架构之外的，但同时又可以跟内容结合得很好，这是一个很聪明很有意思的设计。

!

戳此获取你的专属海报

34 | 价值曲线分析：排定需求优先级的方法（下）

“民为贵，社稷次之，君为轻。是故得乎丘民而为天子，得乎天子为诸侯，得乎诸侯为大夫。”——孟子

在上次的分享中，我们聊到了利用受众的规模、需求的频率和强度来做需求优先级判断的框架。今天我们会介绍另一种，叫做价值曲线分析法。

类似的框架其实有很多，它们之间其实并没有对错优劣之分，所有的框架都没办法给出答案，只是帮助整理思路的工具而已。还是那句老话，不要迷恋工具，多把精力花在深入思考上。

我们今天要介绍的方法，出发点还是我们前几次分享中提到的那个分析路径：“用什么方案，解决谁的什么问题”，顺序依然是从谁开始，到解决什么问题和用什么方案。

我们如果去看传统的价值曲线分析（或称价值曲线评价），会发现它主要是用于分析用户感知和服务质量的工具；但正如我们之前的分享所提到的，产品经理不能仅关注用户，而是要关注所有跟产品相关的受众。我们要从产品涉及的所有利益相关者的角度出发，利用价值曲线分析的方法去理解他们的感知，然后再去评价我们产品提供的服务质量。

罗列利益相关者和他们的感知价值

我来举个开饭店的例子，努力把这个工具解释清楚。比如我们现在要打造一个新的连锁饭店集团，假设叫 X 县小吃。这件事情的利益相关者可能会有很多：到店吃饭的顾客，有连锁店加盟店长，还有上游的原材料供应商，可能还有投资我们做这个事情的投资人等等。

列出这些利益相关者之后，我们就把自己放到他们的立场上去，考虑他们能够感知到的价值和问题。

比如，我们把自己放在顾客的场景上，对于一个连锁饭店，他可以感知到的价值可能是菜品的种类、口味、价格和卫生等等。这里要加一个“感知到的”，其实是为了保证价值最大化。提供用户完全无法感知到的价值是危险的，因为那很难成为用户为你付费的原因。

乔布斯曾经说过：“要把篱笆的背面也做得尽善尽美。”这是一种值得赞叹的工匠精神，但如果用户无法感知，那么为此付出的成本很容易就跑到黑洞里了。

说完顾客，我们换一个角度，如果我们把自己放到加盟品牌连锁的店长的立场上，他们最关注的可能是收入、成本、利润、翻台率等等指标。如果从投资方的角度去看，可能关注的是加盟店的数量、增速、毛利、实施成本。

对问题进行优先级排序

当我们列出每个角色的关注问题列表之后，我们要做的第一件事是为这些问题做个排序，这里的排序没有正确答案，但跟业务方向和目标用户群强相关。

比如我们不能武断地说，对顾客来说，菜品的口味比价格重要，用餐环境比菜品的种类重要；但我们可以根据业务的定位（X 县连锁小吃店）和我们的目标用户群（可能是在 CBD 工作的普通白领）来衡量排序。

我们可能会认为最重要的是配餐速度，其次是价格，第三是卫生，这里有一点需要注意，正如我们刚才说的，“卫生”可能是个难以感知的价值，需要去考虑如何向顾客传递和解释这一价值。

我们再试着看连锁店的店长，他们可能是自己掏钱加盟装修店面的，我们假设他可能投了一大笔钱，现在他特别着急回本儿，所以他的关注第一位是快速获得收入和利润。

如果他是需要钱继续开更多的店，可能更关注流水和账期，如果是单纯追求赚钱，可能会更关注利润率；而投资品牌连锁店的资方，如果是战略投资者，可能会优先关注加盟店的数量，开店的速度，如果是财务投资者，可能会关注收入和毛利。

将问题指标化并拆解

给问题排序之后，第二件事情是将所有的问题指标化。我们在考虑目标时可能会用一些大而化之的描述方式，用一些模棱两可的形容词，比如配餐速度快，比如卫生条件好之类。类似的目标很难衡量和管理。我们应当把它换成非常具体的指标，比如配餐速度换成下单到上桌的时长，卫生条件换成餐具消毒次数和清扫频率等指标。

我们在面向市场和用户介绍产品的时候可以叙事，可以说副词说形容词，可以赋比兴，但在做产品和规划业务的时候，要多说数字，多说名词，多用白描。产品经理要避免把诗性和情绪带到分析框架里，容易耽误事。

在指标化的过程中可能需要对部分指标做拆解，比如当我们关注利润的时候，其实是营收减去成本，关注成本的时候，可能会有可变成本和固定成本，关注固定成本时又会有人员成本和设备成本。

关于指标的粒度，并没有标准答案，不同的业务阶段和状态可能会有不同的关注点，比如我曾经负责的一部分业务在一段时间内，优先级最高的目标是大幅度降低获客成本——这只是所有成本中的一部分，但在那个阶段成为核心矛盾，所以就把粒度拆到这里。

整体权衡和排序

指标化之后，我们需要基于这个模型进行整体排序，我们先要在业务上去做出一个判断，目前哪些人的哪些问题是当前的瓶颈，是我们需要集中解决的？抓住这个问题和背后的指标，基本就抓住了业务重心和方向。

比如我们的连锁品牌刚刚完成了一轮融资，也完成了单店运营的基本流程，可能这个阶段我们认为需要集中精力大量增加加盟店的数量，拆解下来发现这个方向背后的核心问题主要是加盟店的装修周期太长，或成本太高。

那么我们可以把这个问题的优先级放到最高，把大部分资源投入进去解决这个问题，甚至不惜伤害用户体验去降低装修标准，提高装修效率。

你应该会注意到，在不同人的感知价值之间，可能是会有矛盾的。我们决定做的事情可能会伤害一些利益相关者。

比如我们如果要提高效率，虽然能提高店面的增长速度，但可能会伤害用户体验，如果要提高用户体验，可能就要提高店长的运营成本，伤害店长。这样的权衡可能是做产品的常态，需要把路径想清楚，有所抉择，一旦做了决定，下手要迅速，不要犹豫，不要绣花。

比如打车平台，在竞争白热化的时候，需要最快地提高司机数量，可能会利用经济补贴手段，以及降低服务质量要求，当车辆覆盖率达标之后，可能需要阶段性提高用户体验，又会提高服务标准，这样一来就提高部分司机的服务成本，导致司机数量相应减少。

这里还会涉及竞争分析，我们回到连锁小吃店的例子，假设我们分析了类似品牌的竞争者，发现大家都主打口味和用餐环境，这时聪明的办法是去找一个不同于其他人的价值高点。比如在口味和用餐环境保持及格的前提下，把送餐速度做到十倍快，做出差异化的品牌定位。

这样，对你来说，送餐速度就是最高优先级的指标。就像淘宝和京东，在淘宝已经有海量商品覆盖率的情况下，京东从垂直品类入手，把正品率和配送效率做到了极致，获得了生存和发展的空间。

可以想象如果京东用跟淘宝一样的价值曲线模型去做电商，跟淘宝硬拼，基本是没有机会活下来的。

综合考虑解决方案

上面的步骤完成之后，还有非常重要的一部分是解决方案和成本分析。有时候排在第一位的问题需要耗费的成本巨大，我们承受不了，那在动手的时候，可以退而求其次。

还用我们的饭店举例子，假设我们发现在某个阶段，品类单一导致回头率降低，决定扩展菜单，结果规划之后发现为全国所有的连锁店增加新菜，需要付出巨大的供应链成本，短期之内不现实。我们就只能先放一放，转而去解决其他问题。俗话说，不要在一棵树上吊死，做产品也不要在一个指标上吊死。

总结

今天，我们从一个连锁小吃店的例子开始，一起简单地分享了价值曲线评价在产品规划上的作用，依然是从受众和问题开始，罗列利益相关者和他们的感知价值、对问题进行优先级排序、将问题指标化并拆解、整体权衡和排序、最后再综合考虑解决方案。

希望今天的内容对你有所帮助，也欢迎留言讨论，我们下次再见。

!

戳此获取你的专属海报

35 | 答疑时间：关于产品经理的12个问题

自从开设了这个专栏，我陆陆续续收到了不少留言，今天就挑出来一些有代表性的问题，集中解答一下。

1 二爷您可以讲一讲，已经有人工智能背景的同学，在一线二线大厂面试的时候，怎么展示自己在这方面的优势？

如果被问到，你的背景对做产品经理有什么帮助，如果这个面试部门的产品和 AI 的结合目前没有成熟，或者自己不知道 AI 对这个产品的商业化帮助，该怎么回答？

答：你好，我不太确定你现在的角色，你说打算应聘产品经理，姑且认为你是一个有些人工智能背景的产品经理吧。

在面试中展现自己在这方面的优势的办法有三种，效果依次递减：

你在人工智能方面有过产品成果，也就是“在这个领域做成过事情”，在这种情况下，你只需要解释你做了什么，产生了什么样的效果，用实际的数据和成果说话是最有力的。之前有个段子说 ：Guido 的简历上就三个词儿 “I wrote Python”，大概就是这种，你感受一下。

如果没有亲自在这方面做成过事情，那你可能是看别人做过，或学习过一些资料，分析过一些产品。这种情况下，最好能够结合用人岗位的实际需求，去描述你认为人工智能可以跟业务结合的机会和方式，你可以理解为：在向面试官做一个人工智能结合对方业务的产品方案的提案，在这个过程中不仅展现了你对对方业务的了解，也展现你对人工智能算法、边界和流程的了解。

如果你自己没有过产品成果，对招人公司的业务和期望完全不了解，而且想不出来“AI 对这个产品的商业化帮助”，那就只能干讲了，介绍一下你学了什么资料，读了什么文献，怎么学的，有什么感悟之类，这类说法可能会缺乏感染力，建议还是在 1 和 2 上下下功夫，尤其是 1。

即便你没有操盘过真实产品，至少应该有自己做过的实验性项目——尽量不要是课程作业或者教科书的样例程序，而是有实际用处或让人耳目一新的东西，比如我之前在网上看到一篇文章，一个哥们儿用 TF 训练了一个神经网络通过王者荣耀游戏截图判断当前玩家的角色，这就比用神经网络识别手写数字有趣多了。

**2 二爷，我想请教一下 UE（我司目前认为的交互设计）与原型设计的临界点应该控制在哪里呢？ **

背景是这样的：下周三会与客户团队过一下 UE，之前的经验是过原型文件，原型里面会有部分需求描述，但是真的交互设计，评审 UE 时，主要是看页面跳转，布局，以及控件的状态，与需求本身的描述是有没有关系的？

答：不知道你后来跟客户团队过产品过得怎么样， 我理解你问的是交互设计师跟产品经理的工作边界。

我过去跟交互设计师合作时，不同的设计师会有不同的边界，跟配合习惯有关系，但基本的合作模式是，作为产品经理，我会用用例文档来描述用户与系统的交互流程，比如我们举个简单的例子，可能用例文档会写：系统展示商品；用户浏览商品；用户挑选商品并向系统请求购买；系统校验商品库存并生成订单。

那在这个过程中，并不描述系统怎么展示商品，列表还是图片，也不描述用户是勾选还是加购物车，或者描述请求购买是点一个按钮还是摇一摇手机。

然后，我会根据我自己的想法有个大概的设想，可能是画个线框，或者在草稿纸上罗列一下元素，跟交互设计师交流这个流程，背后的动机和商业背景。

比如我会说，你看这个产品目前其实挺少的，可以考虑弄个大图什么的，免得页面显得空，或者说大部分用户不会买多件商品，估计也不用有购物车或者多选之类的。

然后，基于这些交流，交互设计师会做出更完整的交互稿，这个过程中，可能会沿袭我之前提到的框架，也可能会推翻掉，出一个全新的框架，在这个过程中，我们都会保持非常紧密的沟通。

当然，如果遇到特别弱的，基本就画画线框图的交互设计师，可能在交代设想的时候，就把框架描述得非常详细，我就会说，这儿弄个按钮，上面放文案，点击的时候得整一个点击状态，等等，感觉这个兄弟基本退化成一个帮我把线框图从草稿变成正式稿的工具了——还好我很少遇到这样的同伴。

3 二爷，我赞同“留给需求发酵的时间”，实际工作中要求是当前版本提测时下个版本就要需求评审，但由于白天时间被各种“会”占据，经常只有晚上才有时间发酵需求，很容易陷入疲惫的循环。二爷能简单讲讲日常产品工作流或精力分配么，谢谢。

答：如果团队没有意识到需要留出时间，同时你也还没有足够影响力去要出时间，那么没有什么好办法，就熬夜吧，我前两年的工作经常是在十二点以后开始写 PRD，写到凌晨，睡一觉第二天起来再看一遍，至少保证被发酵一觉的时间。

精力分配，我自己也没有做得很好，试着用了不少工具和方法，但事情多了还是会很慌乱，也没法给你特别好的建议，希望以后我找到什么好办法之后可以跟你分享吧。推荐去看看左耳朵耗子专栏最近的一篇文章，专门讲时间管理的，挺实用。

4 我在现实工作中碰到的情况就是，需求评审这事其实大家没有放在心上，有些同事对业务并不熟悉，心态上还是以完成任务为主，对需求或是方案并未有足够的重视，简而言之，责任都是产品经理的。我一直在想，产品是靠团队的，一个人总有自己的局限。

不知道二爷对此有何高见？如何将大家的心态转变成为真正做产品而不是做项目？

答：我年轻的时候想过很多歪门邪道来胁迫别人关注需求和方案，对需求评审用心，但后来发现最好的方法还是激发团队的凝聚力和好奇心，我会在剩下几期里专门写一篇文章跟你分享一点我的经验。总之记得强扭的瓜不甜，抱怨也没有用，行动起来，能改善一点儿是一点儿。

5 邱老师，我有两个小问题：

（1） 设计信息架构的时候应该注意些什么，一个好的产品信息架构有哪些共性？

（2） 项目管理中有关键路径的概念，产品设计中，怎么找到产品的核心路径，路径往往有多条，设计核心路径的时候，如何取舍？

答：（1）注意辨别信息本来的架构，想办法弱化设计，让信息自己表达自己的逻辑关系。我举个例子，比如一篇文章有标题、时间和作者，一般会把标题弄得又黑又大，作者小很多放下面，时间写成 2018-01-01 这样的形式，本身就表达得很清楚了，不用费事写标题：xxxxx；作者：xxxxx；日期：xxxxxx 这样，然后下面隔开一点距离，小一点的字放正文，大家一看就懂了，哦，这是标题，这是正文。

另外要注意从用户的角度考虑信息架构，而不是从供给的角度考虑信息架构，符合用户的心智模型，而不是我们自己的实现模型。比如我们做电商的时候都会区分会员、商铺、商品、交易、物流等等产品线或模块，但我们不能把会员、商品、交易这样的东西交给用户，用户要看的可能是类目里面有货，然后就可以加购物车交钱买。

有人说看一个公司水平怎么样，就打开网页看看菜单结构，最好的公司是根据用户需求来划分菜单结构的，次之是根据产品模块划分，最烂的公司是根据部门划分的，大概就是这个意思。

我理解好的产品信息架构应该符合用户心智模型，不靠明示而是靠暗示来让用户理解信息架构，让用户自然地知道自己身处何处，可以去哪里，怎么去。推荐一本书叫《Web 信息架构》，封面是头北极熊，那本书很专业。

（2）一方面是在设计之初要有自己的假设，比如设想电商的典型路径是用户搜索商品，然后看详情，然后付费购买。上线之后看行为路径的数据，可能会完善或者纠正你的假设，比如你发现有一波用户是先搜店铺然后在店铺里看新货上新，或者一波用户是从社交网站的推荐直接进入商品详情页完成购买，如果这些用户的占比足够大，可能就需要纠正你自己的判断。

6 AI 现在炒得火热，但是按照一般的科技产品的炒作周期，火热过去就是山谷，然后就是看技术的实际应用场景能不能达到投入产出比，比如去年得 AR/VR. 我想问，二爷你是基于怎样的考虑认为 AI 的前景如此美好，谢谢。

答：这个问题我可能答不好，试试哈。

首先我认为火热和山谷是很正常的，有一点像股价和公司价值之间的关系，不论短期怎么波动，整体的走势还是稳定的。而现在判断 AR/VR 是风潮式的伪命题我认为为时过早，但如果说大家的关注焦点和资本暂时不聚集在这个行业中，我认为这是正常的。

另一方面是不同于 AR/VR，AI 可以在现有计算平台和业务流程中部分地发挥作用，它并不是在解决新问题，而是在用新方法解决老问题。比如过去手写识别能不能做？可以做，但有了深度学习，做这件事情的成本和门槛低了，这时不需要业务的结构性变化就能带来价值。

基于这两个原因，我认为它会离我们更近一些。

7 二爷，我有一个问题想请教一下：对于一个一到两岁的产品经理，最重要的素质应该是什么？或者说，如果你面试这个阶段的产品经理最看重他的哪些方面的能力，比重分别大概是多少？

答：我觉得最重要的是有没有做成事情的经历和气质，不论这个事情是什么。

你可能原来没有做过产品经理，可能原来只是做销售或者运营，但是你能在你的岗位上有灵性发现这个岗位来龙去脉，捕捉到这个岗位的本质，你能把交给你的任务完成地非常好，你能证明你在任何领域里有做出事情的潜力，那么，你就证明了你作为一个产品经理，也依然可以做成事情。

8 “如果不是非常清楚一条产品线的来龙去脉和设计原则，哪怕只是一个细节，都很难给出明确的建议。”

作为一名程序员，不太能理解这句话，一个小建议不能根据以往的经验来决定吗？二爷可以谈谈这个问题吗？

答：陈升有一句歌词说，“写歌的人断了魂啊，听歌的人最无情”，大概就是这个意思，设计产品的人断了魂啊，提建议的人最无情。

建议分成两种，一种是从用户角度出发，不爽，希望能改，这个完全没问题，百无禁忌，不喜欢它的颜色都可以提，这是一份来自优秀用户的热情，但最后改不改取决于设计者的判断。另一种是从一个产品设计同行的角度去评价（judge）别人，我在没有看到大盘的数据细节，也不知道别人的战略判断的情况下，就不好给出评价或意见。

我这句话是基于这个背景，Fenng 的公众号小道消息最近有一篇文章《在中国，有一亿人想指点张小龙该如何做产品》，推荐读一下。

9 之前一直做淘宝天猫运营，很想转行做产品经理，学习了产品经理的一些知识，感觉一部分和运营是相同的，最近想学 Python，刚刚开始看书，不知道是不是应该继续呢？

答：做运营，想转行做产品，然后学 Python，我觉得你可能要三思，我建议你先成为一个优秀的运营，至少把本职工作做得很出色，这其中的思考和积累，未来都可以用到产品经理的岗位中。

10 一直有个疑问：即便是手机中的常用产品，我们也无法了解或是掌握它的全部功能或是细节，而产品不断迭代更新，我们可能总是处于未知状态，产品设计者也罢、狂热爱好者也罢、普通用户也罢，大部分人都要看攻略、看教程、看视频等，因为通过自己的摸索远远不够，我们应当如何面对这样的窘境呢？

答：我不太清楚你说：“如何面对这样的窘境”，问的是作为设计者还是用户。我觉得作为设计者，应该能在产品设计中把不同的用户类型和场景尽可能区隔开，或者有所取舍，照顾一部分用户的需求，舍弃另一部分需求。

作为用户，我很希望自己能遇到那些惊鸿一瞥便愿意驻足，不断探索总有新的发现和惊喜的产品。爱它如烟，也爱它曼丽又懒倦，挺美妙的不是吗？

11 让团队消化需求变更。其实也是产品的沟通能力之一，还有就是公司工作流程问题。需求变更出现在各个层级，领导要求变，UI 设计又要变，开发过程中又会变又或许是需求方的业务需求变，那么对于这些场景来说，该用什么样的语言跟对方沟通？

答：对方是什么世界的人，就用什么语言。比如跟开发尽量用技术语言，跟业务多说业务语言，争取达成谅解。

12 二爷，游戏带给您什么灵感呢，可不可以讲讲这个内容？

答：好的，收到了你的点播，我会专门分享一下我从一些游戏设计方法里学到的东西。

今天的问题就先总结到这里，我们下期再见。

!

戳此获取你的专属海报

36 | 产品案例分析：解读知识星球

知识星球的创始人吴鲁加老师曾这样介绍这款 App ：“你可以把知识星球理解为一个手机版的论坛。”

他的产品机制设计非常聪明，从哪里看都像是论坛，但众多细节差异又使得它似乎变成了另外一个物种。

一般在各种论坛或者社区这种有互动的产品中，评论或留言的排序方式有几种，一种是纯时间排序。比如传统的论坛都是这样，它是一种公共讨论的隐喻，就像大家聚在一起，你一句我一句的说话，这些内容的先后顺序本身就包含了信息。

另一种是按照某种重要程度排序，比如知乎、Quora，它不像一堆人的讨论，而像是一个人和多个人的交流，可能是一个人问问题，其他人跟这个人对话。

还有一种是像知识星球这样，评论按时间排序，然后将针对评论的评论再单独提出来。并且知识星球的设计是，在列表页看到的评论按时间排序，如果进入到某一条具体的帖子中，才是我们说的这种更复杂一些的评论展示形式。

百度贴吧之前同时用了这两种形态，也就是说所有的评论根据时间排序的同时，再根据评论之间的关系再冗余一遍，我不知道现在还是不是这样，没有去求证，现在百度贴吧太乱了，让人不愿意看。

微信朋友圈、Instagram 的评论都是简单粗暴的平铺，我们都很熟悉了。大家可以猜猜看 Facebook 是怎么处理的？我们不在这里展开说，大家可以去看一看 Facebook 在不同端对留言区的设计，很有意思。

从一个完成冷启动的社区的角度看，有老生常谈的三个问题：内容流动与沉淀，内容分类与整理，蒸发式降温与留存，我们看看知识星球的处理方案。

首先，由于列表的本身限制，会让很多优秀的内容沉下去，而且这些优秀内容也缺乏索引和结构，很容易淹没在一些低质量内容中。

知识星球用了一些筛选，也加了精华和标签的机制。这些手段，如果对于一个论坛来说，其实是远远不够的，随着内容增加就应付不过来了；但在移动端，由于碎片化的属性，可能会好很多，联想一下微信的朋友圈，以及半年、三天不可见的设置。可以理解在移动端的环境中，内容的预期寿命其实是很短的，沉淀可能问题不大。

还有内容分类的问题，我们经常看到有两个极端，一个是完全按照领域、主题来区分内容，还有一种是按人来做划分，知识星球取了个模糊的中间位，既是根据人，也就是星主来划分板块，也是根据主题——每个人会设计板块的主题，这样来作区分。

另外就是所谓的蒸发式降温，指的是社区头部的生产者离开社区，导致社区活跃度坠崖式下降，这种情况在一些年纪比较大的社区中很容易出现。老人走了，新人由于群体隔阂也没接上班，很快就凉了。

知识星球由于非常依赖星主的运营，所以有可能会面临比传统论坛更凶猛的蒸发式降温，这时候需要去考虑拽住人，尤其是拽住星主或主要内容生产者的机制。它目前有一个在灰度测试很有意思的设计，就是转发赚钱，比如我加入了小道消息的星球，我把内容分享出去，如果有人通过我的分享加入星球，我可以分到一点钱。

另外还有加入星球付费的这个设计，会持续给星主一些运营的压力，也算是一个天然的拽人机制。

目前知识星球还利用微信的一些推送机制，定期的推送内容，也是在拽人。不过这里面有个设计是可以通过互动关掉这个推送，不流氓，挺好的。

还有最后一个想说的是它的发现机制，这是一个刚刚上线的功能，之前基本是完全去中心化的，也就是我几乎只能在知识星球体系外发现和加入一个版块。在这种情况下，其实去做一个“发现”，做中心化的推荐是一个非常顺的逻辑，但吴鲁加老师一直到最近才做了这样的功能。

!

戳此获取你的专属海报

37 | 如何做好需求评审（上）：需求评审不只是一次会议

“问渠哪得清如许， 为有源头活水来。”
——朱熹

几天前收到了一位专栏读者的留言：说自己在现实工作中发现，大家并没有把需求评审这件事情放在心上，有些同事对业务并不熟悉，或者没有建设性心态，觉得潦草交差即可，所以在评审阶段不重视需求方案，认为反正都是产品经理的责任。

他在留言中问我有没有什么办法能让大家转变心态，可以关注产品，而不是简单地交付项目。

这个问题我也遇到过，而且一直持续地遇到，即有我主持需求评审别人心不在焉的时候，也有别人的需求评审我走神儿的情况。

年轻的时候我想了不少歪门邪道让别人在评审阶段关注需求和方案，对需求评审用心，承担责任。

比如提前发出文档然后针对文档问问题，比如要求必须提出两个以上的反馈，或者让工程师来主持需求评审，甚至还干过把评审结论打印出来让业务部门代表在纸上签字的事情。

所有的这些方法和手段在刚提出来的时候都会有一定的效果，但随着大家逐渐习惯，它们就会形式化，然后我们又去寻找新的流程化手段，周而复始，流程越来越重，效率也越来越低。

那应该怎样优化需求评审呢？今天我就来谈谈自己的一点经验和思考，希望可以给你带来启发。

1. 当我们谈论需求评审的时候，我们在谈论什么

当我们谈论需求评审时，第一反应会觉得它只是一个环节，可能包括一次会议，几封邮件。但我们不能局限在一个流程切片的角度去理解和讨论它，需求评审串起了前期的需求收集和分析，不同利益相关方的博弈，以及后续项目落地实施的计划管理等各个方面，评审会议本身只是露出水面的一角，想让评审更有效，事前和事后都要做不少工作。

正因为如此，需求评审也成了对产品经理综合能力的一次考验，我曾经有个同事把需求评审会称作是产品经理的 Show Time（表演时间），如果完成得出色，不但项目会顺利很多，也会为自己在团队中的影响力加分。但是，对于那些能力欠缺、准备不充分的产品经理来说，也可能会是一场噩梦。

2. 需求评审的受众、目的

作为产品经理的下意识反应，任何事情都应该先去追问：“解决谁的什么问题”。对需求评审来说，就是要先弄明白需求评审的受众和目的。我们通常意义的需求评审，是产品经理完成需求收集和分析，确定解决方案之后，面向两个角色，做四件事情。

第一件事情是向需求方以及其他利益相关方详述自己对需求的理解和分析，明确我们的需求分析与他们的原始期望是一致的。通俗一点讲，就是需求方（包括用户）说了自己需要什么东西，你思考和挖掘他们背后的动机之后，用自己的理解复述给他们听，确定自己的理解是不是正确。比如用户说要一匹更快的马，你分析需求和场景之后，认为他的动机是希望更快地到达目的地，把你的分析过程讲给他听，并同他们达成一致。

第二件事情是向设计、研发和测试团队，也就是需要去实现产品的这一票人，讲清楚需求的背景和来龙去脉。这个在我们之前怎样与工程师相处的分享中也提到过，不能只交代做什么，还要交代为什么做。这个事情本质上跟刚才提到的，向需求方详述对需求的理解和分析很像，只不过受众不同，可能需要多交代一些背景。

第三件事情，是向需求方交代具体的产品解决方案，也就是他们将要得到一个什么东西，是一个按钮，还是一个表单，还是一段没有界面的逻辑。这个东西会如何出现在他们的工作场景中，以及会如何跟他们发生关系，让他们的工作发生什么变化。

第四件事情，则是向开发团队交代产品解决方案，设计师、工程师需要弄清楚自己将要制造一个什么东西，长成什么样子，怎样运转，有哪些特性。这也是我们提到需求评审之后可能想到的第一件事情。

3. 哪些人参加评审，怎样安排议程？

有人曾经问我，需求评审会应该安排哪些人参加？需求方和工程师应该在一起完成评审吗，要不要分开开会，或者，怎样安排需求评审会的议程等等。其实如果把上面提到的四件事情拽出来，分别排列组合一下，就很容易得到答案。

需求方代表，如果有的话，通常是业务或者运营团队，To C 产品也可能没有一个具体的代表，通常有产品经理本身来充当。实现方则包括设计、研发、算法、测试甚至运维等等。

如果通过一次串讲，既能与需求方达成一致，也向实现方交代了背景；既能让需求方明白产品方案，也可以让实现方清楚特性列表，那就尽量一次性搞定。如果有实际情况或者流程障碍，比如你的开发团队是外包的，或者关于产品方案实现细节的讨论冗长而且专业，那再根据具体情况去拆分会议。当然，不论开几个会，评审几次，都要记住上面四个目标，手段是为目标服务的。

评审议程也应该结合目标来安排，一般是先讲业务，然后再讲方案，讲的过程中还是根据刚才说的四个目标来安排逻辑和内容，提高效率。

4.“预则立，不预则废”

大部分人的思考都需要时间和过程，有的产品经理为了顺利通过评审，会想要打别人一个措手不及，毫无铺垫突然开评审会，趁着参会的同事还没反应过来，闪电完成串讲，需求评审顺利结束，结果后面一大堆问题，他还振振有词说谁让你们需求评审的时候没提出来呢。

还有一种情况是，没有提前准备，结果在会上发现有根本性的分歧，当场陷入到具体细节里，长时间的讨论，但依然没法达成一致，无果而终。

所以，大家一定要重视会前的沟通，提前做功课，要记住需求评审会应该是凯旋的钟声，而不是冲锋的号角。

会前沟通一般是小范围的，针对一些细节点深入、频繁地与具体的相关人交换信息，达成一致。这其中既包括与业务部门的沟通，也包括与工程师的沟通。通过这样的沟通，确保在需求评审之前，将整个流程中可能发生分歧的点都考虑到，并且进行过讨论，要做到最终在需求评审会上的内容不会让与会者感到“意外”。

另外很重要的就是一定要提前发出需求评审的材料，让大家可以提前熟悉一下评审内容。虽然有一些手段可以敦促大家提前预习，但说实话，大部分人还是不会读。你也不能怪别人，在没有引导的情况下读产品文档确实是件很低效的事情，寄希望于把文档发出去大家就都会仔细阅读然后给出反馈，其实也是一种推卸责任。

这时候，最好可以一对一跟进一下，也就是说，产品经理需要能够意识到不同的人关注的不同内容，然后非常具体地指出来，再让对方去提前读。

比如，文档发出去之后，跟业务部门代表说：“你看看功能图例里头那个流程图，是不是跟你们业务实际情况一致”，或者是，“你看看文档里的线框图，加了一个按钮可不可以”。只有这样具体地指出来，相关的同事才能有操作路径，才有预习的效果。

除了会前沟通之外，还有一件对于需求评审很重要的准备工作，就是准备材料和议程。材料至少要包括需求文档，议程至少有讲业务、讲实现、评审讨论三个部分，如果是大规模需求评审，可能还需要特别准备幻灯片，如果需求评审跟项目启动会一起开，或许还要加上项目计划等等。

会前发出来的材料和议程，一定要专业，要严谨，一方面是可以把事情交代清楚，另一方面，大家提前看到这样专业和严谨的东西，会收到影响，在潜意识里会对这次需求评审更严肃和重视一点。虽然听起来有点形式主义，但还是有必要传递这样的信息。如果你自己都吊儿郎当，别人凭什么郑重其事。

总结

今天我们关于需求评审的分享就先到这里，我们说需求评审不仅仅是一个环节，它会贯穿整个产品需求分析和实施过程，然后聊到需求评审的两种受众和四个目的，以及基于这四个目的，如何去安排需求评审会议，最后说到如何为需求评审做准备，做好会前沟通和预习。

下次分享，我们会继续聊需求评审，关于需求评审你有没有值得分享的经历？不妨在留言中一起讨论交流，谢谢你，我们下次再见。

!

戳此获取你的专属海报

38 | 如何做好需求评审（下）：在评审中控住全场

爆竹声中一岁除，2018 pretty cool。

千门万户曈曈日，all your dreams coming true。

——王安石 & 邱岳（加微信：642945106 发送“赠送”领取赠送精品课程 发数字“2”获取众筹列表。）

作为产品经理，需求评审时最头疼的事情莫过于参与人都心不在焉，嬉皮笑脸就通过了评审，结果到了项目都快做完了突然又提出问题，这时再返工除了浪费资源，还会打击士气。

除此之外，有的产品经理甚至提到需求评审就紧张，因为经常会有人跳出来挑战产品方案，需求评审会最终演变成争吵掐架会，没有结果产出，大家不欢而散。

上次分享中我们聊到了需求评审的目的和准备工作，今天我分享几个能帮助我们提高评审效率的方法，希望可以给你带来启发。

1. 当心知识的诅咒

我们说到了评审会上大家不能积极参与的情况，通常情况产品经理都会责怪评审会的参与人，觉得他们没有积极投入，缺乏主动性。其实我觉得并不完全是这样，很多时候他们也是有苦难言。

这里要先提到一个叫做“知识的诅咒”的概念，指的是当一个人拥有某种知识之后，就很难想象和模拟出不知道它时的状态，因为陷入这样的状态会影响沟通和表达，仿佛就像受到诅咒一般，所以由此得名。

有个著名的心理学实验，让一组人在限定的范围内选择一首非常简单的曲子，然后在桌面上敲击它的节奏，另一组来猜具体是哪一首，最终结果是只有 2.5% 的听众猜对了曲目，而敲击者在敲打节奏之前，预测这一概率至少是 50%。

你也可以试试，在脑中试想一首旋律，然后手指敲打书桌，这时你会觉得自己敲打出的节奏如此准确清晰，别人不可能听不出来啊；但倘若你把桌面上的敲击声录下来，回放自己听，你就会发现当脑子里没有旋律的时候，这些敲击声就像是一串毫无规律的莫尔斯码。

作为产品经理，对业务和产品细节的了解就像脑海中的旋律，台上的你其实无法想象坐在下面听讲的人的处境。我参加过类似的评审会，虽然抱定全情投入的决心，但产品经理在上面讲不了几分钟，我就完全迷失了。

所以我建议你在做宣讲或者评审需求的时候，要像做产品设计的时候一样，把自己放到听众的上下文中去，把来龙去脉讲清楚。哪怕有一部分听众会觉得你有点啰嗦，也要讲，尽可能从所有人都了解的背景开始讲起，逐渐向外延伸，像讲故事一样。大部分人听到自己已经知道的事情时会有安全感，以此为基础延伸开来，才能让听众感到踏实和好奇，摆脱知识的诅咒。

2. 不要强迫，要吸引

和与人相处一个道理，当听众没有积极参与的时候，我们要做的不是强迫他们，而是引导他们来理解。在需求评审会上引导听众的最有力武器就是“具体”。

先讲个故事，这是我在一本书上看到的，说一个产品经理在公司内部做便携式平板电脑的提案，在上面介绍这个平板电脑的外观、尺寸、数据，说了半天下面的听众一头雾水，鸦雀无声。这时他发现自己随身携带的文件夹的尺寸跟这个产品的设计尺寸很相近，于是灵机一动，把这个文件夹扔到会议桌中间，说：这就是那个平板电脑的样子。

有人拿起那个文件夹端详，然后传给下一个人，终于有人开始发言，并且逐渐演变成了七嘴八舌的热烈讨论，开始提出问题，讨论功能特性。所以你看，一个莫名其妙却足够具体的文件夹，就能帮助所有漂浮在空中虚无缥缈的概念落地。

对于软件产品来说，我们的“文件夹”就是用户场景和用例故事。

为了让听众理解需求和方案，我们最好可以从场景和故事出发，用具体的案例来跟听众沟通，而不是对着文档从头到尾照本宣科。我过去的习惯是，先整体地介绍业务，大的逻辑和背景，然后用一个实际的业务案例把相关的功能和流程串讲一遍，最后回到文档本身，把需求文档从头到尾过一遍。

比如我之前做工单流转的需求，里面涉及了很多角色和业务场景，还有一张巨大的流程图。为了让所有人能看懂这个流程图，我就编了一个客户案例，然后还花了很多时间做幻灯片的动画，上面有一个卡通形象，顺着这个流程图移动，每移动到一个点，会停下来，然后跟大家解释在这个流程点上，系统的界面会是什么样子。

那次评审很成功，虽然流程和逻辑非常复杂，但基本上没什么人走神，这是因为大家都可以在具体的用例故事里理解需求和方案。

3. 用自己的态度感染别人

我们上一次的分享中曾经提到过，需求相关文档和会议流程要尽可能的专业严谨。有个重要的目的是让大家郑重其事地对待你的文档和会议议程。

换位思考一下，如果你拿到的是一份非常潦草的文档，以及没有任何议程计划的会议邀请，你也不会为这次评审提前投入什么精力。相反，如果文档严谨准确，会议邀请里写有相对完整的会议议程，或许你本能地就会觉得这是一次“正式而严肃的会议”。

信心也是一样，产品经理在评审时一定要有信心，并且要在评审过程中传递这样的信心。所谓“自信者，人恒信之”，如果你自己都对产品和方案没有信心，整个项目组就会没有主心骨；而且人都很奇怪，他们是否会相信一件事情，通常会取决于是否相信提出这件事情的人。

所以想要让听众相信你的话，最好能让他们先相信你，除了日常建立的影响力和信任之外，在评审过程中表现出来的信念和气势也非常重要。没人愿意跟软蛋合作，尤其是产品经理。

4. 不要为了赢而争吵

需求评审中经常会发生争吵，产品经理站在台上被人挑战，不论是挑战方案还是个人能力，都会让人不太舒服。人在面对挑战和危险的时候，会自动开启战斗或逃跑模式，也就是要么选择对抗，要么选择逃避。开会的时候我们站在台上无所遁形，所以大部分人会本能地选择对抗，也就是开始为自己的方案和想法辩解。

对抗通常会激起更多对抗，很快大家都忘了本来要做什么，只是希望能赢得辩论。一旦大家的目标是赢，争吵就变得毫无建设性。所以说争吵本身不可怕，可怕的是为了捍卫自己而吵。产品经理要对自己的情绪活动敏感，当意识到是因为自尊而开启战斗模式的时候，你需要能尽快刹车。

防止将不同意见升级为争吵的一个办法是用陈述句复述并确认，我举个例子，比如我们正在讲客户服务流程，你说客户来电结束后，需要记录在案并设置下次跟进提醒时间。听众插嘴了，说：“你了解过现在的流程吗，所有的来电都记录提醒时间，服务人员还用不用干别的了？”

这句话可能不太友好，如果你恶向胆边生，回他说：“我看是你不了解流程吧，你知不知道有多少没有及时后续跟进造成的客户投诉？”照着这个趋势，说不了几句应该就要吵起来了。

可是如果你能及时摁住情绪，把态度描述忽略掉，用陈述句去复述提问人的意思，你说：“我理解一下，你是想说，并不是所有的来电都要记录提醒时间”，对方可能还会挑衅，说：“废话，一天一个服务人员平均接两百个电话，你说呢？”

你继续摁住情绪，复述：“所以我理解你的意思是，如果我们要求服务人员为未处理的来电建立提醒，会降低工作效率。”

用这样的风格不断复述的同时，你可以引导他把问题背后的问题说出来。这个过程的目的是通过他的反对找到有建设性的建议，而不是赢得争论。

另外，用这样的方式还可以让提出挑战的人意识到他自己在对话中混杂了情绪，从而被你引导回到冷静讨论的范围中，而不是继续抬杠。不要让情绪影响了判断，更不要让赢得争吵取代做好产品成为你的评审目标。

如果没能控制好情绪，或者发现陷入细节无法自拔了，一定有礼貌地喊停，先搁置争议继续后面的内容，不要浪费其他人的时间。

5. 小公司的需求评审

最后想简单说一下关于小公司、创业团队的需求评审方式。在小公司中，需求评审未必会成为一个仪式化的流程环节。可能是产品经理跟老板聊几句，然后写比较短的文档，或者画个原型，跟工程师面对面交流。

然后工程师在设计开发的过程中，可能还会不断跟产品经理交流，来进一步明确需求，可能需求分析的过程直到产品上线的一刻才最终成型。

这样的工作方式对小团队来说可能是合适的，因为它足够灵活，而且没有流程成本；但我的建议是，小公司可以没有正儿八经的大型需求评审会，但最好要有需求评审的过程。

这个评审可能是跟工程师小范围的需求串讲，也可能是产品经理自己在脑海中对自己的一次模拟评审。不能因为缺乏评审会，就把没有完全想清楚的需求交付给开发，浪费了时间，也影响士气。

总结

到这里，关于需求评审的分享就结束了，需求评审虽然看起来像是一个环节，却影响了需求从产生到实施的整个周期，也是对产品经理基本功、业务了解和情商的一次综合考验。

今天的分享中，我们提到要避免知识的诅咒，以及用引导而不是强迫的方式让相关同事用心投入，之后说到了要利用自己的态度感染他人，并且尽量避免以赢为目的的争吵。希望这些建议，能在你的需求评审中发挥作用。

最后，在此祝福你春节快乐，狗年顺心，能在自己的职业生涯中有新的突破，我们一起加油！

!

戳此获取你的专属海报

39 | 产品案例分析：SeatGeek的订票设计

SeatGeek 是一个订票类的 App，我们买过电影票，可能也买过一些话剧或者体育比赛的票，所以应该都用过类似的应用，今天介绍的 SeatGeek 中有一些挺好玩的交互细节，希望可以给你带来启发。

SeatGeek 的整体结构比较简单，可以根据不同维度去浏览活动和节目，也可以搜索，还可以订阅追踪。

门票的快速浏览

我们重点看一下订票的交互流程。我们可以看到页面上方是一个场馆的缩略图，不同区域的座位用不同的颜色标识，不像我们平时买电影票或者一些演出的票那样，所有的座位都平铺开展示，这里只是有限的一些小点。

这里还有一个很有意思的交互，缩略图上的每一个点代表门票，每个门票蕴含的信息量比较大，那么如何快速地浏览所有的门票呢？

传统的思维可能是点击某个点的时候，浮层展示一下门票详情，这样做效率非常低，要不断地点；而 SeatGeek 采用的方式则是滑动下面的列表。

在滑动的过程中，利用图和列表的联动把门票的信息交代清楚，可以快速地浏览门票信息。滑动中还利用了 iPhone 的震动，每个切换会有一个微小的震动，这是一个新颖的设计。

票价的直观筛选

还有这里的 Filter，有一个细节，虽然很常见，但还是分享一下，就是当筛选价格的时候，它有一条曲线展示每个价格区间的门票量，随着你修改上下限，能够非常直观地看到总量和你选中的价格区间的门票量。

过去我们在做筛选或交互步骤的时候，思考逻辑是单线的，比如用户向系统发出请求，要求筛选某一个价格区间内的门票，系统响应请求，展示这个价格区间的门票列表。

如果我们跳出这个单线思维，去考虑在用户提出筛选请求时，还有没有其他对用户有价值的信息可以一起反馈。比如说，反馈的信息可以加入整体的票量以及价格区间的分布。

位置的真实视角

再看一个有意思的细节，当我们买门票选位置的时候，有一个痛点，就是如果我们不了解场馆，很难判断不同位置的视线怎样，我们来看这个 App 怎么解决这个问题。

打开个体育比赛，我们点击一个位置点，你可以注意看，上面的缩略图变成了这个位置的真实视线情况，我没有去研究这个图是怎么收集的，但可以想象这会是一个苦活儿，能做到这样很让人感慨，我觉得我自己有时候挺缺乏这种踏踏实实下笨功夫解决问题的劲头。

卡片的流畅转场

最后一个很小的细节，就是当我们点击 Checkout 的时候，不是替换页面，而是直接在当前页面浮出卡片，我们之前也讲过类似的细节，比如 Fabulous 里面，这么做不加入转场，交互体验衔接很流畅。这是移动端设计中，保证用户体验顺滑很重要的一点。

!

戳此获取你的专属海报

40 | 新年给产品经理的几碗鸡汤

“成长不是顿悟，而是练习。”——朱赟

除夕已过，假期未满，先给你拜个年，祝你在 2018 年剩下的三个多季度里，烦心事尽量少一点，不论遇到顺利还是不顺利，都能尽快恢复平静。

掐指一算，我也是有十年的产品设计从业经验了。虽然职业生涯犯了很多错，摔了很多跟头，但庆幸赶上了好时候，还是有不少积累与收获的。今天的分享，我不打算聊某个具体的主题，而是讲四条细碎的感悟和原则，希望能给你带来启发。

取一利、生一弊，深思熟虑，扛住诋毁

世上没有完美的产品设计方案，产品经理的日常工作，就是在各种并不完美的方案中作出取舍。

对一部分人友好的设计，可能会伤害到另一部分人的利益，伤害自然会带来抱怨甚至谩骂。对于产品经理来说，一定要深思熟虑，想清楚可能的利弊，坚定地做出选择之后，坦然面对选择带来的负面声音。

有的产品经理做出判断之后，听到负面声音就犯怂，不敢坚持，想要讨好所有人。要知道，做产品和做人一样，一个讨好所有人的产品是平庸而缺乏个性的，这时候，产品经理要有自己的权衡取舍，有自己的坚持。

另一方面，也不要盲目地在没有经过深入思考的情况下瞎坚持，如果某些特性上线之后，用户抱怨的内容或规模超出了你的预期，那可能就要果断做出一些调整，不要将错就错。

比如即时通讯应用的已读回执。我们可能都有过类似经历，别人发来的消息，我们读完之后暂时不方便回，或者不想回，一旦有了已读回执，就会给收到消息的人造成一点心理压力，觉得有必要尽快回应。

而对于发消息的人，有时发出的消息就像被扔进薛定谔盒子的猫，如果没有已读回执，对方没有回应，就无法获知状态，对方究竟是没有收到，还是收到了没看，还是看了没回。

所以这是一个典型的偏向消息发件人的特性，在我们日常熟悉的即时通讯工具中，微信是没有这个特性的，但是钉钉有。

微信的设计原则应该是收件人体验大于发件人，同时，微信的聊天体验一直推崇简单有力；而钉钉则不同，对钉钉来说，用户关键人甚至不是收发信息的人，而是企业管理者，他们的需求是沟通效率，所以已读回执是一个重要特性。

我不止一次听到钉钉用户抱怨，已读回执这个特性给他们带来很多压力和尴尬；但如果钉钉想清楚了自己的定位，并针对这个特性做出了抉择和取舍，那么就应该坦然面对这样的抱怨，接受不完美方案带来的阴暗面。

关于坦然面对抱怨，还有一点提醒就是：不要封闭自己。不要干脆彻底忽略负面意见，还是要虚心吸取，从中找到意料之外的、有价值的信息，这也是一个考验心性的机会。

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

产品经理要忌讳“广谋而不决”和“优柔寡断”，不要“每种可能都去调研，但却迟迟不做选择”。

有时候，我们会不自觉地放大一次抉择的作用，在各种商业故事中，主人公会因为在关键时刻的一次生死抉择力挽狂澜，救公司于危难，支大厦于将倾；所以我们会时刻惦记着去寻找宏大的“关键抉择”，不希望因为一步错棋导致全盘皆输。

但事实上，在我们的生活和工作中，很少有哪一个抉择是真正的“生死抉择”，当我们在几个选项中持续犹豫时，说明这几个选项可能差不多好，所以不用太纠结究竟要选哪个。

尤其是对发展期的产品设计来说，单次决策的质量不是最重要的，决策的速度和频率才是。我们应当训练自己的决策能力是：快速做出大量的、质量还不错的决策，而不是花费大量时间和精力做出一个无懈可击的决策。

如果能从内部、而不是传记和故事的角度去观察，我们会发现任何成功都不取决于某一个单独的决策，而是由一系列的决策和行为造就的。好的产品发展需要不断迭代，不断审视和修正，而不是寄希望于早期的某一个重大判断。

什么都不做，或许就已经跑赢了大盘

有一次我到小区里的一个快递柜里取包裹，包裹取出后，屏幕上显示：“您的包裹存放 xx 小时，击败了本小区 x% 的人”。

我盯着屏幕愣了很久，不知道究竟是什么意思，如果我想要击败本小区更多的人，是应该将包裹放得更久，还是应该尽快取走；而这个信息对我有什么价值，对产品设计者又有什么价值呢？

后来百思不得其解，于是我猜测，做这个特性的产品经理可能纯粹只是为了做而做。想想也可以理解，当快递柜用户界面趋于稳定之后，产品经理可能会觉得不做点事情特别对不起自己拿的工资，于是干脆就做个特性吧。

这也是为什么我们早先经常赞叹于微信团队“克制”的难得（虽然据说张小龙自己并不认为自己是在克制），尤其是当你的应用开始成为入口，开始有了各种用户和反馈之后，你可能会发现很多虚虚实实的机会，想要做各种各样的尝试。

这些尝试如果单独去看，每一个可能都无伤大雅，但加到一起，可能就会让产品的调性发生变化。比如很多电商产品的 App，一旦有了大流量，就开始不断膨胀，甚至堆砌了一些烂尾逻辑和走不通的流程，进而影响到核心用户体验。

所以在很多时候，或许什么都不做就可以跑赢大盘。比如想想 Google 的核心搜索流程，这么多年连“ I’m Feeling Lucky ”都没有变过，这来自于对用户与产品核心体验的理解和信心。我们应当对一些东西保持克制或冷漠，并始终对用户怀有敬畏。

平淡无奇，十之八九

很多人在入行之前觉得，产品经理是一份每天都需要创造的工作，有充足的空间，可以依据自己的审美和喜好设计东西，有一切尽在掌握的感觉。闭上眼睛仿佛就能看到产品上线，万众沸腾，改变世界。

事实上，做产品没有那么多激情时刻，就像里尔克的诗说的那样：“哪有什么胜利可言，挺住就意味着一切”。我们绝大部分的工作，都是在平淡、纠结和琐碎中度过的，就如同日常生活一样，没有那么多聚光灯时刻。

我之前看到过一个数据，说这个行业中百分之七八十的项目最终其实是以失败告终的，或者没有交付、或者交付了但没有达成预期的目的。

这就是产品工作的真实写照，产品经理要保持一颗平常心，不要因为几个项目失败了，就失去对自己的信心。面对工作中的琐碎也要保持耐心和认真，很多时候不是我们争取到了胜利，而是我们有足够的耐心和储备等到了它。

坚决执行，不要绣花

前些日子，有幸跟斑马资本的吴永强老师有过交流，他给我分享了很多创业心得，并给了我许多建议，其中一条是：“在战略上谨慎，在战术上激进”。

我们日常工作中很容易出现的一个状况，就是在战术执行中不断地质疑战略，结果影响了进程，也伤害了士气。相反，一旦经过充分论证之后，做出了方向上的判断，就应该搁置争议，全力执行；并且执行的过程应当大开大合，快进快出，不要绣花。

几乎所有的执行方案都是有瑕疵的，就如我们这次分享提到的第一点，硬币有两面，如果像绣花一样，一寸一寸地分析，总能够找到缺陷和错误，如果因为缺陷和错误就怠慢了手头的工作，整个规划的节奏就会乱掉。

电影《大决战》中，林彪指挥部队在塔山激战，战场开阔无险可守，前线死伤无数，林彪却说：“给程子华发电报，我不要他的伤亡数字，我只要塔山”。虽然做产品不需要像打仗这样悲壮和激烈，但决策一出，就应该坚决执行，不要再犹豫。如果战略上有问题，等告一段落再复盘，不应该在拉车的时候看路。

多喝热水，新年快乐

在春节假期的尾声，我分享了做产品经理以来的一些感悟：学会接受不完美，提高决策效率、避免优柔寡断，能够用良好心态面对日常的琐碎，以及战略上要谨慎、战术上要激进。

希望你能够保持良好的心态，不要浮躁也不要气馁，在新的一年中踏实做事，锐意进取，为自己的用户创造价值。

再次祝你新年顺心，狗年大吉，一起加油，我们下次再见。

!

戳此获取你的专属海报

41 | 产品经理的项目管理心得

“将者，智、信、仁、勇、严也。”——孙武《孙子兵法》

产品经理有时需要承担不同角色的责任，项目管理就是其中一种。一方面，很多互联网企业中没有专职项目经理，产品经理可能需要在项目中担任项目经理的职责；另一方面，产品经理的日常工作就是协调各种不同的角色，组织各方资源来推动事情发生。

从这两个角度来说，都需要我们了解和掌握项目管理的技能，今天，我就跟你分享关于项目管理的一些经验和感悟，希望能给你带来启发。

1. 影响力大于权力

互联网公司的项目团队通常是根据项目范围临时组建的，团队成员来自于不同的职能部门。这就意味着产品经理对项目组成员并没有行政权力。

在这样的环境中，作为产品经理或项目经理一定要依靠影响力来组织团队。我在前面的专栏文章中专门分享过“产品经理如何获得非权力性的影响力”这个主题，这里不再重复，但还是想要提醒你，即便是在临时组成的短期项目组里，也要有意识地建立和利用影响力。

千万不要抱有“我是这个项目的项目经理，所以你们要听我的”，这样的态度和言行，否则很容易让项目组内部出现罅隙。

在另一些情况下，我们也有可能会获得明确的行政权力，比如一些长期项目可能会单独建立团队编制，或者，绩效考核时，项目经理可以拥有一定的权限等等。我的建议是：即便在这种情况下，也要尽可能利用影响力而不是权力来组织团队、管理项目。

利用权力威逼利诱，总是隔着一层障碍，利用影响力团结一心，才能打造更有效率的项目团队。

2. 管人大于管事

项目进行的过程中，有的项目经理会根据流程和制度，照本宣科地执行项目管理手段。

从单个项目的角度来看，这样的方式可能不会有太大问题，但如果忽略了项目中人的因素，那么项目抵抗风险的能力以及达成卓越的可能性都会降低，并且久而久之，会消耗整个团队的心力和士气。从我自己的体会来说，我感觉在项目中，对人关注的重要性或许会超过对执行具体事务的管理。

士气是团队中看不见的那只手，项目经理需要对此有感性上的敏感，关注整个项目组的士气。士气低落会影响交付能力，并且也会造成团队的不稳定。

在项目组中提高士气的大前提是：你做的产品规划和设计要靠谱，大家能够理解并且看到希望。在此基础之上，也要注意项目的里程碑和仪式感。在达成阶段性的目标或交付阶段性的特性时，可以买点水果大家一起庆祝庆祝，或者哪怕在项目群里郑重其事地宣布一下，既可以保持项目组内部的信息透明，也能让大家时刻感受到项目在持续向前推进，不至于疲倦懈怠。

3. 交付大于计划

项目管理通常都是基于项目计划开展的，包括分析预估并排定计划，在项目推进过程中设置里程碑和观测点，以及最终保质保量交付上线。我们都会根据计划来确保项目进程始终保持在轨道上行进不失控。

这个过程需要项目计划保持一定的严肃和刚性，尤其是当项目涉及人员数量较多时，某些任务如果延期，就可能造成较大的影响。所以我们会反复强调项目计划的重要性，它相当于项目的一条主线。

但我们也要知道，项目计划只是手段，项目交付才是项目管理的目的，所以不能过分拘泥于计划，因为过程中的一些意外自乱阵脚。

项目管理中我们要能识别关键路径，清楚任务依赖，并且建立尽可能多的观察点，在问题发生前预警、问题发生时快速做出调整。这要求我们在脑子里或纸面上有一张完整的甘特图，即使出现问题，也能弄清楚可能的影响范围和应对措施。

我曾经看到一个项目经理的实践，他在管理复杂项目的过程中，把所有项目进度画在一张泳道图上，并且根据前后依赖在不同的任务之间画上箭头，每个节点用颜色来标识：进度正常的标记为绿色，识别到风险标记为黄色，如果发现问题将会导致延期就标记为红色，任何环节出现问题可能造成的影响都一目了然，非常清楚。

当项目进展出现风险时，应对方案基本就是三招：“加班、加人、砍需求”。

先考虑加班，如果加班搞不定，考虑往项目组中增派人手；如果加人也解决不了问题，就要开始根据优先级倒着往下砍需求或者改方案；不到万不得已尽量不要延期，虽然可能有些项目从业务上来说延几天并不影响大局，可一旦形成习惯和风气，团队就会变得越来越散漫。

我刚开始学做项目管理的时候，前辈曾经给我一句忠告，他说做项目经理，交付就是承诺，只有保住交付，才能保住饭碗。

另外，还有一个建议就是在项目计划中争取缓冲时间，我过去经历的大部分项目评估都偏向乐观，工程师觉得三天能做完的东西，可能需要五天才搞得定；所以我们要在项目中，尤其是在关键路径前后，根据风险大小和团队情况，在评估的结果上留出余量，应付可能出现的延期。

这一条建议可能在敏捷开发的实践中没有那么突出，但依然需要注意，当涉及功能模块依赖时，我们应当对交付尽可能严肃。

4. 正确看待项目管理工具

项目管理是一项技术活，涉及了很多工具和方法，小到一张燃尽图，大到一整套执行规范。面对这些工具，有两种极端的态度，一种是全面实施，严格按照工具来执行项目管理；另一种是觉得工具都是形式主义，没有价值，根据自己的经验管理项目就可以。

这两种态度都不可取，我建议你要全面了解项目管理工具和方法论，同时不拘泥于它们。每一样工具和规范都是前人经验的结晶，通过研究这些工具的设计和构造，我们可以学习很多关于项目管理的洞察。

比如我们举个例子，敏捷开发的方法论中有个工具叫做站会，就是项目组所有人每天围在看板前依次介绍自己今天的计划。在站会中有一个设计，是用一个令牌——比如一支笔，作为发言的标识，只有拿到这支笔的人可以说话，其他人保持安静，说完之后再把它传给下一个人开始发言。

这个设计本身非常形式化，但我们可以通过这个细节去洞察，站会中可能会发生的现象，就是本来设计的初衷是做一个短平快的沟通，结果却演变成了七嘴八舌的细节讨论会，这样一来就降低了站会的效率。通过这样的观察和思考，我们即便没有丰富的站会经验，也可以明白我们在站会中发生的现象，以及我们应当避免类似现象的发生。

另外，所谓尽信书不如无书，我们也需要根据自己的项目和团队情况，选择合适的管理工具。并不是所有的团队都需要站会、所有的项目都需要燃尽图。我们应当在深入了解各种工具的基础之上，择善而从，才是正道。

5. 稳住才能赢

我认识的优秀项目经理，都有一个共同的特点，就是风格非常沉稳。在项目出现意外的时候，他们也会慌张，但都可以迅速调整心态，冷静思考对策，绝不会手足无措。这一点非常重要。项目经理的心态如果崩了，其他团队成员信心就更悬了，所以作为项目管理者，一定要稳得住。

除了心态要好之外，项目经理能稳得住，最重要的是对整个项目状况的通盘掌握。项目经理要深刻地理解业务背景和项目目标，并以此把握好相关优先级，管理好项目边界，控制好成本和质量，只有这样，才能在项目推进过程中尽早识别和应对风险的发生。

这一切都需要投入精力和时间去学习，所以项目管理并不是一个纯粹的经验学科，而是一门手艺，不能随意而为，而要刻意练习。

总结

总结一下，在今天的分享里，我提到了在项目管理中应当更多地利用影响力而非权力，应当更重视人而非流程和制度；之后，我谈到了计划是交付的手段和确保交付的重要性，最后又聊到了如何看待项目管理工具，以及项目经理所需要的心态和控制力。

这次分享中我并没有讲具体的方法和工具，如果你想了解这方面的内容，我可以推荐几本书：《人月神话》《构建之法》《团队之美》《网易一千零一夜》，你可以挑感兴趣的读读看。

如果你有对于项目管理的心得，欢迎在留言中跟我分享，最后祝大家新年第一个工作日开门红，我们下次再见。

!

戳此获取你的专属海报

42 | 产品案例分析：Unread的阅读体验

Unread 是一个非常著名的 RSS 阅读器，如果你是 RSS 爱好者的话，肯定听说过这个应用。它的设计非常漂亮，简洁精确，阅读体验很好。

Unread 的设计，从首页到列表页一以贯之。页面的版式设计也非常统一，元素很少，颜色也很少，只有黑灰红三个颜色，却很精致，有设计感。

设计的美学：乍见之欢 vs 久处不厌

关于设计我想多说一句，有一个我特别喜欢的设计师，之前跟我合作去做一些 Web 页的设计，她曾经跟我说，设计应该放到更长的视角中去评价，很多第一眼看上去很惊艳的设计并不一定是好的设计，它有可能会过于抢戏，而把真正的价值掩盖掉。

好的设计应该是长时间使用，但让用户感到不疲惫，甚至用户都没有意识到设计的存在，它会低调地藏到内容后面，去支撑架构和逻辑。

这一席话对我影响还是挺大的，我们评价设计的时候通常都是会从看到它的那个片段出发，觉得惊艳或者赞叹，或者平淡无奇，但其实如果我们可以从更长的时间段出发去评价的话，很多乍一看平淡无奇的设计，可能是非常好的设计。

继续回来看 Unread，我们来看列表页，这个列表页没有去取 RSS 源的图，没有图可能会让页面看起来没那么活泼，但是也会更简洁直观地展示信息。

字体的差异：英文 vs 中文

这里有个细节，对比看中文和英文的文章，会感觉英文表现比中文好很多，英文标题有明显的加粗，跟摘要有很明显的样式差异；但中文的差异就小很多。当然 Unread 应该是主要针对英文做的设计，中文表现稍微差一点很正常。

但我们在同一个列表对比两种设计，会比较直观地感受到差别，当主题和正文的差异足够明显的时候，我们随着往下拉列表，视觉是很容易跳读的，视线可以快速地定位到每一条的标题上；如果差异不大，像中文这样，当然也可以跳读，但好像就会稍微累一点。这个道理没什么高深的，可是在这里对比还是挺直观的。

还有一个是关于这种差异来源的，就是我们看到很多国外很漂亮的版式设计，用到中文的时候就会差一截，长度、字体和字型都不一样；所以当我们想要去借鉴的时候，一定要意识到这个差异，不要一股脑搬过来，可能会不伦不类。

对于版式设计，其实可以多借鉴日文的东西，因为日语里面有很多汉字，不太会有字型差异带来的设计效果差异。

信息架构的逻辑：解决问题 vs 制造问题

我们再看整个架构，会看到统一入口或者某个源的入口，然后进来就是列表，点击就是详情，非常自然。当然，因为 RSS 本来的逻辑结构就简单，不需要什么特别的设计。

但是，从文字内容的设计出发，更容易去理解一个事情，就是设计与信息本身的关系，我之前看过一本书叫《无界面交互》，里面有一句话我特别喜欢，说过载、混沌和困惑并不是信息的特质，而是设计的失败。

其实信息本身就有其逻辑和结构，而不是说因为有了信息架构设计，才被分门别类地安放在不同的槽里面，很多时候我们会陷入到一些经典的范式中，比如抽屉，比如 Tab，比如九宫格。

好像是先有了架构，再往里填充信息，这个逻辑其实是不对的，应该是先理解信息本身的结构，再考虑用什么样的设计去自然地接住它。要让设计去解决问题，而不是制造问题。

另外说一下这个极简设计是如何做交互的，除了在架构里点来点去，按图索骥之外，还利用了长按和上下左右滑，在几乎所有的界面上都响应这几个交互手势，而且有一个很精致地动效连接，非常连贯。

!

戳此获取你的专属海报

43 | “玩”的力量：从游戏设计中学习产品设计（上）

“玩游戏，就是自愿尝试克服种种不必要的障碍。” —— 伯纳德·苏茨（Bernard Suits）

你有没有考虑过一个问题：从某种意义上来说，打游戏和做工作的性质是类似的。它们都需要在一定的规则框架内，克服困难，完成目标。

不同的是，打游戏是我们“自找的”，没有什么强制要求，我们却主动花费精力和金钱投入其中，乐此不疲；而工作为我们提供了收入来源和社会地位，我们却经常心猿意马，叫苦不迭。

如果抛开外在的表现形式，只从编程的角度去思考游戏的实现，我们会发现让玩家魂牵梦萦的背后，只是内存中变量的数值或显存里不同的色块。

那么，究竟是什么让游戏充满了不可抗拒的魅力，让人们自愿投入其中，难以自拔呢？我们设计的产品有没有可能像游戏一样，也具有这样的魔力，让用户持续投入其中呢？

我并不是一个资深的游戏玩家，所以便带着这样的疑问，读了几本跟游戏设计相关的书，也尝试玩儿了一些流行的商业游戏和独立游戏，接下来两次的分享中，我就来谈一谈自己对游戏的一些思考和理解，希望能给你带来启发。

游戏设计的手段

如果追溯历史，我们会发现游戏其实是一门古老的学问。我去年在台北故宫博物院看到了宋朝苏汉臣的《秋庭戏婴图》，画中是一对正在聚精会神玩游戏的姐弟，身旁堆放了很多当时流行的儿童玩具。

带我们参观的讲解员仔细地解释了这些玩具的构造和玩法，很精巧也很有意思。我当时就在想，虽然这些宋代的孩子没见过电脑，没见过 PS 和 Switch，但其实他们从游戏中获得的快乐也许跟我们并无二致；而游戏本身，它的内核或许也并没有因为时代的变革而发生变化。

有很多书对游戏设计做了系统化的解构，在成功的游戏设计中，有一些通用的设计手段和设计原则，它们支撑了游戏性，并吸引玩家持续地在其中投入了精力和时间。我们应当学习和借鉴游戏设计，把它们应用到产品设计中。

游戏设计手段 1：持续实时的反馈

实时的反馈是游戏中最常见的设计手段。不论是吃掉砖块里长出来的蘑菇，还是命中远方山坡上举着平底锅的敌人，游戏一定会立即通过声音或影像给予玩家以反馈，它既是互动，也是奖励。

这种奖励会在神不知鬼不觉中激活我们的低级神经反应，达到一种生理上的过瘾；然而，当我们全身心沉浸在游戏情节中时，或许并没有注意到，自己已经被这些感官反馈激发了。这也是游戏设计的精妙之处，就像是用一只你没有注意到的、看不见的手拉住你一样。

我们可以通过一些方式去理解这些反馈带来的引力，前些日子微信发布了跳一跳小游戏，一夜之间周围很多人玩儿。我也试了试，发现总是得不到高分。

后来我有个分数很高的同事跟我说有个窍门，就是：“玩儿的时候把声音打开”。于是我打开声音试了试，发现在有声音的情况下，不但自己的表现更好，而且觉得这个游戏似乎“更好玩了”。

类似的道理，在产品的交互设计中也一样。比如我们在做按钮设计时，都会做一个点击状态的样式，当点击或触摸到按钮的时候，背景颜色反显一下或者阴影变化一下，这样让用户在点击时有一个直观的反馈。

这个设计说起来可能没什么大不了的，很多人都没有注意到，但如果你试着把这个反馈拿掉，让按钮在点击时没有变化，那立刻就会觉得别扭，会很难受。

我们之前在分享 Mimo 的时侯提到过它的实时反馈，就是当用户完成一道题目的时候，除了声音和视觉效果的反馈之外，还会立刻对题目的正误做出解析。

我之前也做过一个答题类的 App，当时设计了一个效果是：用户每完成一道题目会有一个动效，屏幕上淡淡地闪现一个“+1”的字样，然后立刻看到“已答题数”的增加。这一点就是希望利用这样的设计，对用户进行潜意识中的奖励。

还有我们在分享 Trigraphy 时提到过的进度条，也是一种实时反馈，它可以直观地让用户和玩家意识到，自己在哪里，距离目标还有多远，给人们继续玩下去的动力。

类似的技巧很容易应用到产品设计中，但要注意过犹不及，不要给反馈效果加太多戏，不要让用户感到突兀和莫名其妙。前段时间玩儿一个游戏，开始玩儿的时候，每做一步操作就出现很震撼的效果，还会有大字和感叹号，表扬我说：“你太棒了！”让我很不舒服，这就是一种负反馈。

除了这些交互细节的设计之外，实时反馈能给我们的另一个启发是关于生活的。当我们从电子产品中越来越容易获得实时反馈时，我们的大脑会逐渐适应并迷上这种感觉。这样一来，我们很容易对那些奖励周期比较长的事情产生厌倦。

在生活和工作中，许多了不得的成就都来自于没有显著反馈情况下的坚持，比如锻炼身体、学外语或积累产品设计经验等等。我们应当具备延迟享受（Delayed Gratification）的耐力，才能够收获更多成绩。

游戏设计手段 2： 人性的开关

我们骨子里或多或少都有惰性、恐惧和贪念等等特质。当设计命中这些特质时，我们就很容易受到牵制或影响。

关于这一点的争议很多，因为人性就像是藏在我们体内的开关，可以伸一只手进去打开或关闭它们——不论这只手善良与否。很多人质疑这样的设计手段是一种操纵，而有的人认为这是游戏工业的规则，没必要大惊小怪。

暂时放下道德争议，这些设计至少都伴随着深刻的人性洞察。比如游戏设计会利用我们与生俱来的囤积欲，为了收集不同颜色的勋章或钻石，我们可以忍受大量机械和无意义的重复。

再比如，游戏利用我们对损失的厌恶，当我们获得某种道具之后，就会愿意付出大量的精力和代价避免它被别人夺走，这在心理学上也被称作禀赋效应；还有几乎所有的游戏都在利用人们对未知的好奇心，藏着道具的箱子、锁住的门，以及剧情中埋下的悬念。

还有游戏之所以持续吸引玩家上瘾的秘诀——成就感与自豪。自豪是一种很特别的情绪奖励，我们渴望体验成功或感受到自己的强大，我们渴望能够清晰而明确地看到自己变得越来越好。这就是虽然游戏从不给我们发工资，我们还是能持续投入其中的原因之一，我们希望在游戏中成就自己。

毫无疑问，同样的手段当然可以被用在产品设计之中。比如最常见的用户等级体系，以及各种成就勋章和排行榜，早已经成为拥有用户体系的产品粘住用户的基础手段。还有各种收集勋章，点亮道具的营销活动，虽然好像没什么品味，但确实非常有效。

还有刚才提到的禀赋效应，指的是当个人一旦拥有某项物品，那么他对该物品价值的评价会比未拥有之前大大增加。

我们熟知的各类代金券赠送都是在利用人们的这种心理，送用户 30 块钱代金券，让他买 80 块钱的东西，远比向他推销 50 块钱的东西来得容易。

如果这 30 块钱的代金券还能“师出有名”，比如分享给朋友才能得到或者老用户才能得到，那就更容易勾住用户，他会觉得这 30 块钱代金券是自己好不容易才赚到揣在兜里的，不花是损失。

总结

今天，我从游戏设计的手段开始聊起，介绍了游戏中“持续实时反馈”“利用人性”两种手段，并谈到了这两种手段在产品设计上可能的应用方式。在下一次的分享里，我会继续这个话题，接着跟你聊聊游戏带来的启发。

你是游戏玩家吗？游戏有没有给你一些启发和帮助？欢迎留言分享，我们今天的内容就到这里，谢谢你，我们下期再见。

!

戳此获取你的专属海报

44 | “玩”的启示：从游戏设计中学习产品设计（下）

“要保持淡定，就算输掉了比赛，你还有人生。”—— DOTA 2 读条台词

在上一次的分享中，我从游戏设计的手段开始聊起，介绍了游戏中“持续实时反馈”和“利用人性”两种手段，并谈到了这两种手段在产品设计上可能的应用方式。

在今天的分享里，我会继续跟你聊聊游戏设计带来的启发，讲一讲游戏设计中“增加社交元素”和“构建意义”两种手段，以及游戏机制的力量。

游戏的设计手段

游戏设计手段 3：与社群建立联系

人是社会动物，我们都渴望与社会建立联系，游戏中会有大量人与人之间的纽带设计，吸引玩家持续投入其中。

比如我前一阵子一直在玩《王者荣耀》，它最大的吸引力其实不是游戏本身，而是跟几个要好的朋友合作完成一件事情的体验。我们在游戏中分工配合、互相协助的过程中，在这个过程里，我体会到了因为融入和关联而产生的开心。

跟游戏一样，产品设计也可以通过加入社交元素来构建持续的吸引力，不论是在应用中加入社区，还是做一个排行榜，哪怕是在内容里做出用户的头像，都可以让一个冰冷的产品变得有人情味和烟火气。

比如我们之前分享过的 Learn Python 中的排行榜和社区，还有近几年崛起的社交电商应用拼多多，就连音乐播放器里面都有“附近的人”这样的社交功能了。

关于社交元素的应用，有一个提醒是：类似的产品特性在计算成本和投入的时候，一定要考虑到运营。任何有人群的地方，都需要持续投入运营的力量，如果规划不力，可能会出现冷冷清清，有不如无的情况。

游戏设计手段 4：构建意义

每个人都渴望成为超越个体的伟大事业的一部分，各种游戏通常都会把自己放到一个宏大的背景中，拯救宇宙、拯救地球或拯救公主。玩家会将自己代入故事，建立使命感，为自己疯狂点击鼠标或机械地移动拼图的行为找到意义。

这是游戏设计惯用的手法，因为游戏本身通常是脱离现实的，为了在虚拟中把游戏世界有血有肉地建立起来，就必须通过叙事的手段去构建游戏的意义。比如最近流行的吃鸡游戏，为什么要不由分说见人就打？这一定需要“大逃杀”或者“军事演习”这样的背景来建立合理性。

而产品设计通常就是在现实语境中解决实际问题的，不需要构建环境和意义，那么说，关于这一点，产品设计能向游戏借鉴什么呢？

其实还是可以借鉴的，比如对于英语学习的应用来说，可以通过强调跨文化交流的意义，来缓解用户背单词带来的枯燥。

再比如我之前做过一款医学职业资格证考试类的 App，我在开屏的界面上，放了一段希波克拉底的医学誓言。这样的做法是希望可以唤起用户学医的使命感。

或者我们可以通过构建意义的手段去润滑产品的体验，比如微信朋友圈的“赞”就是一种。你可以设想一下，如果这个按钮被设计成“阅”，即便操作完全一样，带来的体验也会大相径庭。

游戏机制为核心的启发

独立游戏界有一位以观点犀利著称的制作人 Jonathan Blow，他一直旗帜鲜明地反对空洞的游戏内核，反对游戏设计中的操纵。他认为优秀的游戏来自于精妙的机制，而非处心积虑的音、画设计。

他推崇清晰易懂、简单有力的游戏机制，就像物理定律一样，游戏中无穷的变幻和惊喜都自然而然地从中演化出来，并不会让玩家觉得突兀。Jonathan Blow 以自己的作品《时空要塞》举例，其中所有的玩法都基于一个简单的假设：如果时间可以倒流，世界会变成什么样子。

他的观点虽然有些激烈，却对我非常有启发。一个好的产品或运营活动的设计也是一样，那些精巧的、处心积虑的功能性设计，远不如关键性的机制设计来得重要、有效。

我们用最近很流行的知识产品推广来举个例子。

假设我们想推进某个知识产品的销量，可能会考虑促进用户间的传播，于是我们设计分享功能；为了让分享率更高，于是我们精心地设计分享按钮的位置、尺寸和颜色。

分享后，为了让分享出去的内容转化率更高，我们还会不断调整文案、样式设计，最终一点一点优化用户传播带来的销售。这个过程就是精巧和处心积虑的功能性设计。

那什么是机制设计呢？

如果我们不去雕琢分享功能，而是设计一套分销机制，比如用户 A 分享了内容，如果用户 B 通过这个分享产生购买，则将收入的一部分作为奖励分给用户 A。

如果用户 C 通过 B 的分享又发生购买，那么用户 A 和 B 都会得到一定比例的提成。不过请注意，这个设计很容易让我们想到传销，法律对多级分销和传销有明确规定，层级太多涉嫌传销是违法的。

在写就这篇文章的时候，三联周刊的电子版刚刚完成了一轮类似规则的运营，虽然海报设计得挺一般，但传播效果确实非常好。

类似的案例很多，优秀成熟的产品多半都有一个简单有力的机制，而内核空洞的产品，多半是靠花里胡哨的设计和奇技淫巧的操纵来支撑。

如果你陷入了无尽的功能性设计中很难突破的时候，不妨停下来回到产品机制重新出发去做一些思考，看看会不会有新想法。

总结

关于游戏设计我是外行，但是经过很长一段时间的观察和学习，让我对这个行业的认知有了很大变化，也越发理解了游戏的意义和价值，也对游戏从业者心生感佩。他们对游戏的信念与产品经理看待产品设计是类似的，所以我也希望这个行业能被更多的人了解和严肃对待。

这两次分享中，我们没有详细展开讲手段和工具的应用，所以在这里分享几本书，书中有更专业和完整的分析介绍，你可以挑来读一读。

先推荐《游戏改变世界》和《游戏化实战》，这两本书讲的是游戏设计原则和分析方法在通用领域的应用；接下来是《体验引擎：游戏设计全景揭秘》，这本讲的是游戏设计方法论以及背后的原理，不但很成体系，而且非常细致；还有《通关：游戏设计之道》与《游戏设计的 100 个原理》，这两本讲的是游戏设计中的一些典型工具和方法，也很好，都值得读一下。

你在设计产品的过程中，有没有从游戏里获得的启发和帮助吗？欢迎留言分享，谢谢你，我们下期再见。

!

戳此获取你的专属海报

45 | 产品案例分析：Chartistic的“复杂”图表

Chartistic 是一款移动端做图表的工具。

在一般的概念中，制作图表都是一项复杂的工作，我们要处理数据、处理图表的样式，进行各种各样的配置工作；而由于手机端使用场景的不稳定，以及交互方式的限制，要为手机端设计图表工具其实是挺困难的一件事情。

除了要删掉大量的配置功能，牺牲自由度之外，我们还要尽可能地利用各种交互可能性，最大限度地拓展物理的小屏幕带来的限制。

“假数据”的靠谱

首先是选择图表样式，它将图表样式的支持删减到只剩五种，前四种我们都很熟悉，柱状图、折线图、面积图、饼图，最后一种很有意思，算是一种信息图。

我们先选择一个折线图，打开后直接看到图，所见即所得的效果。这个跟我们想象中创建一个图表的过程其实是有点不同的，按照逻辑顺序，似乎应该先维护数据表格，再基于数据表格来创建图表。

这里是用假数据填充了数据位，直接就能看到表格。这个思路很值得学习，不是按部就班地走完逻辑流程，而是用临时数据先直接完成流程，然后再回来对中间步骤做调整和修复。

这个页面中直接给出了一些编辑的位置，标题、横纵轴这些，样式设计和文案也很直观，会召唤我们直接去点击编辑。一旦我们开始动手去编辑，是直接可以看到成果变化的。

这个感觉很微妙，不是在黑影中做一大堆工作，然后一开灯看到成果。就像我们产品迭代，不论多烂，先发布一个版本，哪怕不对外，有看得见摸得着具体的东西，感觉就会很特别，英文叫：On Track，中文可以翻译成：“上轨道”，心里就有谱了。

被放大的屏幕

我们再来探索界面，左边可以直接改变图表类型，数值都会保留，然后这里的数据点都是可以拖动改变的，我很喜欢这个设计，这里很符合手机的操作场景。

之后是设计，我们可以向右或者向下拉出参数设置的部分，这里有一个动效的衔接，参数设置部分是折叠出来的，而图表的主体部分稍微缩小，还保留在屏幕内，并没有转场。

这样的设计相当于放大了屏幕的面积，让我们感觉这些设置似乎就停靠在屏幕边缘，一定程度降低这个界面复杂度，让操作流畅而连贯。

自由度的取舍

再来看这些设置项，刚才提到一个完整的图表工具在向移动端迁移时的取舍，从这些设置项里面，我们可以看到一些端倪，跟我们平时做表格的各种设置比起来，这里的设置少了很多。这背后取舍的逻辑就是保留核心价值，删除自由度，提高易用性。

我们一起来看看去掉了哪些易用性，除了我们刚才说的，图表类型只有几种之外，可以看到所有图表元素的位置和字体字号之类也是可以预定义的，只能调整是否显示之类的细节，但还是保留了一些坐标轴配置之类的东西。

还有一个有意思的设计是图表的配色，我们是没办法完全自定义图表元素配色的，只能在几种配色之间切换，甚至我们不能指定配色方案，只能依次切换。不得不说，Chartistic 这么做非常有胆量。

从场景出发

我们再看一个功能点，我们如何调整图表中的数据值？我们可以看到，有两个地方可以调整，一个是我们可以在图中直接拖拽，另一个就是可以向下拉开配置菜单去输入数值。同样的，添加或者删除数据点也有两个地方可以操作。

这个东西本身没有什么设计难度，但我感觉它背后有种设计思想，就是不从功能出发，而是从场景出发。

我们做设计的时候，可能会觉得需要有一个删除或添加数据点的功能，然后根据功能结构放好了，认为自己已经提供了这个功能，任务就完成了。

但是，完整地提供功能不是设计的终点，把每一个场景理解清楚并做好设计才也是。哪怕一个功能在一屏中以不同的形式出现两遍，也不是不能接受的。

最后介绍一下这个类似信息图的小设计，很有意思，你可以在这里选择一个图形，然后用它来指示一个百分比指标，操作也很简单，就像是调整水位一样。你可以搜索各种图形，做出来的图形虽然简单，但却精致实用。

!

戳此获取你的专属海报

【第二季回归】二爷归来，再次扬帆起航

有时我会想，如果我所在的公司把我或整个产品团队换掉，换成一个更好的产品经理或团队，公司会有什么变化？这个更好的产品经理会如何解决我解决不掉的难题，如何跨过那些让我踉踉跄跄的障碍，如何给公司带来可观的成长？

这样的想法会立刻消灭我所有的沾沾自喜与嚣张跋扈。我跟那个假想中更优秀的产品经理暗暗较劲，努力希望自己做到跟他一样好。

又或许，产品经理的平庸与卓越其实并不能左右一个公司的成败？即便把我换成更好的产品经理，公司也不会发生质变？我们自以为是的“产品力”，究竟能在整体业务中起到多大的作用？

一方面，当看到不拘小节甚至丑陋的产品大获成功时，我的内心其实会摇摆，怀疑我在日常工作中对那些产品细节不讲情面的苛刻是不是根本没有必要。另一方面，当我看到许多产品混乱的流程、矛盾的逻辑和糟糕的体验时，又会由衷地感慨：一个基本功扎实、思路正常的产品经理是多么重要。

这种疑问和矛盾伴随我多年，让我时而充满斗志，时而忐忑不安。而创业之后，我终于开始有越来越多的机会跳出产品的岗位和立场去观察和思考，从外部去审视产品经理的价值和业务对产品团队的期望。

这个过程坚定了我对产品经理职责的认识。我们过去会认为，产品经理规划产品功能、完成需求分析，就算是完成了“产品”部分的工作，剩下的则是其他人的职责，大家各安其位，边界清晰。

但实际上，并没有任何一件推动公司前进的事务能够泾渭分明地划分职能责任。一个产品的功能，可能来自于运营活动的沉淀，一处工程架构的设计，甚至是产品的发展方向。产品经理的工作方式不能是“我的部分做完了，其他的事情我不管”，当然，任何角色都不应该这样。

业务的发展不应该像搭积木，开发、产品和运营把自己的工作成果垒到一起，而应该像调酒，不同的角色把不同的原材料注入杯中摇动，互相交融甚至产生化学反应。

一口酒好喝，是因为所有的原料恰好达成了某种意义上的平衡，刺激味蕾，我们很难像科学一样，划分每种味道之间的边界，很难像指着搭好的积木一样说：这一部分是产品经理搭的，“一般”；那一部分是运营搭的，“很好”。

这样来打比方，产品经理的职责就是将对产品的思考和“产品力”注入到杯中，与其他环节充分融合、互相反应，进而完成业务规划和发展。比如，我们会希望在运营中有产品思维，在产品中也能体现运营套路，而不是产品生下来便丢给运营去养；希望在架构设计中体现产品规划，在产品设计时充分发挥技术的价值，而不是产品经理写好文档，就丢给开发去实现。

这也是我在这一次专栏中想要分享的内容，我希望能从整个产品业务的起承转合出发，去挖掘产品经理和“产品力”能够在其中起到的作用。我会试着从产品创意、调研和立项，到增长和发展，每个不同的阶段去分享产品经理的思考和职能。

我会先从产品增长谈起，在专栏中，我会根据产品的生命周期组织内容，比如第一部分“产品的诞生”，我会跟你分享怎样在早期验证产品的可行性，如何收集信息，怎样推演产品逻辑和机会等等。接下来，关于产品的增长，我会分享包括推动萌芽期的产品发展壮大，以及找用户和积蓄流量的一些经验和方法。

然后，我会试着跳出单纯的产品设计，从业务出发，说说如何升级你的产品能力，这一部分我探讨产品经理的商业意识，怎样从打造好用的产品到打造赚钱的产品，包括商业产品中的一些基本概念，商业产品怎么算账，以及我自己在做商业产品过程中总结的一些原则和经验等等。另外，根据上一季专栏读者的反馈，我还会继续分享和完善产品经理的能力树，比如数据意识和能力等关键技能。

除此之外，我还会根据自己过去一段时间的工作经历，分享一些做微信小程序的体会和经验，包括小程序形态特点和流量组成，核心的设计原则以及增长策略，等等。

当然，除了上面这些内容，写作的过程中我可能还会有新的念头蹦出来，也欢迎你随时告诉我想同我探讨的问题，或许它们也可以形成新的主题和内容。

在写作上一季专栏“邱岳的产品手记”过程中，我收获良多，不但通过系统性写作与阶段性总结梳理了自己的产品脉络，也认识了很多朋友。他们是专栏的读者，同时也是专栏内容的贡献者，我经常在文章下读到非常精彩的评论，并得到很多启发。希望这一次我们还可以在留言里讨论和切磋，我也期待能看到更多你的故事以及思考。

我在上一季中曾提到过，专栏内容不是标准作业流程，也不是一定正确的金科玉律，它最好是线索和启发，帮助你找到适合自己的方法和模型。作为专栏的作者，我最盼望的不是你们在专栏中打破或重建知识体系，而是每个人在这里找到能完善自己的素材，点燃自己的火花。

“法无定法，然后知非法法也”，希望这个专栏能够给你启发，帮你成长。让我们一起加油，超越那个曾经的自己，做出不辜负用户也不辜负自己的产品。

戳此跳转第二季

尾声：你的快乐是哪一种

最后这一期，我不打算讲产品设计的技法和经验，而是想跟你分享几个故事。

2000 年， 43 届格莱美“最佳器乐独奏专辑”授予了一位时年 33 岁的天才小提琴家。同一年，这位小提琴家参与的电影《红色小提琴》获得了奥斯卡最佳原声配乐奖，颁奖典礼上，他获得的颁奖词是：“如同上帝般演奏”。

他叫 Joshua Bell，出生于美国印第安纳州，5 岁开始学琴，展现出过人的音乐天赋，14 岁开始与世界级指挥大师和管弦乐队合作演出，40 岁获得代表美国古典音乐界最高荣誉的费雪奖（Avery Fisher）。

人们津津乐道于他手中那把价值数百万的小提琴，它由意大利大师斯特拉迪瓦里（Antonio Stradivari）于 1713 年制成。2001 年时，Joshua Bell 卖掉了自己的琴，又额外凑了百万美元才将其买下。

Joshua Bell 凭借精深的艺术造诣，高超的琴技，毫无争议地成为当今世界上最优秀的小提琴家之一，他的独奏音乐会永远爆满，一票难求。

小提琴被称作“上帝的口哨声”，它自由、细腻的情感表现力，以及接近人声的音色，使得一个并不需要太多古典音乐背景的普通人，也可以领略它带来的冲击。我在工作时经常用小提琴独奏作为背景，它们陪伴我完成了无数的深夜 PRD。

同样是艺术家，文森特·梵高并不像 Joshua Bell 那么幸运，他穷困潦倒，寄人篱下，与好友决裂，离开相依为命的弟弟，割掉了自己的耳朵，被关进精神病院。

虽然命运如此凄惨，但他却从未停止创作，一辈子完成了几千幅画，只不过生前仅卖出了其中一幅。

梵高的天才在他死后才被发掘出来，人们逐渐意识到这个疯癫画家笔端涂抹出的色彩和线条有多么伟大，他的作品价格也像坐上火箭一般，一路飙涨至千万美金的天价。

谈论梵高时，人们都会为他的际遇扼腕叹息，感慨他生不逢时，怀才不遇，可怜他空有一支丹青妙笔却郁郁而终，对他际遇的同情成了人们怀念他时的基调，他那些伟大而深刻的作品，似乎也因此带上了无尽的悲剧色彩。

围绕梵高有很多谜团，其中最著名的莫过于他的耳朵，有人说他因为与高更的争吵而割掉了耳朵，有人说他为了妓女割下耳朵，BBC 甚至有一部专门的记录片去探寻这个天才匪夷所思之举背后的来龙去脉。

最终的答案是：他因为可怜一位在妓院工作的清洁工，所以决定把身体的一部分作为礼物送给她。

一个本该被同情，本该陷入绝望不堪的画家，竟然依旧怀揣着悲悯。这并非不可思议，梵高的精力似乎并没有多少花在对抗自己的穷困或抱怨世界不公上，相反，他热爱这个世界，他用这个世界带给他的苦难来探求和表达欣喜与热烈。

吸引他的不是钱或名气，这在梵高给弟弟提奥的信中或许可以窥探一二，他说：“如果生活中不再有某种无限的、深刻的、真实的东西，我将不再眷恋人间。”

梵高从没有许下用画作赚大钱的心愿，相反，他只希望自己的作品能够触及人们的心灵，梵高曾提到自己最想得到的评价是：“他的感受如此深刻而又细腻”。（I want to touch people with my art. I want them to say: he feels deeply, he feels tenderly. ）

我们曾经在文章中聊起过互联网领域的暗黑模式，在那篇文章中我没有提到的是暗黑模式的驱动力。

其实催生各种让人啼笑皆非设计把戏的根源，就是无处不在的 KPI 文化，我们习惯了为 KPI 工作，为一堆指标工作，它们是衡量我们工作成效的标尺，就如同用画作的价格和知名度评价画家一样。

前些日子我看了淡豹在单向街书店文化节上的一个演讲，她在演讲中提到麦金泰尔和他的书《追寻美德》，书中将人的快乐分为内在和外在两种。

麦金泰尔用一个学习国际象棋的小孩子举例：如果这个孩子每赢一次棋，我们就奖励他糖果，那么糖果就是这个小孩子关于国际象棋的外在快乐。

这样的快乐是由于机缘巧合，偶然与国际象棋关联，却与国际象棋的本身并无必然联系，这是可以通过除国际象棋之外的其他实践获得的快乐；而另一方面，国际象棋本身给这个孩子带来的逻辑或战略相关的心理满足感，则是存在于国际象棋之中，无法被其他实践替代的内在快乐。

麦金泰尔说，如果驱动这个小孩子的仅仅只是外界作用于他的糖果奖励，那么将没有任何事情可以阻止这个小男孩用欺骗或贿赂的方式获胜。

对我们来说，如果驱动力仅仅只是外在奖励，比如晋升、加薪、奖金和地位，那么也就没有任何事情，可以阻止我们为更高的数据指标做出狡猾的设计。

我们会准确地在标题中放入耸人听闻的词语，命中情绪，引爆传播，我们会用 A/B 测试不厌其烦地比较不同样式设计带来的转化率差异，我们会在不起眼的角落默认选中“我已阅读并同意《用户协议》”。

那产品设计的内在奖励呢？对我来说，就是用产品真切地改变人们的生活。

我想象中的产品，她不需要占据用户每天八小时，而是恰如其分地出现，然后悄无声息地消失。她依靠精妙的产品机制，而不是哗众取宠的标题和费尽心机的设计样式触动用户。她慷慨而克制，不吝惜给予，又不会喋喋不休地索取。

就算这个产品只有一个用户，那就谦卑地解决让他焦头烂额的问题，为他带来启发，为他创造价值。

即便永远无法做出这样的东西，我依然想要去追求，它是我走进这个行业的初衷。

梵高曾经在信中平静地发问：“为什么我们永远无法触碰天上的星光？”(Why, I say to myself, should the spots of light in the firmament be inaccessible to us.)

他在罗纳河上的夜空中追求，在乡下金黄色的麦田中追求，最终他成为了人类历史上最伟大、最不可思议，永远怀有赤子之心的画家。

我知道当我说完这一切，走出这篇文章后，还是会为了生计而奔波，为了下个月的车贷和房贷而发愁，为了公司的营收和利润殚精竭虑。

我还是会数据分析、增长黑客、A/B 测试、敏捷开发。这就是生活，理想和初心太重了，我们没办法总是把它们挂在胸口。

但我依然想在结束前问一个问题：如果没有百万用户，没有喝彩和关注，没有奖金期权，没有 App Store 星级，也没有双手抱胸的商务形象照，你的工作还会让你感到骄傲和快乐吗？一个产品经理的成就，只有那一种评价标准吗？

2007 年 1 月 12 日早上 7 点 51 分，一个身穿黑色 T 恤，头戴黑色棒球帽的男人，像其他街头艺人一样，独自来到华盛顿特区市中心的“朗方广场”(L'Enfant Plaza) 地铁站。

他打开琴盒，取出一把不太起眼，有点老旧的红色亮漆小提琴，演奏了包括巴赫《恰空舞曲》和舒伯特《圣母颂》在内的 6 段曲目，演奏持续了 45 分钟，期间有 1097 个人从他身边经过，只有 7 人驻足观赏，20 人向他的琴盒里投下零钱，共计 32 美金。

只有一个路人在演奏接近尾声时认出了他，他是 Joshua Bell，当今世界上最优秀的小提琴家之一。