《Getting Real》如何做产品你的产品需要有一个明确得通常是一句话就可以阐述的观点和目标。这将决定你产品的初衷和

概述

所谓的“Getting Real”是指要避免许下问题：

过长的计划安排
空谈的功能定义
过度设计，如系统拓展、收缩
为了开会而开会
大量的人员投入
无意义的版本迭代
愿景理想，路径规划愚蠢
毫无节制的偏好配置
漫长、复杂的反馈支持
不合实际的测试及修改
无意义的文档
自上而下的管理制度

构建一个什么样的产品

明确产品定位

Before you start designing or coding anything you need to know the purpose of your product — the vision

你的产品需要有一个明确得通常是一句话就可以阐述的观点和目标。这将决定你产品的初衷和方向。当用户选择一个软件或服务时，他不只是在选择一个功能，他也在选择一个解决问题的方式，一个设计上的思考和视野。

命中正确的用户

你的产品完全不需要也不应该去讨好所有人，记住每个产品都有其适当的人群，甚至相同产品下的不同竞品都会适配到不同的用户群体。所以不要去讨好所有人，讨好所有人的结果就是没人会买账。如果一个用户在你的产品理念上就不认同，那么不要尝试去拉拢他，你永远无法让他认同和开心。

以少胜多，比你的对手更精简、专注

Do less than your competitors to beat them

普遍的观念认为，要比你的竞争对手做的更多，如果他们有四个功能，你就提供五个，如果他们投入一，你就投入二、三。这是一种愚蠢的跟随策略，这种策略并没有自己的思考，只是茫昧的跟随对手。相对的应该专注，减少投入，少一些功能设计、少一些用户可选项/配置，少些会议，少些管理层级，以及少一些承诺和愿景。

解决自己的问题/烦恼

如果你有一个痛点，那么其他人也会有这样的痛点，这些人就是你的用户。如果你着力于解决的问题是困扰你自己的问题，那么你能更好的抓住痛点，提供解决方案，同时你也能真正的投入热情，通常热情要比解决问题更加重要。

可以先做半个产品，但绝对不要做一个半吊子产品

如果你在时间或精力上没办法满足现状，你可以先完成一部分核心功能，不要把时间投入到非核心的功能上，后续的时间和精力是无限的，但是眼前的时间和精力需要分配到刀刃上。

你可以制定一个最小的功能子集，从优先级、必要性、拓展性上去考虑抽离最重要的功能点。如果没有这个功能点，产品是否可以使用，如果可以使用，那这个功能就是非必要的。切记不要制定太大的功能集，然是问题百出，宁可只有核心的功能，但确保整个功能是可用的，先做出半个产品来，而不是一个问题百出的产品集合。

方向和自驱

找一个竞对

Sometimes the best way to know what your app should be is to know what it shouldn’t be 找一个竟对，站在他的肩膀上，吸取他们的经验，你能更好的明确什么是需要的，什么是不需要的。

竟对带来的好处

如果存在竟对，说明你的产品是确实存在用户和市场的。对用户而言存在两个相似的产品他就会去对比选择，通过这种对比用户可以更好、更主动的了解你的产品。这时制造些对立信息，宣传些用户重视或感兴趣的信息，可以吸引足够的注意力。

如何从竟对手里分羹：不要跟随，避开对方优势

在市场竞争里，紧跟领头羊是绝对不会有什么差错的。但是如果你的竟对在某一方面树立了足够的宣传效果，切记避开这些信息点去宣传，通常人对挑战其已有认知是排斥的，你的竟对提供一万的计算能力，你要去说服用户相信你的产品可以提供两万的计算能力是不讨好的，你应该从另一方面吸引用户，你的产品可以更高效，更简洁，更便宜，切记制造一个不同的宣传点效果要更好。

关注整体方向和核心问题，而不是你的竟对在做什么

找到竟对并把他们的功能罗列出来进行对比，很容易将你带入歧途，不要过渡关注他们在做什么，关注你所做的产品的大方向和核心功能点，着重解决这些问题，而不是去集合竟对的功能。

对你的产品饱有激情

