《Getting Real》这本书有点意思，是37 signals团队的作品，作者以简洁有力的风格，阐释了如何打造一个简单但却真正解决用户需求的产品。
1、不妨假装在资源很少，人力不够的情况下，去考虑需求，做出来的产品，没有多余的，浪费的东西。
要做到这点其实真的很难，经常思考你的产品上有没有多余的东西，在能解决用户问题的前提下，如果有，为啥不去掉，减少代码量，降低耦合度。这点就跟日本的设计一样，他们因为资源缺乏，所以设计出来的作品从来就没有多余和浪费的东西，让人看着很自然。
2、创造，不是对每个需求说Yes,而是对每个需求说No，除了那些真正至关重要的需求。
创造是提炼精油，不是做膨化食品。
3、产品的大框架，根，要固定，对部分局部细节，可以保持弹性，不要定死方案，一来可能造成隐形负担，二来限制了用户探索产品的乐趣和空间。
4、用户告诉你应该做A功能，然后你可以反问他：“你提到的这个，我们考虑过，那你有没有想过，我们为什么不做？”
5、真实的产品导致真实的行动。这才是你走向真理之路。问题是在使用产品的过程中发现和验证的，所以最重要的事是尽快出一个真实的产品出来。那些虚拟的模型，简单的文字描述，都是虚的。
6、办实事，能促进达成共识。用事实说话，实践是检验真理的唯一标准。当一群不一样的人开始尝试寻找和谐共鸣的时候...如果他们是一建立一个全方位的真实的产品那么他们的意见总会趋于一致。当然，如果他们只是打打草稿或是生出一些点子的话是很难达成共识的。因此，当你真正开始做一个实在的产品时，共识就比较容易达成。
实践是检验真理的唯一标准，不要把时间浪费在争论概念上。
7、如果你知道过后总是要重来一遍，你就不需追求一开始就达完美。这种明了不管如何你总是得过后重新审视一些问题的理念，能引发你先把产品想法推出去看看是否可行的激情。
认清现实吧，这也是很多产品在某个阶段，都要重构的根由。做产品的过程也要为过去的赶着上线等“偷懒”偿还“债务”。
8、设置选项也是邪恶的因为他们使软件变得冗余。更多的选项就需要更多的编程代码。而且你还要花额外的时间在测试和设计上。还有很多选项排序和显示界面等你可能从来没见过的东西。这意味着隐藏的软件瑕疵：破碎的布局，凌乱的表格，奇奇怪怪的页面排序问题等等。在一些小处细节上，你需要帮客户拿主意，是的，你有可能下了一个不太好的决断。没什么大不了。如果事情发生了，人们会抱怨，会让你知道。照样，你可以做调整。
设置选项就是隐藏在界面争夺战中败下阵来的功能和元素，然后好久才能被主人看到一次。只是当设置中的内容越来越多时，设置也就丧失了原本的意义。
9、事实证明，加设置首选项是有代价的。当然，有些首选项也有重要的作用 — 并且可能是关键的页面职能。但每提供一个选项都有不菲的代价，你应当仔细考量其价值。很多的用户和开发者都没能理解这个道理，最终付出很大成本，宝贵的资 本只带来一点点的价值...我发现，如果你是信奉要靠设计优秀默认功能而不是懒惰地去添加设置首选项的人，那么自然而然地你的总体UI（用户界面）会走上 正确的道路。
10、当我听说有人对自己的点子很具保护性时觉得很可笑。（那些在告诉我一些简单的概念之前希望我签定保密协定的人。）对我而言，如果不去执行的话点子是一无用处的。它们只是倍数。执行才是价值万金的。
理由:
糟糕的点子 = -1
脆弱的点子 = 1
普通的点子 = 5
好点子 = 10
伟大的点子 = 15
超闪亮的点子 = 20
没有执行 = $1
柔弱的执行 = $1000
普通的执行 = $10,000
好的执行 = $100,000
伟大的执行 = $1,000,000
超强的执行 = $10,000,000
如果要成就一番事业，你必须将二者相乘。
最闪亮的点子，如果没有执行，最多值$20。如果它乘以优秀的执行，那么就值$20,000,000。
那就是为什么我不爱听他人的点子。只有当看到它被确实执行下去了我才有兴趣。
11、为了让事情做好，人们需要不被打扰的时间，特别是对开发们来说。
从自己工作经历来说，不要频繁找开发，否则他们没法干活，而且这也是自己不专业的表现，把问题整理好，能自己解决的就自己解决，争取一次解决问题。开发又不是你的女朋友。
12、不要会议：开会前想清楚你真的需要会议吗？会议经常出现在概念不够清楚的时候。不要求助于会议，试着简化概念，于是你可以快速的讨论它，通过电子邮件，即时通讯或者Campfire。目标就是避免会议。**你避免花费在会议上的每一分钟是你真正做事情的每一分钟。有太多的会议了。放弃那些没有意义的和没有效果的会议。只有当需要讨论重要的商务议题的时候或者你需要建议，赞同或者一致意见的时候才召开会议。
要想清楚会议是为了什么而开，少拉一些人进来，有人来开会纯粹是因为坐电脑前有点无聊了想换个环境透透气。
13、在你确实地必须 开会（这必须是一个少见的事情）的时候 , 坚持这些简单的原则：设定一个30分钟的计时器。当它响的时候，会议结束。句号。
邀请尽可能少的人。
没有明确议程的时候不要开会。
14、增加人员带来了减少的回报。最有趣的原因之一就是增加的交流通道的数量。两个人只需要相互沟通；只有一条简单的交流途径。三个人有三条交流途径；4个人有6条。事实上，交流途径的增长是指数级的……很快，备忘录和会议汇占据整个工作时间。解决方法是明显的：把团队分解成小的，自治的和独立的小单位以减少这些交流途径，减少个体之间的依赖，鼓励一专多能。
15、寻找和庆祝小的胜利：每天发行点什么软件开发中最重要的就是激励。激励是局部的 -- 如果你没有被你正在做的事所激励， 机会就没有应有的那么好。 实际上，很有可能变得更糟糕。
冗长，滞后的发布周期是激励的杀手。 这使得庆祝活动之间间隔太长的时间。 另一方面， 可以庆祝的迅速胜利是极大的激励动因。 如果你让冗长的发布周期压碎迅速的胜利，就杀死了激励。 并且这样也会杀死你的产品。
所以， 如果你的发布周期是在一个月以内， 拿出每周一天（或者没2周拿出一天）对取得的小胜利进行庆祝。 并扪心自问： “我们可以在4个小时内发布些什么？” ， 然后去实现它。 这可以是
一个新的简单特性
一个对现有特性的小改进
为了减低支持负担，重写一下帮助信息
去除那些并不需要的表格项
当你发现这些 4小时的迅速胜利时， 你将发现庆祝的理由。 这样鼓舞了士气， 增强了激励 并且 再次肯定了团队正在向着正确的方向前进。
用战果，鼓舞你的将士们。——尼古拉斯.纳博纳.小鸟将军。
16、给延期的软件开发项目添加人手只会更加拖延进度。
17、如果你在琢磨从几个人选中挑出哪一个来填补空缺，选文字功底好的那位。无论他是设计师、程序员、市场人员、销售人员还是其他，写作技巧都很有用。简洁高效的写作和文字编辑能力可以带来简洁高效的代码、设计、邮件、即时信息以及更多。
18、先设计最重要的：页面赖以生存的是其核心。举例来说，如果你正在设计显示博客文章的页面，那么核心就是博客文章本身。不是在边栏里的文章分类，不是顶部的页头，不是底部的评论提交表单，而是实际的博客文章单元。没有博客文章单元，这就不是一个博客文章页。只有当这个单元完成之后你才能开始考虑页面中次重要的元素。次重要的元素完成之后，你再转战第三重要的元素，以此类推。这就是震中设计。
震中设计规避了传统中 “先搭建框架，再填充内容”的方式。在那种方式里，人们先建立好页面布局，然后把导航条包含进去，然后插入有关销售推广方面的东西，到最后才把核心功能——页面的实际意义所在用来填充剩下的空间。这是本末倒置的做法。
震中设计让你从一开始就关注于真正重要的部分。先做必需要的，再做其他的。结果是给用户一个更友好、重点清晰的界面。并且，这样可以让你马上和设计、开发人员展开对话而不是等到页面所有部分都各就各位之后。
19、对于每一个界面，你需要考虑可能出现的三种情况：常规一切运行正常的话，人们看到的是一个充满内容的界面。
场景胜过一致性：说到底，一致性只是一种未经验证的执念。动作是使用 按钮 还是用 链接 来实现 ？ 这取决于那个动作。 一个日历视图是应该使用列表方式还是表格方式实现？ 这取决于 它要用在哪里 并且 要显示多长的时间。 全局的导航链接是否需要出现在每个页面上 ？ 是否每个地方都需要一个全局的搜索条 ？ 是否在每一页上需要一个完全相同的页脚？ 答案是“这取决于应用环境” 。这就是应用环境比一致性重要的原因。 如果你的设计在那种状况下有意义， 不一致也没有什么大不了的。 只给人们重要的。 给他们所需要的，并且去掉其不需要的。 比保持一致性更好的是保持正确。
一致性不是必不可少的。 很多年来， 学习用户界面和用户交互的学生都这样被教导，界面中的一致性是界面设计中的核心守则之一。也许这在软件中成立，但是在Web上，这不对。 Web上真正重要的是，在每个独立页面，用户是否能够快速、简单地前进到流程中的下一个步骤。在 “好的创新” （Creative Good）, 我们把这叫做“聪明的不一致” ： 确保流程的每个页面都给用户提供他在流程中的那个位置所真正需要的东西。 只因为了和网站的其它部分保持一致，加入多余的导航因素，是很愚蠢的。
初始人们第一次使用这个应用，在加入内容前的界面。
忽略初始界面的阶段是你会犯的最大错误之一。初始界面是应用留给人们的第一印象，永远不会有第二次这样的机会……这个么，你应该知道。然而，产品在初始状态下是没有内容的。当新人注册，他们将从初始界面开始。就像是一个博客，用户需要自己去充实它。而在用户输入文章内容、链接、评论、日期、边栏的信息或其它数据前，整体外观无法成形。不幸的是，用户会在初始界面时决定产品是否值得一用——在这个内容和信息最少的阶段来判断产品的适用性。如果你设计的初始界面有缺陷，人们就不知道缺少些什么，因为他们感觉什么都没有。错误有错误发生时，人们看到的界面。这是一种保护性设计，必不可少。
20、能用一个按钮做两件事，就不要用两个按钮做两件事，一个是节省空间，另外一个还是为了不让用户跳来跳去。放大来看，不要让用户在这个界面做了一件事，然后又要跳到另一个界面去做另一件事，拒绝分离的界面。
21、更少的代码：产品设计上，要比竞争对手做的更少，而不是更多。做的更少达到同样的目标，才能体现你的实力。
你或许认为代码量加倍软件复杂性也相应加倍，但实际上，每增加一些代码，软件的复杂性就随之指数式增长。 代码的每一点增加，每一点改动，每一个相依性，每一个前指性（Preference) 都有着联动效应。轻率地增加代码，不用多久，你就会造出一个可怕的大稀泥巴。打造软件最重要也是最鲜为人知的规则：复杂性和大小不成线性比例…… 2000行的程序比1000行的程序要用多于两倍的开发时间。对付复杂性的办法就是更少的代码。更少的软件意味着更少的特征（features），更少的代码和更少的浪费。
关键在于将每一个困难的问题（要求很多的代码）重新描述成一个简单的问题（要求少得多的代码）。你解决的问题也许不是和原先百分之百一样的问题，那也没关系。用20%的努力解决原先问题的80%就是一个很大的胜利。原先的问题几乎从来就没有糟糕到值得花5倍的精力去解决。
更少的软件意味着撇开水晶球。处理今天面对的问题而不是预测未来的问题。为什么？对明天的恐惧常常是毫无结果的。不要让幻想的问题把你拖住。从一开始，我们就将产品的设计基于更少软件的概念。只要可能，我们就将问题简单化。我们发现，对简单问题的解决方案不仅更容易实施和支持，也更容易理解和使用。这都是我们用来区别于竞争对手的做法的组成部分。我们造的产品要做更少，而不是做更多。
鼓励程序员提出反建议你想听到："你建议的方法要花12小时，但我这样做只需1小时，它不做x，但它做y。"让软件推你回来。告诉程序员用他们认为最好的方法去战斗。还有，寻找可以避免编写更多软件的途径。用屏幕文字的方式建议用户绕道而行，从而避免对于软件模型的更改。比如，建议用户上载指定尺寸的图片，而不是在服务器端作图像处理。
没有任何代码比没有代码更灵活
好软件设计的"秘密"不在于知道在代码里放什么，而在于知道代码里不放什么！这在于辨认出硬点和软点在哪里，还知道哪里该留下空间而不是试图塞进更多的设计。PM最重要的能力就是简单，其次是在简单的基础上，实现自然的体验。好的PM不是能做很多需求，而是能不做很多需求。好设计的前提是知道不设计什么，这样才能专注在最重要的事情上。
22、
界面将成为功能文档的替代物。 在纸上简单快速地画些草图。 然后把它写成html代码。 界面设计是每个人都会认同的共同基础，这不同于，大段的文字可以有不同的理解。人人都使用同样的屏幕界面时， 混乱不见了。在你开始担心后台代码之前，要建立一个人人都可以看得见的，使用的，点击访问的，并且可以“感受到的” 界面。 一定要尽量把自己置于客户体验之前。
(1)对PRD来说，尽量少用文字，如果必不可少，则尽可能精简，因为一段文字甚至一句话，开发设计和你有可能就有不同的理解，这也是为什么一千个读者有一千个哈姆雷特的原因，文字就是有这个特性，不同人容易有不同的理解，并且不能直达重点。因此，需求文档其实也没多大用。
(2)另外一点，PRD不要过多关注实现方法，而是应该专注在目标和需求上，因为这些才是你可以确认的，可以准确传播给开发设计和运营的。其他的细节只会浪费你的时间，并且没有多大卵用。**避免写功能规格定义是一个好的开始,但不要仅只于此；要处处避免过分的写文档工作。除非有个文件确实要演变成现实, 否则别写它。****建造出来,别写出来。如果你需要解释什么,先建造一个原型而不是写一份冗长的文档。实际的界面或原型是你正在构建一个真正的产品的很好说明。另一方面,一纸文档,只能说明它们终将被丢入垃圾桶。
23、写故事,别写细节。如果你发现你确实需要来解释一个新的特征或概念,写一个简短的故事说明之. 别陷入技术或设计的细节,只讲一个短故事. 象你在正常的交谈时和一个人讲话的方式一样。
它并不需要成为一个短文。只要象记流水账似说明发生什么事。如果拿出你正在开发的屏幕作背景，来简述这个故事,那就更好了。
坚持经验,而不是越来越拘于细节。考虑战略,而不是战术。一旦你开始建立的你的那部分应用，战术自然就会适得其所。现在你只是要想出一个故事,发起讨论,然后使你步入正轨。
24、填入真实的文字而不是测试用的胡乱用语，真实的体验产品。 虚拟文本意味着你不会看到当真实信息录入后出现的不可避免的改变。这意味着你不会知道在你的站点填写表格时会是什么样子。 虚拟文字是隔在你和现实之间的面纱。
25、确立你产品的气质和个性，是有趣的，还是严肃的，保持这种个性，这将在你设计界面，运营产品时帮你定位。
26、做付费产品时，将你的产品或服务拆分成多个小块，免费送给用户，吸引他们来使用你的产品，从而引导他们去使用你的其他产品。设想一下在你的每个专辑中拿出一首单曲作为免费奖励，让全世界下载 --- 就像电影的预告片 --- 就像送往电台的最热单曲---使得人们想去买你的音乐。不要担心这首曲子被盗版。 让人们去演奏， 去拷贝 ， 去共享 ，去分发。要有信心，一旦全世界都听过，他们会付钱买更多。
27、作者提到了开博客或论坛，发教学帖子，给用户传播知识这类推广方法，是一个不错的方法，因为教育一般是比较温和的，相比于那些商业营销推广。在解决用户问题的同时，还能引导用户去使用你的产品。
28、给用户特色食品：给产品加一些特色有趣的特性，不管是从运营上，还是从技术上，能够形成一个较好的传播点。掌握使用最新时髦技术的花边噱头，是一种有效且廉价的方式来引起轰动效应。如果你正在使用了一些新的或引入瞩目的技术，一定要继续使用并且把它在特殊兴趣社区中大肆宣传。
29、找到你的用户在哪，去找到他们在哪讨论、赞扬、嘲讽你的产品，然后和他们互动，询问他们是否愿意成为你产品的热心用户，最后还要做一件事：把积极正面的用户评价，抓到产品官网上，放一个专门页面来展示他们，利用真实用户的评价来帮你推广。
30、做用户型产品，PM肯定要活跃在一线，倾听用户真实的声音。
31、不要把发布出去的东西，叫做测试版，要给用户信心，即便它就是一个不完整的版本，测试版只是内部测试时使用的。
32、产品逐渐变成熟，不意味着产品就要变得臃肿复杂。你并不需要成为一个外太空钢笔，要上下颠倒地书写。 有时成为一支铅笔就挺好。 你不需要是一把瑞士军刀。你可以作一把螺丝刀。 你不需要做一个潜水表，在5000米下还安全工作，假如你的客户是陆地爱好者，只想知道现在几点了。