在产品开发的过程中，工程师的主动性体现在要善于处理不确定性，迅速发布满足可以接受的最低标准（但并非低标准）的产品，再根据监测数据的情况不断完善，最终达到极致。
在Facebook，对于工程师来说，公司特别提倡以下几点。
其一，迅速发布，再进行监测（Move Fast and Monitor Closely）。Facebook一直崇尚的是尽可能满足一个最低标准，当然这个最低标准也还是很高的，你可以在完成产品离所谓的完美程度还有一定距离时迅速推出去。接下来，就要监测这个产品最重要的几个指标，从整体的运营数据来看看你的产品究竟算不算成功，找出哪些方面没有达到你的预期，然后思考如何加以改进，再推出下一个版本。Facebook很多尝试性产品发布的时候有一些已知问题，由于Facebook发布是灰度发布 方式，如果这些问题只在极端少见的情况下才会被用户碰到的话，在新产品的发布初期是可以接受的。这由主导工程师和产品经理来决定，大家都习惯了相信这些人的主观判断。Facebook崇尚的是Move Fast，前提是不能有太多错误，尤其是低级错误。如果你仅仅速度够快，但每次推出去的产品各种错误接连不断，很快你的名声就毁了，这种质量的快速是不允许的。Facebook在早期还提Break Things（产生破坏），其实是有点开玩笑的，后来工程师多起来，即便每个人出错概率只有千分之几，综合下来公司每天还可能会出现一个较大错误，后来逐渐开始提倡初始代码质量方面的要求，所以就不再公开讲Break Things，而Move Fast一直在强调。在2009年的一次“礼品商店”新版本发布中，我犯了一个错误，把本来只应该影响和礼品商店相关的数据库访问扩展到了全站，结果导致全站的后台数据库崩溃，在半小时内Facebook不能响应任何访问。这是我在Facebook第一次让全站崩溃，也是最后一次。我当时的确很紧张，想死的心都有，在极度紧张中很快提交修复，半小时后所有的访问都恢复正常。当天和我一起作战的一位资深工程师（公司前20位员工，后来是工程总监）开玩笑地对我说：“Harry（哈里），如果你从来都没有让整个网站崩溃的话，你就不能说自己真正是Facebook的工程师！好玩吧！”
其二，坦然对待不确定性（Be Comfortable with Uncertainty）。前面讲到，要迅速发布产品，会涉及究竟优先开发产品的哪些功能，在市场上去做试验。在互联网2.0时代，访问网站是光速，更新网站是近似光速。Facebook将网站的更新做到了极致。这样做，主要是由于这种产品是否适合市场的不确定性：这一次做对了，下一次继续增强；这一次做错了，下一次马上改正。这就考验工程师跟不确定性打交道的能力，你要根据自己的知识和经验，敢于做出选择，然后根据监测数据及时改进或做出调整。公司不允许对一个计划中的产品是否成功有太多纠缠，当然会有讨论，在讨论中鼓励大家理性地分析用户可能有的反应，感性地推销自己对某个产品方向的热爱；但对于有争议的产品，很难有一个大家都完全认同的方向。这个时候，公司更愿意相信有能力的产品经理或工程师的判断。比如刚开始决定要用时间轴来替代个人主页，谁能确定这样做的效果就一定比原来好呢？但扎克伯格敢于将它推出来进行试验，并且工程师团队也愿意跟他一起去尝试。在大家互相无法说服的情况下，倔强一点的工程师会说“何不让我花两天时间做一个最简版本来试试看呢？如果有效，我们继续做；如果无效，那就停”，这就是著名的“代码胜于雄辩（Code Wins Arguments）”的来源。当然，这些做法中最重要的是监测相关数据，以验证自己的预期，如果出现的错误越来越少，用户反馈数据越来越好，那就说明这种改变是积极有效的。
其三，不追求极致，应该不断地发布以达到目标（Done Is Better Than Perfect，Stay Focused and Keep Shipping）。在眼下所处的互联网时代，软件开发工程师不要试图追求一次就让你的产品达到极致。这一点不像硬件，比如苹果公司的iPhone等硬件产品，它对产品有极致的要求，因为硬件一旦销售出去，如果发现致命的问题，除了召回没有其他办法，只能等到下一次推出新产品时再改进。它也不像传统的桌面软件产品，其更新与否很大程度上取决于用户的兴趣、时间、使用习惯和集成程度等，导致产品更新有很多负担。而且多次更新之后，会出现用户群之中多版本共存的问题，版本兼容、版本管理就成为很头疼的事。这些都增加了产品的开发难度，拖累了产品的开发速度。而通过浏览器访问的网站产品，则没有上述问题。代码只存在于服务器端，开发者要么不更新，要么最终全部更新 。而且，网站的更新可以在比较短的时间内完成（小网站只需几分钟，像Facebook这么大的网站最多几小时），用户也没有任何本地旧产品的负担。这就允许互联网公司可以不断地尝试，不断地改进，在这个过程中逐渐达到极致。当然，由于用户的口味、需求都在不断变化，在这种商业环境中，没有最终的、稳定的极致状态。只有不断地进行符合用户需求的改变，才是能够在互联网时代生存下去的法宝。
在上述过程中，如何处理监测数据，是非常关键的。我认为，要重视数据而不盲从数据。决定产品方向时，要的是想象力、激情和胆量，而不是数据。数据能让你的团队沿着正确的方向前进而不出轨，也有助于产品从“一开始是什么样”到“最后应该是什么样”的逐渐优化成型，但数据不能帮你决定方向，尤其是产品的初期方向。
举个例子，在开发反欺诈相关系统的时候，我们最初开发的是人工规则系统，规则是人写的。一条人工规则是有少数变量的简单逻辑，比如“如果（‘注册在30天之内’‘支出大于100美元’‘是首次支付’‘用户来自印度尼西亚’），那么（拒绝交易）”。但其中存在的问题是——人写的东西容易出错，人很难有效地处理10个以上的变量。我们需要一个更有可扩展性（Scalable）的解决方案，希望把很多事情自动化，让机器人做更多机器擅长的事情。因此，我们达成了一个共识——将绝大部分规则逐步替换为机器学习获得的判断模型。这个共识更多的是依靠直觉，依靠以往的工程经验，把我们团队所有资源都押在了人工智能（机器学习）这个方向。然而，到此为止，我们虽然试过一个智能模型，但在现实条件的限制下，其效果并没有比人工系统强。但这完全在预料之中，数据量仍然较小的情况下，人工系统很多时候都可以打败智能系统。但等到数据量很大的时候再上马智能模式，已为时太晚。因为打造一个好的智能模型，采集更多数据，这需要工程师资源；至少花几个星期去积攒数据，这需要时间资源；去开发算法并验证结果以判断有效性，这需要工程师和运营部门的配合。因此，我们做转向机器学习方向的决策无法有太多相关数据可以支持。我们的确忐忑不安，但坚信一点：现有的基于人工规则引擎的防欺诈系统会很快成为死胡同，因为它太死板，而且不易规模化以处理大数据。所以，我们需要做艰难的、有远见的决定。就像在电影《指环王》中Frodo明知通向Mordor的道路很黑、很冷、很危险，但那是一条他必须要选择去走的路，我们就选择了在机器学习上押宝。虽然万一失败了，整个团队会很难看，我也把自己在Facebook的职业声誉押在了这个方向上,但我们决定走一条艰难的、可自己认为是正确的路。
当然，同样不能忽视数据。没有数据的支持而一味靠直觉走黑路，很容易走岔道，甚至大错特错。有一段时间，我们认为爬行工具［通过分析关联的Cookie（网络用户的浏览器上留下的一段数据）、信用卡］也许可以找到很多欺诈的同伙。通过试验却发现，这种预期是否成立很大程度上取决于当前流行的欺诈行为的特点。比如，当失窃或贩卖信用卡的案例非常普遍时，关联分析是一种有效的方法。因为你会发现同样一张被贩卖的“黑卡”不断出现在完全没有联系的用户账号上，你就可以通过这些关联卡号去寻找所有的“黑卡”用户，再从这些用户出发怀疑他们其他卡的来源是否正当，这样可以不断地顺藤摸瓜。但如果主要情况是账户被黑或小孩子冒用家长的信用卡去消费，关联分析就作用不大了。直觉在现实前面碰了一鼻子的灰。不过幸运的是，我们很快就意识到这一点且把这个项目叫停了，没有浪费太多的资源。
