有了目标以后，会产生很多相关的想法（Ideas），但很难判断究竟哪个想法一定能帮你达到这些目标，你也不可能把所有的想法都试一遍，往往到最后都需要你有理有据地进行“赌博”，把精力押在某几个核心的想法上。这就对人的要求比较高了，也是Facebook要招最好的工程师的原因之一。工程师不仅要善于写程序，也要有选择想法的能力，你要对这个问题有很深入的思考，进行大量的分析，还要有胆量，才能果断押注，并且有很高的命中率。
那么，这些想法从何而来呢？最自然的方式就是之前延续下来的、大家明确知道要做的项目，而那些不明确的想法，才是难点。在发展非常快的公司里，绝对不会缺少这种不明确的想法。在Facebook，一般是由技术经理、产品经理、工程师贡献大量的想法。由于和产品相关的想法比较容易产生，而对于基础架构的需要经常被忽略，在Facebook，很多组都特别强调后台工程师要主动思考未来一段时间内应在后台系统上做哪些开发，以配合我们产品的发展需要。另外，商业运营（Business Operation）那边的同事也会传过来一些想法。做下一个月计划时，我会在当月25日左右开始给相关人员发一个一周后的头脑风暴（Brainstorming）会议邀请，并希望他们在会议之前把他们认为应做的或者想做的事情发邮件告诉我，我可以事先分类整理，让会议进行得更加高效。当然，线下的讨论、分享等也是产生想法的好机会。
收集了想法之后，就要开始头脑风暴了。一个做法是：先列出设定的目标，再在这个目标的指引下去思考哪些想法可以为之服务。做头脑风暴的原则就是要把“提出想法”这个过程和“分析想法”严格区分开来。在提出想法这个过程中，针对某个特定目标（比如Goal X），让大家绞尽脑汁地集思广益，但对提出的想法要克制住讨论其优点与缺点的冲动。之所以这么做，其中一个很重要的原因是：让提想法的人没有任何压力，可以“肆无忌惮”地提，而不用担心马上可能会被批判。
等有了足够多的、不错的想法，接下来最为关键的一步就是分析想法——如何挑选出最可能产生效果的想法。理论上，如果有无限的资源，我们应该尝试所有的想法。但在Facebook，任何时候都处于资源短缺的状态，我们必须把有限的资源放到有可能产生最大价值的想法上面。这里，我要特别强调一下“Top X（只做前X项）”规则：只做对目标最有影响的前X项。必须要面对一个非常残酷的事实——80%的影响是从20%的工作上得来的。“Top X”的原则就是鼓励大家积极地找出这20%的工作，应该着重在哪些想法上面，这对工程师的要求非常高，也是发挥大家聪明才智的机会。我们会对所有的想法进行讨论，根据每个想法对目标的影响和其所需要的资源（主要是人力与时间——“人周”）进行讨论，然后排序（按P0，P1，P2……的方式来），最后挑选排在最前面的几项。这些会议通常是技术经理或者产品经理来主导，但要求每个参加的人积极参与，发表意见。这个过程看起来比较机械化，但和Facebook其他所有的流程一样，这个过程只有一个大致的指导意义。在讨论过程中，工程师或者产品经理的个人激情，以及他们对一个想法的准备程度，会在很大程度上影响大家对一个想法的理解和支持程度。分析完后，对几个明显一定要做的想法很容易决定，对几个要去掉的也很容易决定，关键是剩下的那些想法，没有足够的精力把它们都尝试一遍，这就要考验你的抉择能力了。流程毕竟是死的，如果没有很好的人参与其中、去激活这个流程，还是出不了好结果。我个人的一个经验是，如果你想说服其他人采取你的想法，你需要两样东西。一个是故事，或者叫例子，就是为什么这样做有效，能不能让你的说法有感染力，让你的说法给人留下印象；另外一个是数据，让你的说法有数据的支持，那么可信度会高很多。
关于时间分配，还有一个“6-2-2”原则，Facebook的很多组都尽可能遵循这个指导原则：60%左右的时间放在那些能够预期的工作上；20%的时间花在后台架构和产品质量上；20%的时间花在比较有风险、有争议的、可能会带来某种颠覆性的后果的那些想法上。对于这60%的事情，通常比较容易做计划，因为这些事情很多时候不做不行，不仅重要，通常也比较紧急，用一位朋友的话来说，都是自己知道“不做可能会死”的事情。花在后台架构和产品质量上20%的时间，是Facebook花了多年时间之后才逐渐形成的。对于非常早期的公司，最大的问题是证明其产品概念是可行的（Proof of Concept），质量固然重要，但并不是必须要花20%或者更多的时间，要具体情况具体分析。但对于Facebook，用户规模上亿之后，质量再也不是一个可以被忽略的问题。公司逐渐强调在计划中要有意识地保留资源在后台架构设计的规模化（Scalability）、可靠性（Reliablity）、性能（Performance）等，以及保证代码质量，再也不能忍受动不动就出现某个功能被一小段程序漏洞搞死的情况。这也是为什么Facebook原来经常提倡的“求快，可以出错（Move Fast and Break Things）”变成了现在的“求快（Move Fast）”。而最后花在风险比较大、有争议的想法上20%的时间，是每一家创新公司都应该思考的。就是说在你挑选想法时，觉得某个东西不确定、但如果做成了会非常有意义，那就要有一个工程师在背后积极支持这个想法，可能会带来很大成功。这些想法，通常很重要，但不是那么紧急。很多创新公司从一个创新点起步，但很快地，原来的创新被市场认可之后，很多资源会持续投入在之前的工作上面，被惯性带着走。这个时候，如果不主动把资源预留在一些有争议性的事情上面，等到原来的创新变成累赘，公司就再也无法翻身。以生产黑莓手机出名的加拿大RIM公司（Research in Motion Ltd.）就是败在故步自封上面。而Facebook对于这一点非常清楚，公司鼓励把资源有意识地预分配到有风险、有争议，但可能会有颠覆意义的想法上。这一步做好了，可以持续性地领导市场，比较难被竞争对手超越。
这里也体现出硅谷的公司和很多中国公司的不同。很多中国公司更希望考虑商业化发展，并不非常关心和鼓励创新。很多想法的主导是从市场、运营那边来，而较少出自热衷于解决某个问题的工程师或产品经理。中国创业者几乎都更早考虑“如何赚钱”这个问题，这就让大家不敢轻易做冒险的尝试。而在硅谷，尤其是互联网产品型的公司，无一不在一开始就把关注点放到用户的增长上面，他们关心更多的是能不能做成一个很多人都会去用的伟大产品。如果做成了，钱不会是问题。苹果公司之所以能够在乔布斯回归之后起死回生，最开始是因为推出iPod，但真正关键的是iPhone。不要忘了，iPhone推出的时候，市场上至少有上千款手机，谁也无法想象这种情况下再推出一款手机可能有革命性的意义。这些产品在以前的苹果公司是无法想象的。Facebook的News Feed（动态消息）、Timeline（时间轴）等产品，一开始都是这种有争议性的尝试。我觉得，公司应当把20%的精力花在一些创新的、有风险的、有争议的产品或想法上，它或许可以给你的公司带来巨变。
当然，不同的公司，由于产品特点不一样，这个时间分配的比例也不一样。每家公司应该量力而行。
对于如何挑选那些接下来要去实现的想法，还有几点需要注意。
1.季度性计划主要是指导性的，不会强求把它们变成必须要遵循的工作计划。季度性的计划让大家知道在大方向上要做的事情有哪些。但在互联网这个行业，3个月已是很长的跨度，很多事情、很多变化都可能发生。如果非常死板地制订季度性计划并严格执行，很可能和实际情况脱节。而月度计划则是大家尽量要做到的，要当作较严格的计划来执行，在月计划上列出的项目要付出很多努力去争取完成。理论上，可能周计划或者日计划更加具有灵活性，但在实践中，我发现月计划是把全局观和实际情况较好地进行结合的一个平衡。而周计划和日计划作为工具，可以让员工自己为了完成月计划去制订。
2.围绕着每个想法的影响力进行辩论。如果你觉得某个想法是我们应该优先考虑的，那你要思考的一个问题是：因为我们资源有限，所以你觉得当前我们倾向去做的几个想法之中，哪个可能会被你支持的想法所取代？这种思考让坚持某种想法的人不会只考虑自己的想法，而是迫使他们从全局的角度思考每个想法的影响，再把自己的想法加入到全局的考量之中。通过这个过程，让工程师主动比较一些项目的影响力，因为很多人习惯了“我想做某个产品”这种念头，而缺乏横向比较的思维。经过这样一轮思考后，再决定是否要继续进行下去。
3.“120%”规则。我们最终挑选出来要做的想法大概是团队可承担范围的120%左右，太多了可能无法实现，太少了则不够进取，所以通常会尝试去实现120%的想法。
4.按照之前的讨论，还要保证一些底层架构和产品质量的工作是在这些想法之中的。很多时候，需要事先要求工程师在这方面进行思考，以在讨论的时候提出来。
最终挑选出要做的想法后，会整理出一个项目计划。计划上的每个项目都对应着一个想法，每个项目都会列出明确的责任人，一个项目下可能有多项需要完成的任务。我们会在一个wiki（公开自由修改的文档）工具上公布并进行项目管理，有时候也使用Google的Spreadsheet来进行项目管理。这里没有使用专业的工具，对这部分的要求只是：1）公开，容易分享；2）大家都能修改。每次讨论项目进展时，比如每周一次的小组会议，在会前就要求每个组员把项目的状态更新，工具会自动将项目的文字颜色改变（Color Coding）以反映项目状态。所以，大家在看到整个wiki页面5秒钟内就会知道完成情况如何。在会议中，每个wiki上面的每个项目都会被讨论一遍，通常只详细讨论项目中碰到的难点或者产生的有可借鉴价值的经验，对于流水账式的项目报告则花很少的时间，通常一句话带过。
项目X（Alex+Sridhar）
【未完成】增加决策树模型并发布该模型（Alex）
【未完成】修复关于属性X的bug#123（Sridhar P）
项目Y（Pratap）
【未完成】增加在工具Z上显示Y属性的小插件（Pratap）
【已完成】修复关于属性X的bug#123（Pratap）
对于我们组特别关注的最最重要的目标，会在黑板的一边列出来，相关责任人的名字、预期的时间点都放在上面，另外一边用温度计的样子来显示完成的进度，非常直观。毕竟wiki页面需要打开电脑才能看得到，而在黑板上画出来，大家路过时或者不经意的一抬头都可以看到，能够时刻提醒。每当项目有大规模进展时，大家都在场看着一位同事把温度计多涂红一点，这比某个人去独自修改wiki页面更有成就感。而当温度计被涂满时，就意味着目标实现了，这种集体的成就感非常好。
我们的一种典型做法就是把最重要的目标画在我们座位附近的墙上。
这样可以时时看看，下图是完成了任务。
