第二章 起始点
一个很好的做软件的方式就是一开始用它来解决你自己的问题。由于你自己变成了软件的目标受众因此你会知道什么是重要的什么不是。这样做下去将会是推出一个突破性产品的伟大起始点。
手头有多少钱就先动起来做多少事。用心想想决定什么是你最基本需要的，什么是可以先舍弃不做的。什么事是你可以三个人就搞定而不必用到十个人？什么是两万块而不用十万块就能办到的？什么样的软件你可以一边白天打工用业余时间做出来的？
一个简单方法让你能准时地在预算范围内推出产品：定额定量。绝对不要在一个难题上多投时间和金钱。要么缩小规模，要么缩小范围。
如果你不能在预定的时间和预算内完成所有的东西的话，就不要拉长时间和增加预算。相反的，把产品的外延缩小些。下一步总是有时间可以加东西进去 —过后有的是时间，当下却是稍纵即逝的。我们建议：范围缩小些。做半个产品比做半拉子的产品好。
有时了解你的应用程序应该做成什么样子的最佳方式就是，认识到它不应该成为什么。搞清楚你的软件的对手是谁，就象点一盏灯，能照亮你前行的道路。你能从敌人那里得到的一个好处就是：一个非常清晰的营销理念。人们很容易被冲突对立挑动。并且通过把一个产品和另一个作比较能更多地了解这个产品。必须指出的是，也不要太过着迷于竞争。过分地去分析其他产品会慢慢限制你的思维想像力。很快地看一下他们在做什么，然后就要回到你自己地理念和理想上来。
老是看你的竞争对手在做什么是你给自己找麻烦的最快的方式之一。我们不随大流，相反的，我们只看大方向，时时提醒自己什么是我们想要解决的问题关键，怎样去解决它。
第三章 保持苗条
如果你越不把软件当作一种交易去做，你就越能做得好。把它控制在一个你能把握的小范围内，你就有可能真正地享受过程。
在美国，在这个时代生意经往往是提出一个构想，让它能盈利，在还能盈利的时候把它卖了，然后改行或不干了。这往往是一个能否挺下去的问题。对我而 言: 去热爱烘培，卖你自己做的面包，人们如果喜欢它我就卖多些。我就这么把烘培事业做下去，因为我知道我在做好吃的人们爱吃的东西。
如果你不能如飞一样的改变，你就会败给能够做到的竞争者。这就是你需要追求更小质量的原因。 质量会由于以下因素增加
- 长期合同
- 多余的职员
- 固执的决策
- 关于会议的会议
- 厚重的流程
- 存货（物理的或者头脑的）
- 硬件，软件和技术的锁定
- 专有数据格式
- 未来被过去支配
- 长期的路线图
- 办公室政治
质量会由于以下因素减少
- 必要而及时的思考
- 多面手的团队成员
- 拥抱限制，而不是试着移除他们
- 更少的软件，更少的代码
- 更少的特征
- 小规模团队
- 简单
- 被拆分为正交的接口
- 开源产品
- 开放的文件格式
- 开放的文化，使承认错误更容易
低廉和迅速的改变是小团队的秘密武器。
保持小，保持简单，顺其自然。
对于产品的 1.0 版本，请从只有三个人开始。三是一个魔力数字，提供足够人力的同时允许你保持流畅和敏捷。从一个开发者，一个设计者，和一个清道夫（一个可以在开发和设计中随意切换的人）开始。如果你不能够用三个人建造第一个版本，那么你或者需要更改人数或者需要缩减初始的版本。
总是有不充足无法满足所有需要。不充足的实践。不充足的金钱。不充足的人。这是一件好事情！约束驱动创新并强迫集中精力。不要试着移除它们，使用它们带来你的优势。
约束经常是伪装的优势。忘掉风险投资，长发布周期和快速招聘。代替的是，和你目前拥有的合作。
第四章 优先级
大量的小公司犯了试着装作大公司的错误。就好像他们意识到他们的规模是一个缺点，需要隐藏。太糟糕了。小型实际上可以是一个巨大的优势，尤其是在通讯方面。骄傲地、无所畏惧地做到真实。
竭尽全力将你的软件定位在一个点上。你的软件代表的是什么？它到底是有关什么的？在你开始设计或写任何代码之前你必须清楚地知道你做这个产品的目的 — 它的前景。把理想放大些。为什么要有它？它和其他类似产品不同的地方在哪里？
在初期时忽略细节，先粗后细！你可有常常一整天被困死在一个设计原素或一个程序代码上？可有不时觉得你今天的进展实在算不上什么真正进展？过早专注于细节就会导致这些结果。永远，都要从大到小去做。
别整天操心还没成型的麻烦。如果你已经掌握了你需要的信息就及时做决定。这样你就能把注意力集中到需要马上解决的问题上来。
找到你产品的核心市场然后就专注进去，如果你想讨好每个人那么你什么人也讨好不了。（缩小市场范围）
伟大的软件必须要有自己的理想。伟大的软件必定是有倾向的。当人们使用软件的时候他们不只是在看功能，同时他们也在寻找一个解决方案，一种理想。决定你的理想而后追求不懈。
第五章 功能选择
构建一半产品，而非产品有一半缺陷。摆出产品应该成为什么样的任何点子，然后砍掉一半。减少功能直到只剩下最必要的功能。周而复始。
最好的设计师和最好的程序员不是 技能最好的，或者手指最敏捷的，或者用 Photoshop 用的神乎其神的人。他们是能够决定什么不重要的人。真正的收获源自于此。
你的大部分时间浪费在无关紧要的东西上。如果你能抛弃不重要的工作和思考，你将会获得不可思议的生产力。
不轻易实现功能。构建部分而不是残缺不全的秘诀是说不。每一次你对一个功能说 yes 时，你正在收养一个小孩。尽量为客户少发布一个功能，再看客户是否愤怒地离开。
即使一个新功能通过了对其说不的阶段，你还需要去发现它隐藏的成本。警惕功能循环（带来更多功能的功能）这种现象。
对于每一个新功能你需要……
- 对它说不
- 强迫它证明自己的价值
- 如果得到否定的答案，就此打住。如果是 yes，继续往下……
- 为界面绘制草图
- 设计界面
- 编写代码
- 测试，改进，测试，改进，测试，改进，测试，改进……
- 检查帮助文字是否需要修改
- 更新产品预览流程（如果有必要的话）
- 更新用于销售的拷贝（如果有必要的话）
- 更新服务条款（如果有必要的话）
- 检查是否违背之前的任何许诺
- 检查价格体系是否受影响
- 上线
- 深吸一口气
为什么不问人们，不想要什么? “如果你可以去掉其中一个功能,那会是哪个呢? “ ，“你为啥不用? “ ， “什么让你觉得最碍事？” 。 答案并不是“更多”。有时你对用户最大的优惠就是把一些东西去掉，拿出来。
第六章 过程
一个可运作的软件是积蓄动力，整合团队，去除行不通的点子的最佳方式。你必须从第一天开始就将它摆在首要位置。
如果你知道过后总是要重来一遍，你就不需追求一开始就达完美。
从灵感，到草稿，到 HTML，到代码
先别写任何程序代码。只把 HTML 和 CSS 的框架搞出来。有关细节实施是后面的事。当模型框架看起来过得去又兼具一些足够必要的功能时，就是开始上代码编程的时候了。
远离设置首选项，替客户拿主意。
不要搞正式版和 beta 版的游戏。两者不应该有区别。另外做一个 beta 版本只会得到一个轻描淡写的试用。正式版本，注入一些 beta 的功能，才能得到全方位的体验。
- 决定它是否值得做，如果是的话:
- 尽快去做 — 不需完美，只需做下去
- 保存。上传。发布。
- 看人们的反应
第七章 组织
给程序员一个下午去编一个小的特定的模块，她就会有办法把它赶出来，然后准备进入到下一个任务。
在工作中建立一条规定：一天中一半的时间作为独处时间。从上午 10 点到下午两点，任何人都不可以和别人谈话（除了午餐时间）。或者让一天的前一半或者后一半作为独处时间。只要保证这个范围是连续的，为了避免破坏生产力的干扰。
给延期的软件开发项目添加人手只会更加拖延进度。
第八章 员工
有句老话是这么讲的：如果你想做好一件事，去找你所认识的最忙的人。
选择快乐的和技术水平中等的，而不是令人不满的专家。
寻找充满热情的人；寻找你信任他可以独立完成任务的人；寻找在发展缓慢的大公司受过折磨，并且渴望新环境的人；寻找为一起去建造你正在建造的东西而感到激动的人；寻找对你所厌恶的事物同样感到厌恶的人；寻找为入你的伙而感到兴奋不已的人。
第九章 接口设计
开始编程之前先设计界面，做应用应该始于界面设计。先行编程则会让你陷入花费额外开销的圈套。
对于每一个界面，你需要考虑可能出现的三种情况：
- 常规，一切运行正常的话，人们看到的是一个充满内容的界面。
- 初始，人们第一次使用这个应用，在加入内容前的界面。
- 错误，有错误发生时，人们看到的界面。
第十章 编码
关键是要把一个需要很多编码的困难问题，转换为一个需要较少编码的简单问题。 你可能没有精确的解决这个问题，但是这没有什么。只花 20%的努力就解决了原来问题的 80%就是一个大胜利。 原来的问题再糟也不会耗费我们 5 倍的努力去解决它。
良好的软件设计的“秘密” 不在于知道把什么加入代码;而是要知道把什么拿出来！正是要识别出 硬点和软点,并且知道那里应该留下空白/空间,而不是试图去填满更多设计.
第十一章 文档
不要写功能定义文档，功能定义一点用都没有。
你应该做什么去替代功能定义呢？ 去写一个简明的替代文档，以此引导你去做那些真正的事。 写一页的说明去描述这个应用要做什么。 使用平实的语言并且要简短。 如果要阐述的内容超过了一页纸，就太复杂了。 这个过程不应该超过一天。
接下来开始建立界面----界面将成为功能文档的替代物。 在纸上简单快速地画些草图。 然后把它写成 html 代码。
如果你发现你确实需要来解释一个新的特征或概念,写一个简短的故事说明之. 别陷入技术或设计的细节,只讲一个短故事.
第十二章 定价和注册
为了让人们在喧嚣中注意到你，免费赠送一些东西吧。
在你的程序里注册和注销应该尽可能简单。在销售站点的每一页都放上一个大大的、清楚的注册按钮。告诉大家这是多么容易的事：“从注册到登录仅仅只需要 1 分钟！”
注册表单要尽可能短。不要问一些并不需要的问题，不要抛出一个长得吓人的表来为难大家。
同时，如果他们决定离开，要确保能导出他们的数据。我们确保客户随时可以轻易地导出xml 格式的所有信息和评论。那是他们自己的数据，他们理应能按自己的意愿来处理。
谁都不会喜欢长期条款，提前终止费或是一次性的安装费，所以要避免这么做。我们的产品付费方式为月付，不用签订条款，你可以随时取消，而且从不会有什么安装费。
要发布类似提价这样的坏消息啦？应该多次提前通知，尽量把坏消息带给用户的痛苦降到最低。同时，应考虑在保留条款中规定，现有客户在一定时间内仍可以原价使用产品。用户就是你的奶油和面包，你要让他们感受到被重视，而不是被欺骗。
第十三章 推广
如果你在发布应用之前没有一些事前吹嘘，人们根本就不知道有这回事。为了闹出个大动静和引起期待， 学学好莱坞风格的运作： 1） 挑逗 ， 2） 预演， 3）上演
挑逗：提前几个月要开始不断透露些暗示。 让人们知道你在干什么。 发布一个徽标。 在你的博客中发布一下进展。 保持神秘，但是要播下种子。同样，建立一个网站，好让你可以从那些感兴趣的人那里收集电子邮件。这个阶段， 你也要开始引诱专业和业内人士。 这些家伙站在前沿。 他们是引领时尚潮流的人。 他们的虚荣心和其作为时尚领导者的地位,使其容易被吸引。 告诉他们，要安排他们参加秘密进行的内部预演。 如果有一个象 Boing Boing， Slashdot 或者 Digg 这样的站点链接了你的（Web）应用，你就会有大量的浏览访问量跟进。 另外，你在 Google 的网页评级也会水涨船高。
预演：发布前的几周， 开始预演特征。 给人们幕后入口。 描述产品的主题。 对于 Basecamp ， 我们发布了屏幕截图 和 高亮度的提示条， 里程碑 和其他一些特性。 同样， 告诉人们此应用背后的思想和原则。你也可以给少数人发放一些特殊“金元券”，让他们可以提早开始使用这个应用。 这些自我感觉提前被选中，享受了特殊荣耀的人其实充当了你的 beta 版测试人员，你从中获益。 同理， 一旦上线发布，鼓励人们来注册，你因此可以得到大量的电子邮件用来发起闪电般的宣传攻势。
上线（开演）：正式上线时间到了。 现在人们可以真正地去“剧院”看你的应用了。 发邮件给那些注册的用户。 发布你的全面营销网站。 力到处散布你的信条。 让博客都链接到你。 公布你的进步： 已注册了多少用户？已经进行了那些更新/调整？ 显示你的成长势头并且保持住。
你仍需要一个顶级的推广站点。 在这个网站中要有什么？ 这是一些主意：
- 概览: 说明你的应用及其益处
- 导游:引导人们体验各项特性
- 屏幕截图和录像: 展示应用面貌并演示如何使用
- 宣言: 阐述其背后的哲学和思想
- 案例研究: 展示现实生活中的案例的可能性
- 共鸣: 引用来自客户，评论，新闻的证明材料
- 论坛: 提供社区会员相互帮助的场所
- 费用和注册: 快让人们使用你的应用
- 博客: 博客提供新闻，技巧等，使你的网站保持活力
博客可以比广告更具效力，（而且便宜很多），应该一开始就建立一个博客！
建立某类网站 , 要快征集邮件。选定你的域名并且发布你的徽标，还要写上一两句，或者至少也要暗示一下，你的应用是作什么用的。 然后，要求人们留下电子邮件地址。
掌握使用最新时髦技术的花边噱头，是一种有效且廉价的方式来引起轰动效应。如果你正在使用了一些新的或引入瞩目的技术，一定要继续使用并且把它在特殊兴趣社区中大肆宣传。
第十四章 支持
拆除研发和技术支持之间的墙壁，所有我们的技术支持邮件，都是产品的真正创建者亲自回复。
你不需要一个手册去使用 Yahoo 或者 Google ， Amazon。 因此， 为什么你不能也建立一个不需要手册的产品呢？ 力争建立一个这样的需要零培训的工具。你该怎样去做？ 好吧， 就像我们以前提到的，你开始就要保持简单。 你的应用越不复杂，你就越能免除帮助人们摆脱困境的麻烦。之后，一个伟大的事前支持途径是在潜在的容易引起疑惑的地方，使用内嵌的帮助和常见疑难解答。
快速回复客户的问题。即使你没有一个完美的答复，说点什么。 若有人抱怨有个不能马上得到解决的问题，象这样告诉他们, “我们已知道你所言那个问题，我们即将在不久之后仔细研究一下。”
从你创业的第一天起，就要牢记客户是最重要的资产，他们对你的长远成功至关重要，因此对待社区用户要礼貌至上。和大人物竞争的方法是要从小处开始， 并且关注每个客户。当你的客户遇到 bug 时，一定要即时答复并且感谢他们的告知。
作为一间软件研发公司，你必须扮演过滤器的角色。 并不是每个人建议的每件事都是正确答案。 我们认为客户所有的需求并不总是正确。 你不得不时常让一些人伤心失望。 关于这点， 作为一间研发公司热爱你的产品是最重要的。如果你的产品中掺和了一些你不认可的因素，你将不会爱你的产品。这是要否决你不以为然的客户需求是必须的，这一点的另一个证。
使用论坛让客户互相帮助。
如果某事出错就告诉人们。 即使他们开始并未曾发现。关于发布消息的旁注，好和坏：当坏消息来时，立即把全部公开。另一方面，应该慢慢地一点一滴地透露好消息，如果您能延长好的信息起到的效果，那么一定要这样作。
第十五章 后续
快速更新显示你的干劲。也表示你在听。还显示你有更多的后备招数。这使你能引起第二波的共鸣。加强了最初的好印象。 这给你一些谈资的和其他博客评论的话题。 明知快速升级迫近，使你在发布前把精力集中放在最关键的部件。 与其试图加入更多东西，不如开始真正完善核心功能群。 那么你就可以在真实世界推出产品。 一旦它在那里了，你可以开始收集客户的反馈意见，你就会知道其后的哪些方面需要注意。
上线后不要停止写博客。 用一个专门的经常更新的博客，显示你的产品是充满活力的， （至少每周一次，如果可能应该时常更新） 。 这些事情包括：
- FAQ 疑难解答
- How-tos
- 小贴士 ＆ 技巧
- 新功能，更新 ＆ 补丁
- 共鸣/新闻
不要用“测试版“作替罪羊
分清缺陷的轻重缓急（甚至可以忽视其中一些）。
分清缺陷的轻重缓急。 有多少人受到影响？ 问题坏到什么程度？这个缺陷 bug 值得立即重视吗或可以等待？你现在做什么将对绝大多数人产生最大影响？很多时候，加入新的功能，甚至比更改现有缺陷更为重要。
订阅你的产品和你的竞争对手的新闻消息（知己知彼总是明智的）
新的并不总是意味着改进，有时你应该找准你的产品的定位点。这是基于 Web 的应用优于传统桌面软件的主要好处之一。 桌面软件生产商每年都要向你兜售新版本。 只因为他们不能总是卖给你相同的版本， 他们不得不通过添加新功能为收费提供正当理由。 从这里正式软件变得臃肿了。Web 软件是基于订阅收费的模型之上， 人们按月付费使用服务。 你不需要通过不断增加更多更多的功能来进行增值销售，你只需要提供一个持续的有价值的服务。