如果你要做的产品不能让你感到兴奋，你只是让他上线、投入生产，那一定不会有好的结果。兴趣与激情是会传递和感染的，如果你投入激情到你的产品，用户是能够感受到的，反之已然，请相信这点。

如何保持精简

精简

你可以抛弃就的想法，投入新的想法，也可以在开发迭代种调整改变，这些都是实际发生着得，为了应对变更，你需要做到精简。精简意味着：

及时思考、改变
多面手的团队成员
直面限制条件，不要逃避
更少的功能及代码
更小的团队
简单高效的运作
公开数据和产品
敢于承担错误

尽量避免：

介入长期的合作
多余的人员安排
固执不变的决策
为了开会而开会
繁琐的流程
积压的工作
封锁的技术
专有的数据格式
历史包裹
过长的路径规划
办公室政治

简单的规则，顺其自然

像鸟儿迁徙，简单的规则可以演化出复杂的行为。不要把事物约定的太死，否则留给变化和创新的空间就很少了。如果你需要变化的成本太高，那就变得岌岌可危了。

控制最初迭代

保证最初版本的迭代简洁轻量，如果你需要投入过多人力或精力完成初版，那么说明初版中有功能是不重要的，需要移除的。轻量的初始版本能让你更清晰的看到产品是否可以生存，同时迭代和变更的成本更低。

前期不要过渡关注细节

我们常说细节决定成败，但在考虑细节之前还有很长的路要走，没有谁一出生就走到了开始靠细节决定成败的地步。同样关注细节所付出的代价也需要商榷，你可能会停滞、争论，然后开会商讨然后延期。这会严重阻塞你的进程，甚至导致你胎死腹中。关于细节处理的最好例子就是绘画，绘画首先要处理的就是构图和轮廓，没有人在会再精细的绘制完头发或手后再去考虑其他部分的轮廓线该怎么走。

不要过早考虑拓展和优化

一般开发人员喜欢在设计阶段就做好拓展和优化方面的设计，如果两年后你才有一百万用户，那么现阶段你根本不需要担心如何处理 1000 个并发请求。人们经常会花费大量的时间来处理现在甚至很长一段时间都不会遇到的问题。一个好的例子，在 Basecamp （付费订阅服务）刚推出时，甚至没有开发付费订阅相关的功能，因为付费订阅是用户试用期一个月后才会面对的事情，而尽早的上线产品，再这段时间内再补足付费订阅功能是一个合适的策略。

关注哪些功能

关注最核心的功能

如果某个功能是有价值的，但不是必不可缺的，那么他就是可以砍掉的。最好的设计或开发不是那些功底扎实或擅长解决问题的人，而是能够做出取舍和决断的人。

拒绝无休止的功能支持

如果每一个提过来的需求你都欣然接收，那么你就像在娇生惯养一个孩子，你不得不照顾好他的每一件事。你要学会探知对方，当一个需求提过来，拒绝并告诉他，现在不会马上支持，如果同样的需求不断的提过来，那你是时候考虑该如何实现它了。同样的道理适用到需求管理上，你如何去管理你要迭代的需求，用看板，代办事项还是其他工具，都不是，你不需要刻意的去记忆，一个真正核心重要的需求会不断的提到你面前，你根本不需要去关注他，在不自然中你就已经牢牢记住它了。你不刻意去记忆但是仍旧在你脑海中的需求，这些就是最需要去落实的需求。

You can’t forget what’s important when you are reminded of it every day

尝试去除一些功能

你可以尝试着去问你的用户，哪些功能是他们不需要的，如果一个功能没有用，那为什么不去掉他。有的时候用户需要的不是新的功能，去掉一些无用的功能也能让他们感到满意。

关于配置项

尽量避免提供用户过多的配置项，细节方面可以替用户做出决定，诸如分页显示多少条数据，你大可规定为每页20条，而不是花费大量的精力支持用户可配置。这是一个投入产出比非常底的功能项。留给用户过多的配置项并不友善，愿想中所有的东西都是灵活可配的，尽量满足用户的定制化需求，实际上你也把很多繁重无意义的工作交托给了用户。当用户打开设置项菜单看到的是无边无际的可配项时，他感到的是头疼而不是惊喜，他不得不逼迫自己甄别出哪些配置项是真正有意义的。用户不需要去考虑每一个细节如何展示，你完全可以替他决定，如果他有定制化需求自然会找到你，视情况再添加也不迟。

