這是最近做產品的一些雜感。放在 FB 有不少迴響所以貼過來。
做產品 = 「解決問題」
很多人做產品，包括我很久以前做產品。其實都犯了一個很大的謬誤。就是太早寫 code，甚至是說太早寫 spec。
做產品，精確地來說，就是在「解決問題」。
很多產品之所以會失敗，就是可能下決定的那個人（有可能是 Founder，有可能是 PM ）看到了問題，先做了第一個假設性的解法，並決定將之 implement。
因為這個假設性的解法，很可能是有盲點的。但 Founder 或 PM 下了命令，它必須得執行。團隊覆對實作手法產生了矛盾大吵特吵。經過了大半天，合作的眾人才可能發現。原先被設定的解法，可能是錯誤的。
甚至當初被武斷所下的結論，甚至也可能是錯誤的。甚至再追溯下去，還可能發現原來的那個問題是假問題。
一旦太早由個人所推出的結論規格化，並且放到整組人馬的生產線上。後面自然可能巨幅浪費資源，甚至可能因為其他面子或政治問題再也難以回頭。
由這個主題延伸談下去的部分可以往下繼續談：
- 創業 MVP
- 寫 code 是否 tdd, 是否需要早期架構封裝化
- 好的稱職 PM 應該為團隊做什麼
創業 MVP
一些活躍的網路從業人員，創業的 pattern 是：因為有著精湛的 coding 技術或者其他網路資源，所以想創業時第一想到的就是蓋平台 => 找錢。或者是先寫 code 再 pitch 找錢。
事實上這是錯的。
創業，實質上就是解決問題並將之商業化。
要先找到了想付錢的買家，再有了初步方案，再透過前幾筆的銷售確定的這個解決方法可以 work。再想要把這個過程 automated 化。automated 的這一步才是寫 code。
之所以為什麼很多時候，想發包給接案公司的客戶或者是公司內部的 PM 連 User Story 都寫不出來。那是因為他根本連自己的商業模型都沒有 run 透想通。既然沒有想通，何來 automated 化。
這中間大部份的實作者（aka RD）都沒有錯，因為在不知道你想解決什麼問題之前，能做的只是能憑藉著過去的經歷與想像把類似的模型蓋出來。
創業與做產品就是在一個一個回覆客訴與處理危機的過程中，慢慢把模型砌出來。
當然，沒有人說這個成本很低。
只是大部分沒有悟通這件事的人，會選擇在一開始就想閃避這件事的風險，例如一開始就創業者「想建立平台讓大家上來用」，PM 一開始就寫出「詳細的規格」。
結果在中間實做 Interact 的時候造成了更大的風險，甚至產生結不了案，錢提早用完的悲劇。
開發產品是否需要 TDD，是否在早期就需要將架構封裝化
實際上寫 code 的也是會遇到類似的狀況。
有些個性過於要求完美的 RD，也是會做出類似的事。明明只是一個簡單的功能，卻 Over Architecture。程式碼很漂亮，但是改不動。
程式碼只是表達解決方案的一種手段。
Over Architecture 或過於封裝的程式碼往往不是去除程式債，反而是新增的程式債。
因為這些人的過於封裝，不是增加 Story 的可讀性或維護性，他們的修改手法，反而恰恰把 User Story 支解到無法辨讀。大大造成隊友擴充功能或者修改方向的困難。
同理，什麼時機寫 Test
- （後補 Test ) 你已有了粗略的方案，你想要將之塑形化，並且希望他不會在意料之外的情境下發生。同時避免其他人以後修改這段程式碼時，破壞了執行結果。
- （先寫 Test ) 你手上拿到了一個非常清楚只是要重複的方案。你要用結果驗證你的 automated 方案是無誤的。
程式碼的乾淨度與創業成功的因果關係
同理，Code 的乾淨度與創業成功也沒有正相關，至少，在最初期沒有正相關。
Code 的乾淨度與 Project 成功的正相關度是受到 RD 教育訓練的影響產生的迷思。
大多數成功的專案，專案 code 都很噁心。至少在一開始很噁心。創業要的是正確的解決方案，而不是優美的 coding style。就如同創業公司的 Stage 演變。沒有人 care 你是怎麼優美的解決，人人只要買解決，而不是你多優美的解決。
什麼時候 code 會變得乾淨，當你有 A round 的錢，B round 的錢時候。有錢 hire 資深人士 refactor的時候。
你的「生意模式」需要「塑形化」，需要「水平擴展」化。這時候你的 code 就會變得乾淨。
不是一開始你的 code 就「先行塑形」「先行水平擴展」，那麼就會成功。而是一開始的主意 works，由生意驅動的 refactor。才帶來後面的 clean code。
只是人人往往倒果為因。
PM 的職責
PM 的職責是什麼？
既然創業做產品是解決問題。PM 的職責是負責去搜羅資源負責讓實作者更能設計出正確方案的或者接近類似方案的人。而不是「方案制定者」。
很多爛網路公司的產品會失敗，是因為請了不懂實作的 PM 亂寫規格，導致的黑暗混亂與巨幅浪費資源。之所以這些 PM 不懂實作，是許多 RD 認為「搜羅資源與需求」不需要技術（他們自己也懶，而且 RD 喜歡寫 code 當戰士勝於在前面當坦克）。
而 PM 又認為自己是 "Manager"，既然他負責搜羅這些資源，就有權力引導甚至是決定專案的方向。
如果你仔細觀察，打造出成功產品的 PM ，往往有技術背景。
一個成功的 PM，應該具備下列特性
- 能夠協助 Unpack 問題本身
- 能夠協助引導討論方向
- 能夠協助搜集幫助討論方向的資源
- 具備一定的實作能力知道資源的限制與 Tradeoff
- 引導溝通
- 緊盯資源的花費與加速或放慢專案的進度
- 花上大量的時間與專注力在 improve 團隊溝通速度與方法
因為實作產品，本身就是一件協調眾人之力，釐清問題，溝通，Prototype，Implement 並balance resource 的過程。