項目計劃都確定下來，也跟相關各方進行了溝通，那接下來就要進行產品設計了。
對於任何一個項目，具體執行中一般都涉及四個維度：有哪些功能（Feature Set），預期完成時間（Time to Market），預算（Budget，主要是人員，還有服務器、帶寬資源、金錢等），完成質量（Quality，包括可擴展性Scalability、性能Performance等）。不管你做沒做計劃，所有的決定都圍繞著這四個方麵進行考量。如果你的進度拖後了，你可以去掉或精簡一個功能，或者推後完成的時間，或者增加人手、加大投入，或者降低質量等，無非就是在這四個方麵進行取舍。
很重要的一點是，設計產品時，你要大概知道第一版本（V1）是什麼樣子的。你可以在設計時構思產品的最終狀態，但公司不會允許你花大量的資源去打造一個所謂的終極版本。何況，終極版本通常隻存在於臆想之中，用戶的反饋會讓你迅速明白，你需要的是一個能反映出你想法的第一版本，迅速推出後根據市場反應進行更新。所以一定要思考第一版本包含哪些功能、什麼時間發布、需要多少人員配置、需要花多少錢做市場宣傳、達到什麼樣的效果，等等。比如你估計自己的第二版本在3個月內完成，而3個月最有可能獲得10萬人在線，那麼你推出的第一版本能夠滿足30萬人同時在線就行了（3～10倍是一個經驗值，Facebook通常用10倍做估算，但對於初創公司通常不需要那麼高的緩衝量）。 這個3倍的緩衝既可以讓你不需要你在質量上有過大的投入，又不會導致係統因產品成功訪問量過大而崩潰。而第二版本是要滿足100萬人還是1000萬人同時在線，則取決於第一版本的市場反饋。Facebook在設計即時聊天（Chat）功能的時候，其初始版本基本就實現了一個在Facebook網頁上嵌入文字即時傳送的功能，而語音、視頻等當時很多競爭對手都具有的功能，則統統沒有，都是在即時聊天功能被用戶接受之後，在後續版本中慢慢加入的。
這可以避免一開始投入過大，但做出的產品和市場想要的並不吻合，需要再進行很大修改甚至放棄該產品的情況出現，無疑那是很大的浪費。
不管哪個版本的產品設計，一般就是在上述四個維度之間進行妥協，達到一個均衡狀態。
在Facebook，為了在項目開始時盡可能獲得高起點，很多組采取產品預覽（Product Review）或者技術預覽（Technical Review）的做法。
早年間，很多想法都是先搞出產品原型，邊幹邊想，然後在上述四個維度之間做調整，隻是當時並沒有對這四個維度有清晰的認知。這在早期的Facebook沒有什麼問題，一個產品初期的樣子，隻要不是太差，對於不是非常大的用戶量而言，還是可以迅速迭代、迅速改善的。但逐漸地，用戶量達到一定規模，無計劃的狀態會帶來很多後續問題。比如沒有預先對工程量的充分估計導致後期到處找人幫忙，或者經常推延項目完成日期。由於在Facebook並不缺少高手，也讓很多牛人有了個人英雄主義式的出風頭機會，把一些看起來不可能在一定時間內完成的項目最終完成了。但公司變大之後，個人英雄主義將很難保證公司的可持續性擴展，管理難度也非常大，因此在產品設計上進行有意識的計劃就越來越有必要。
慢慢到後來，稍微大一些的產品類項目都需要設計師參與。產品經理、工程師、設計師三方在一起討論所開發的產品究竟需要解決什麼樣的最關鍵問題，圍繞這個問題，設計最最重要的功能。然後，設計師會給出樣稿（Mock-up），會包含每一個頁麵或者步驟應該是什麼樣的，大家對這個樣稿進行大量討論，然後再修改，直到做出感覺差不多的版本，就可以讓工程師實現出來，然後再微調。
產品設計進行得差不多的時候，產品負責人會召集相關人員（也歡迎所有對該項目感興趣的人，但一般不主動宣傳）進行一次對產品的預覽討論。會議上，工程師、產品經理、設計師會談談為什麼做這個產品、產品的核心功能、主要界麵等，並盡可能給大家展示設計的頁麵（Mock-up）。在這個過程中，參與者會提出很多問題，尤其是這些產品影響到的相關產品技術人員的意見非常重要。這些意見會被一一思考、討論，並盡可能在產品定稿之中有所考慮。不被接納的意見，負責人也會有禮貌地回複，並做出解釋。通常，為了把第一版本推出去，我們經常用“試驗（Experiment）”的理由，是告訴別人我們需要第一版本在有控製的範圍中來驗證產品，並會嚴格監測重要數據。如果產品成功，我們會在後續版本中再認真考慮更多的功能。以試驗的方式推出新產品，通常阻力要小很多。