关于落地实现

所见即所需

通常功能文档或Sketch设计稿很清晰表达或达成一致，如果你真正去落地实现他，事情就会拨云见物，人们会很快的对焦并达成意见。通常人们会花费大量的时间去讨论一个功能，甚至有人会热衷于此，从中获取乐趣，避免反复的沟通讨论，直接落地实现有时候其实更加高效。

调整和修改是在所难免的

不要幻想着能够一步到位，几乎没有人能够在设计阶段就和最终产品完全一致，开发中修改，迭代中变化再正常不过。产品是在反复验证修改的过程中定型的，设计一些界面或功能，使用它，然后分析它，如此反复，这样才能打磨出一个好的产品。

开发一个产品需要经历得阶段

脑暴就如同绘画一样，这个阶段是一个高层次的工作，决定的是产品要解决什么问题，要做什么，怎么判断它是有价值的。

原型这是一个实验性的阶段，把你的想法转化为粗略的界面画在纸上或者电子软件上。

骨架把原型用静态的html实现出来，当然也可以用原型软件生成，这是一个纯静态的页面，不设计任何逻辑代码。

编码当骨架模型在功能上已经完备了，就可以开始着手真正的开发工作了。

心里要有预期，上述过程可能因为一些问题会反复重新来过，这也是不可避免的。

关于执行和效率

执行力的重要性

如果我们把创意和执行分开计算。

糟糕的创意：0
普通的创意：2
好的创意： 5
伟大的创意：10
---------------
没有执行：0
不理想的执行：$10
普通的执行：$50
完美的执行：$100
---------------
产出 = 创意 * 执行

再伟大的创意，没有执行，或者没有好的执行也拿不到好的结果，决定成败的不是创意，而是你如何去执行它

划分任务，缩短迭代周期

The truth is you just don’t know what’s going to happen that far in advance. 不要做过长的计划安排，你无法预知未来会发生什么。将功能拆分，将迭代周期缩短，更少的功能、更短的时间更有助于项目管理。** 如果你给一个开发三周的时间去完成一个迭代或功能，他会花两周半的时间准备和调研，然后用剩下半周的时间去实现，但如果你只给他一下午的时间去做一件小事，他会马上去完成，这是很普遍的现象。** 所以尽量拆分功能缩短时间，一方面可以提高效率，另一方面不断的迭代上线也能激发成就感。

直接沟通，聚合团队

不要把工作划分的太细，专门的设计、专门的交互、专门的开发，专职有其利端也有其弊端，每个人细碎的工作只能关注到细碎的问题，无法关注到整个产品全局是什么样的。同样细碎的分工也会增加沟通成本，我们通常喜欢通过产品代理沟通，尽量减少中间人传话，直接沟通能避免很多不必要的周折和误解。

预留一段时间用于专注于工作

很多人喜欢在早晨或者晚上完成大部分工作，因为这些时间没有人会去打扰他。 ** 可能你帮别人排查或解决一个问题只会占用你五分钟的时间，但你可能需要花费半个小时或更多的时间来重新回到专注高效的状态。** 制定一些规则或承诺，保证一天中有足够的时间是独立安静的，在这段时间内不被任何人或问题打扰，静音手机，关闭邮件、IM软件、拒绝会议，这能极大程度的提高效率。

愚蠢的会议

会议带来的弊端：

会议会将你一天的时间切分，不连续的时间会影响你的工作计划和进度。
会议大多数都是在讨论些不落地的概念和想法，这些都不是核心的，行之有效的东西。
会议的信息传递效率特别低，往往一个人花上几分钟的时间只是在说一个点，而所有人则要持续的听完每一个人的发言。
有些人的发言是点对点的，甚至有些人的发言是无意义的，这些完全可以私下沟通。
会议中很容易有人偏离主题并喋喋不休。
有的会议议程模糊，甚至有人根本不知道要讨论的内容是什么。
有些会议需要预先准备，但很少有人愿意如此。

如果会议是不可避免的，可以考虑：

