產品開發
一個人做一百個產品：節奏、記錄與停損
Throuz Labs 的規則只有一條：做一百個 MVP，主題不設限。
這個數字不是隨便定的。做到第八個的時候我發現，前三個產品裡我學到的東西，有一半是關於「怎麼做產品」而不是「這個產品好不好」。那些經驗只有在數量夠多的時候才會浮現，而一百是一個足夠讓模式顯現、又不至於一輩子做不完的數字。
這篇寫的是維持這個節奏實際需要的三件事。
一、節奏：固定週期，浮動範圍
我的週期是兩到六週，而且時間是固定的，範圍是浮動的。
這個順序很重要。多數人的做法相反——功能清單固定，時間往後延。而時間一旦可以延，就會無限延，因為每一次延期都有很好的理由。
固定時間的好處不只是「準時」，而是它強迫你在每一個決策點做取捨。當你知道第 14 天一定要上線，「要不要加這個功能」就不再是一個開放問題，而是「加了這個要拿掉什麼」。這個框架下做出來的決定，品質高得多。
具體的分配我寫在另一篇，這裡只講一件事：第一天不寫程式。 第一天只用來決定不做什麼。
二、記錄：每個產品都填同一份表
做完一個產品，我會填一份固定格式的紀錄。格式三年沒變過，因為固定格式才能橫向比較。
基本資料
- 產品名稱與一句話說明
- 實際開發天數（不是預估）
- 上線日期
假設
- 這個產品驗證的假設是什麼（一句話）
- 假設成立的話，會看到什麼現象
結果
- 上線後 30 天的實際數字
- 假設成立了嗎：是／否／不確定
回顧
- 最大的技術誤判是什麼
- 最大的需求誤判是什麼
- 如果重做一次，第一天會做什麼不同的決定
最後那三題最有價值。填第一次的時候會覺得很虛，填到第八次的時候，你會開始在新產品的第一天就想起某一題的答案。
這份紀錄我不公開，因為它包含太多具體的失敗細節。但整理過的版本會變成這個網站上的文章——事實上你正在讀的這一系列，大部分素材都來自這份表。
三、停損：三條線
持續出貨最反直覺的部分是：難的不是開始，是停下來。
一個做了三週的產品，就算數據很差，也很難放手。因為投入已經發生了，而且你總能想到「再加一個功能可能就會不一樣」。
我用三條明確的線來對抗這個傾向。
線一：上線後 30 天，沒有任何一個非親友的持續使用者
「持續使用」的定義是：使用超過三次，且跨越至少兩週。
如果 30 天內連一個都沒有，就停止投入新功能。這不代表下架，只代表它進入維護狀態，不再吃我的開發時間。
這條線很殘酷，但它處理的是最常見的自欺：把「有人試用」當成「有人需要」。 試用只證明標題吸引人，持續使用才證明問題存在。
線二：連續兩次的改版都沒有改變任何數字
有時候會有一點使用者，但成長停滯。這時候的誘惑是繼續改——改介面、加功能、調文案。
我給自己兩次機會。兩次改版之後，如果核心數字（不是造訪數，是實際完成核心流程的人數）沒有變化，就停。
兩次的意義是：一次可能是改錯方向，兩次都沒變，代表問題不在你改的那一層。
線三：我自己不再使用它
這一條最主觀，但準確度出奇地高。
我做的產品多半源自我自己的問題。如果連我自己都不再打開它，通常代表兩件事之一：問題其實沒那麼痛，或者我用別的方式解決了。
任何一種都足以構成停損理由。
停損之後產品怎麼辦
不下架。這是我一開始沒想清楚、後來覺得很重要的一點。
停損的意思是「不再投入開發時間」，不是「關掉」。靜態託管的成本每月不到一美元（實際帳單拆解在這裡），留著它的成本趨近於零，而好處有兩個：
- 少數真的在用的人不會被拋棄
- 一年後回頭看，有些產品的價值會在你意想不到的地方浮現
我有兩個產品，在停損半年之後因為外部環境變化而重新有了使用者。如果當初下架，那個機會就不存在了。
為什麼公開寫這些
一開始只是給自己留紀錄。後來持續寫下去，是因為發現了兩件事。
第一，寫出來會強迫你想清楚。 一個只在腦中的判斷，可以模糊地存在很久；一旦要寫成別人看得懂的段落，你會立刻發現哪裡沒想通。這個過程本身就改善了決策品質。
第二，失敗的細節比成功的結論有用。 網路上「如何做好產品」的文章非常多，但幾乎都是成功之後的回顧，而回顧會自動整理掉當時真正的混亂。我想留下的是混亂本身——第幾天發現方向錯了、當時的判斷依據是什麼、後來證明錯在哪裡。
如果你也在做類似的事，這些紀錄或許能省下你一點時間。如果沒有，至少它們對三年後的我會有用。
其他文章
內容有錯誤或想補充？寄信到 support@throuzlabs.com， 我會更新並在文中註明修訂日期。