作者認為，為了做出引領潮流的創新産品，在産品開發流程中的每一步，Facebook是這樣做的：
描繪遠景，設定目标
對于遠景，要思考以下幾點：
第一，為什麼設這個目标而不是另外一個目标？
第二，在做一件事情之前，腦子裡應該有這件事情完成之後是什麼樣子這樣一個畫面，接下來很多事情都是圍繞着這個最終畫面來進行的。
第三，計劃做些什麼事情來實作這個遠景？
我們可以采用“SMART”規則來設定目标：S—非常詳細具體的(Specific)，M—是能夠衡量的(Measurab1e)，A—要夠有難度、有挑戰性(Aggressive)、R—現實的(Rea1istic)、T—要有實作的期限(Time-bound)。
收集想法并排出優先次序
想法可以來自任何人和任何地方。在Facebook，一般是由技術經理、産品經理、工程師貢獻大量的想法。
收集了想法之後，接下來要做的是先列出設定的目标，再在這個目标的指引下去思考哪些想法可以為之服務。
等有了足夠多的、不錯的想法之後，接下來最為關鍵的—步就是分析想法，即如何挑選出最可能産生效果的想法。
關于時間配置設定，有一個“6-2-2”原則：60％左右的時間放在那些能夠預期的工作上，20％的時間花在背景架構和産品品質上，20％的時間花在比較有風險、有争議的、可能會帶來某種颠覆性的後果的那些想法上。
如何挑選那些接下來要去實作的想法呢？要注意以下幾點：
第一，季度性計劃主要是指導性的，不會強求把它們變成必須要遵循的工作計劃。
第二，圍繞着每個想法的影響力進行辯論。
第三，“120％”規則，即嘗試去實作120％的想法。
第四，要保證一些底層架構和産品品質的工作是在這些想法之中的。
最終挑選出要做的想法後，會整理出一個項目計劃。計劃上的每個項目都對應着一個想法，每個項目都會列出明确的責任人，一個項目下可能有多項需要完成的任務。
對于小組特别關注的最最重要的目标，會在黑闆的一邊列出來，相關責任人的名字、預期的時間點都放在上面。另外一邊用溫度計的樣子來顯示完成的進度，非常直覺。
跨團隊溝通
兩類人是特别需要溝通的：一類是不同職能之間的溝通，另外一類是相關的工程兄弟組之間的溝通。
跨團隊溝通也讓不同的團隊事先都清楚自己在一個項目中的角色和任務，知道哪些人将會在一起合作，各個組可以做出事前的安排。
告知所有可能關心的人
召開一次最終的計劃定奪會議。整個計劃定下來之後，會發—封郵件給所有關心該計劃的人和相關工作的人。
設計産品
任何一個項目具體執行中一般都涉及四個次元：有哪些功能，預期完成時間，預算(主要是人員，還有伺服器、帶寬資源、金錢等)，完成品質(包括可擴充性、性能等)。
很重要的一點是，設計産品時，要大概知道第一版本是什麼樣子的。
在Facebook，為了在項目開始時盡可能獲得高起點，很多組采取産品預覽(Product Rev1ew)或者技術預覽(Technica1 Review)的做法。
一個原則是：有好的開源系統，就用開源的；有好的商用産品，就購買商用的；必須自己開發的或者跟Facebook核心競争力息息相關的，則集中力量開發一套。
Facebook從不期望由一個人去完成某個項目所有的事情。
對于産品設計，有以下一些基本理念：
第一，不要過度設計。
第二，産品越簡單越好，但并不意味着簡陋。
第三，對于自己做出來的産品，你必須是它的使用者。
第四，産品要确實有用，主要流程盡可能順暢。
第五，不追求完美。
第六，保留最基本的品質底線。
指定項目責任人
對于每個項目，都要指定一個明确的責任人，一般都是工程師。這樣做最大的好處是責任非常清楚，每一個項目都有非常清晰的擁有者；第二個好處是鍛煉員工的才能；第三個好處是友善交流。
定期碰頭會
對于每個開發中的項目，要清楚地知道具體進展，因為今天做好的東西是明天的基礎。
召開碰頭會時，所有跟這個項目相關的人都要過來，圍繞着這個項目把所有相關的任務及其進展迅速過一遍。
了解進度，彙總報告
對于負責一個團隊的研發經理而言，要對自己組裡正在進行的每個項目都有深入和及時的了解，知道最新的進展：哪些項目處于綠燈狀态，哪些處于黃燈狀态，哪些處于紅燈狀态，并對此進行思考、采取相應行動。
編寫簡報的注意事項：
第一，簡報應該能在一分鐘之内被人閱讀完畢。
第二，在簡報的最開頭一段，可以明确列出這周的核心資料的變化。
第三，應該隻涉及組裡最重要的3～5個項。
第四，每個項目隻用最最重要的一兩句話去闡述清楚進展。
第五，項目進展的描述要着重在動詞上面。
釋出産品，監測資料
釋出前評估，就是在釋出之前，根據具體的産品或者該次釋出的特點，做一些諸如釋出政策、需監測的核心資料、産品示範、核心算法改變等方面的讨論。一些經驗：1)要短；2)形式可以多樣；3)人員選擇可以多樣；4)内容可以多樣。
一種釋出工程的做法是閥門控制式的灰階釋出(Gated Launch)，就是有所控制地選擇釋出的人群及其比例。
需要監測的有兩類資料：一類資料反映目前的系統狀态，另外一類資料反映新功能的使用者影響。
所謂Post-mortem，就是通過分析過去發生的問題，從中總結可以采取的行動方案，以避免類似的錯誤再次發生。
Post-mortem會涉及以下幾個方面：
第一，發生了什麼？
第二，影響多大？
第三，問題的原因是什麼？
第四，事件發生的具體時間表？
第五，如何避免将來犯類似錯誤的行動方案？
從以上的總結中，我們可以看到，Facebook的産品的整個開發流程注重的是工程師的自主性、流程的合理及規範性、産品品質的可控性及可監測性、産品版本的持續完善性。與之相對的，國内很多IT公司的做法是這樣的：
第一，軟體工程師隻需要實作需求工程師給出的需求，根本沒有直接與客戶進行交流的機會。工程師的很多想法都會被無情地駁回，以至于其創造性及主動性消失殆盡。
第二，開發人員隻顧編碼實作需求，而不重視對開發出來的軟體進行測試，抑或是随便設計一些測試用例就了事。每當客戶傳回軟體問題之後，又要占用大量的工作時間來“救火”。
第三，代碼品質完全由作者本人說了算，沒有同行評審流程。即使有，也是流于形式。在送出軟體版本之前，也沒有人來對代碼的規範性和版本的完整性進行檢查。
第四，不注重産品的使用者體驗，缺乏一種從使用者的角度看問題和以使用者為中心的理念。單單強調産品功能，而忽視了其易用性。
作為一家引領時代創新潮流的公司，Facebook的諸多經驗值得廣大IT公司學習和借鑒。就像李開複老師所說的：“無論中國是否能出一個Facebook或紮克伯格，我都相信了解Facebook，并從王淮的親身經曆學習，對于中國的創業者、工程師、學生都會有莫大的幫助。”