严格控制会议时间，召开一个三十分钟的会议，时间一到就解散。
尽可能的控制与会人员，只有真正相关的人才被邀请。
如果一次会议没有议程，那么就不要召开。

综上，不要频繁的会议商讨，尽量在需要达成意见一致，或遇到重要的、阻塞的问题时才召开会议。同样即使如此也只邀请相关人员，不要浪费无关人员的时间。

关于界面设计

设计优先，震中设计

关注空白页和错误页的设计

通常页面涵盖了：常规、空白、错误三种状态显示，人们一般只花时间和精力完成常规显示的界面设计，而忽略了空白页和错误页。

这里避开错误页不谈，着重强调空白页的重要性。当你新注册一个应用，或第一次进入一个系统时，你看到的就是空白状态下的页面展示。这以状态的展示是不可能规避的，而且更不幸的时，它展现的频率很低，但影响很大，这往往影响到用户的第一印象，如果你空白页展现出粗制滥造的样貌，用户很容易认为这是一个粗制滥造的产品。

你可以用以下信息填充空白页

可以用新手引导或者快速起航教程填充页面。
可以用样板数据填充页面，这样用户能知道常规情况下这个页面会是什么样子。
可以用 FAQ 填充页面，把常见的问题和引导以 FAQ 的方式罗列。
可以用产品介绍、功能介绍等信息填充，帮助用户理解这是一个什么项目，具备什么功能和优势。

第一印象相当重要，所以空白页的设计和展示需要投入必要的时间和精力。

适当情况打破设计原则

我们知道设计有四大原则，以一致性为例说明。假设页面的主体内容相对复杂，但通用导航中有部分内容无用且占据了核心内容的显示空间，那么完全可以去除这部分内容，虽然这会导致设计上的不一致。但要注意用户需要什么和不需要什么才是更重要的。所以决定该放什么，该怎么做有时会比设计原则的优先级更高。

编程和开发

更少的功能，更少的代码

There is no code that is more flexible than no code. 好的代码不在于多么专业的设计，而在于如何使用更少的代码完成相同的功能，如何去除无意义的代码。如果开发被雇来删除代码的话。比起去愈见将来的问题，预留设计模式和拓展，不如着手解决现有的问题。因为传统软件的维护和发行限制，在开发前往往谨慎的考虑，但就互联网产品的迭代和变化频率来看，有时就问题解问题反而成本更底。

使用热衷的工具

激发开发人员最简单有效的方式就是，让他们使他们想用的或感兴趣的工具或技术。一个愿意使用的语言或工具往往能极大的鼓舞士气，提升效率。

使用真实数据测试

往往在调试测试阶段会引入一些工具生成无意义字符，这些字符只能起到填充页面的作用，对于视觉的临界条件和功能测试没有任何帮助，所以尽量使用真实的数据进行测试，哪怕是模拟写死的数据也尽量使用真正有意义的，产品会真实显示的数据。

不是所有的 bug 都是平等重要的

你完全不必马上去修复现在暴露出的所有 bug，大多数 bug 只是一些小问题而不是致命的。当然对于影响到系统的运行，或者会造成经济损失的 bug 是要第一时间修复的，同样对于用户反馈过来的 bug 也要第一时间处理，并恢复对方已经收到反馈并在加急处理。

找到设计的平衡点

如果你是一个只表匠，你的表要卖给一个不会游泳的旱鸭子，那你完全不需要关心你的表能否在水下一千米正常运行。同样程序设计也是如此，你完全没必要考虑过于长远或健全的设计方案，足够即可。当然你也要为未来的变化留有足够的空间。

功能定义文档

功能定义文档脱离实际，往往跟不上变化

An app is not real until builders are building it, designers are designing it, and people are using it. Functional specs are just words on paper.

功能文档只是一些文字的描述，或者是一个大的蓝图，在产品落地实现之前，一切都有可能改变，它并不是完全符合实际的。脱离实际的文档是没有意义的，

功能定义文档只能达成表面上的一致

对于同一段文字，不同人的解读是不同的，所以有些时候虽然集体对同一份描述文档达成了统一认识，但实际上各自的理解是有差异的，功能文档只会变成一份协议，当存在理解差异时，对方可以说：你当时是同意了的，我们有文档规范，你还在上面签了字按了手印。它除了堵住你的嘴外，对项目推进上没有什么实质的帮助。

