問題背景描述：
創業團隊。
我們最近在做乙個產品，乙個規模比較大的web應用。
由於具有創新性，國內市場沒有成熟的產品可以參考。
正因如此，我們簡單想好基本的功能和架構，心中有了乙個大概的樣子，就開始編碼了。在整個開發過程中，我們一邊開發，一邊思考新功能是不是要加，一邊思考舊功能的優化和刪減，因為之前思考和定義的不是很充分，所以我們開發者一直在處於不斷修改心中藍圖的過程中。
這樣真的好嗎？
持續思考日誌：
寫於2012-10-17：
首先我必須要說：前期沒有做足充分的產品定義和設計，就開始編碼，這是絕對是很不合理的。
新產品和沒有參考，或者自主研發這都不是藉口，因為太多軟體工程的書裡都傳達著這樣乙個資訊：
「軟體工程實踐中，一半以上的專案都會存在交付日期拖延、功能不完整甚至於專案失敗的問題，而導致這些問題最大的誘因，就在於：前期需求定義不完整和規範，或者需求變動過於頻繁
」
所以說，即使種種原因，如沒有現成參考等，也一定要盡可能思考充分，要確定好要做的功能模組（哪怕是幾個備案選一），要想清楚系統的使用者需求，想清楚系統的核心本質，想清楚在產品使用者體驗過程中，我們會傳達給使用者乙個什麼資訊。
這是關鍵：
腦子中我們對系統本質了解的透透的，都不一定能達到預期的效果。更何況我們沒理解透徹，糊里糊塗就做下來了呢？
推而廣之，在編碼、測試乃至看書、查資料等技術問題上，做之前先動動腦子想清楚究竟怎麼下手，什麼是最優選擇。看似耽誤了做事的時間，但是對於整體的效率來說，通常是更有效的一種方式，就像我們總有這樣的經驗：以前中學寫作文的時候，花十分鐘打個草稿或者提綱，通常能有效的縮短整體的寫作文時間，而且動筆的時候一鼓作氣更流暢，文章邏輯更清晰。
同樣的道理，可
為什麼很多時候我們都做的不到位呢。
寫於2012-10-20：
真的很糾結。
是因為創業公司嗎？十幾個人的開發團隊，水平模式（所有人員涉及產品定義/設計/編碼和測試，各有偏重）。
應該是有序的啊：
1.看見樹木，又見森林，心裡知道整個產品是怎麼樣，核心是怎樣，這個模組的功能是什麼，意義何在。
2.想清楚每個模組投入的成本和實現的價值，考慮清楚價效比再做決策。
3.做每個模組時候，應該先從使用者體驗出發吧，我覺得這是最重要的。然後根據這個，考慮視覺流和介面，然後是功能實現的問題。如果每每都從功能或技術難度考慮問題，怎麼做出一流的產品啊。
4.溝通真的很重要，怎麼建立乙個自上而下的溝通方式，怎麼有乙個好的決策制度，真的很重要。如果乙個員工(甚至只是編碼或者測試，都不是產品)覺得這個產品有嚴重的缺陷或者設計失誤，應該怎麼進行有效溝通呢。
總而言之，最近很充實，學習和思考了不少新東西，加油。
寫於2012-12-15：
現在不止是需求的問題了，而是做乙個產品，應該本質上做什麼的問題。
做產品不是為了做出來，而是為了實現一種概念，為某些使用者滿足需求。【今晚酒店**】就是乙個絕妙的例子，要分析市場和需求，考慮各種條件，最後綜合得出結論。
引用周教主的兩句話： 「
很多成功的產品是強需求，所以會有使用者，使用者不斷的提要求，不斷的持續改進體驗，體驗越改進越好，最後就成功了......各位聽了這種分享之後，回去玩命的打造介面調整顏色，最後產品還是不成功，為什麼？因為我們沒有抓到使用者本質需求，所有離開了需求的使用者體驗改進都是耍流氓。
做產品最核心是：解決使用者需求痛點，如果使用者沒有這個需求，那你怎麼做都是無用功。做產品最大的坑就是踩到了空處，你認為有價值但使用者沒需求，那你肯定完蛋了，趕緊換方向。尋找，嘗試和把握住使用者需求痛點，這產品做下去就心裡踏實了，說實話我最怕的就是做心裡沒底的產品，純炮灰。 」
產品化的思考
關於產品化，公司也進行過相應的 也是公司的目標。公司一直在做專案，沒有很好的產品化的思路。個人認為為什麼會稱之為產品，產品應該是有大部分共性的特點，按照相應的技術標準或規範生產出來的東西。比如螺絲釘，有各種規格的螺絲釘，但每種規格都有統一的標準。比如手機，有相應的通訊標準。那麼我們的軟體產品如果要產...
產品經理如何思考和構建需求池？
說到需求池，首先要了解一下什麼是需求池，對於產品新人而言，需求池听起來感覺有點蒙。需求池就是把即將要做和打算要做的事情，放到乙個池子裡面，都收納起來。需求池的作用和意義 做過的人相信很多會有這種體會。那如何建立你的需求池呢？需求描述 備註資訊 所屬範疇 需求提出人 提出時間 需求優先順序 計畫迭代版...
產品化機器學習的一些思考
如果說網際網路是優化資訊的儲存和傳輸方式，提公升生產要素之間的運阿行效率 人工智慧便是對各個生產要素的公升級。平台 強調賦能基礎支撐 基礎平台 通用的ml技術平台，實現常用的演算法,形成通用機器學習平台 spark tensorflow等 對外提供api sdk等，為業務賦能。這類平台聚焦效能 開發...