简化文档，用原型页面替代描述文本

相对于功能定义文档，写一个简化的文档，用一页纸去说明你的产品要达成什么目标，要做什么事，语言要简单朴实。然后就可以开始搭建原型界面了，原型界面相比功能文档更加直观清晰，人们可能对描述文字有不同的理解，但对一个可交互的页面往往不会产生分歧。

没人喜欢花费时间去细数每一条功能定义

开发通常不会花多少时间认真去读功能文档，他们通常只关注问题、然后探讨方案，实现，测试。一个功能在测试阶段疏忽某些功能定义是很常见的事情，这充分说明开发不会关注每一项看起来不重要的功能定义。所以尽量简化你的功能文档，让它清晰，一眼命中，那些冗余成册的甚至可以装订出版的文档，没人会去读它，你的工作只是在说服你自己你足够努力了。况且产品在变化和迭代过程中，和最初的构想相差甚远，那么文档究竟那让人得到什么呢？

写故事别写细节，小说而不是说明文

读书的时候就能知道，没人喜欢读说明文，所以当你要表达一个需求或功能的时候，不要描述细节和规范，举一个实际的场景和例子，编一个故事，阐述一个故事足以让对方知道你需要的是什么。

反馈和支持

预先周知坏消息，降低接受成本

诸如系统维护、订阅涨价这种不好的消息，尽量早些公告出来，并用最明显的方式展现给用户，长时间的提示有助于消耗一部分负面情绪，能尽可能的降低用户的痛苦就是最成功的。

直接听取意见，直接反馈

我经历过最好的反馈就是自己在客服群里直接和用户对话，尽可能让用户直接和设计、开发对话，不要经过太多的中间人，传递消息，一方面信息会失真，一方面时间也会失效。尽量直接读用户的反馈邮件，听取他们的意见，从中改变和成长。如果你迫切的想要一份炸脆的猪排，你可以直接跟服务员说，当然最好的方式是直接告诉厨师，但你绝对不会跟一个伊斯兰教徒说。

简短的使用说明

在交互设计中，通常会尽量避免较长的引导教学，过长的引导会让用户烦躁，同时也难以记忆，就会造成二次复习，恶性循环。所以保证你的产品足够简单，如果不需要引导视频或教程则是最好的。你可以使用行内提示或者 FAQ 的方式替代新手引导，通常游戏的新手引导是最复杂的，我见过最好的处理方式就是把引导融入到游玩的进程中，在实际流程中渐渐渗透。当然你也可以根据用户反馈，着重调整，对于经常被提问或质疑的功能，可以通过行内提示或帮助信息提示给用户该，预先说明。

快速响应

反馈和咨询问题要最高优先回应，很多政府企业让人恼火的原因就是处理流畅长，响应极慢，作为一个满足用户需求的产品，即使不能第一时间解决问题，也要告知用户你收到问题并在努力处理了，这样用户会感受到你的态度和重视，记得没有谁会喜欢石沉大海的感受。

学会拒绝

这一点之前有讨论过，对于用户反馈同样如此，不是每一个人的每一个建议都是绝对正确的，学会甄别和拒绝，因为你也不想你的产品成为一个满足各种奇怪要求的怪胎。适当的态度和坚持是有必要的。这一点乔布斯在 iTuns 发布会上应证的非常好。

充分利用使用论坛、客服群

人们向来是喜欢帮助他人的，建立一个论坛或客服群，总会有人愿意积极替你帮助后来者解决些他遇到过的一些问题。更短更直接的沟通形式也是拉近户间关系的好方法。

积极承认问题，坦诚相对

如果你的系统出现什么问题，第一时间公开出来，哪怕没有影响到用户，不要存在侥幸心理尝试隐瞒，这只会让事情变的更糟，坦诚相待，你要相信大多数人是友善宽容的，除非涉及到用户利益的问题，否则大多数人都是宽容的。要记住真诚都是相对的。甚至听起来有些费解，如果你们第一时间把坏消息或者坏的影响公开出来，反而会获得主动权，不至于让自己处于被动防守的尴尬处境。