我的產品沒有 PM，所以每個功能都在搶同一個人的時間

一個人做產品時，功能需求常會以很輕的方式出現：「只要多一個按鈕」、「再加一種分類」、「這裡補個設定就好」。程式可能真的不難，甚至交給 AI，幾分鐘後就能看到可以操作的畫面。

但功能做完之後，事情才剛開始。它要有文案、翻譯、空狀態、錯誤處理、分析事件和測試；使用者開始依賴之後，還要繼續維護。

我的產品沒有 PM 幫忙處理這些取捨。更準確地說，PM 的工作沒有消失，只是全部回到同一個人身上。

沒有 PM，不代表沒有產品管理

產品管理不只是在排 roadmap。它包含判斷要服務誰、現在最重要的問題是什麼、哪些要求應該拒絕，以及什麼證據足以讓方向改變。

團隊裡，工程、設計、行銷與客服可以各自用不同角度挑戰一個功能。獨立開發時，這些角色通常由同一個人依序切換。沒有誰會在會議裡提醒我：「這個功能寫完很快，但你確定要養它嗎？」

真正缺少的是一個能把「想做」和「值得做」分開的機制。

一個功能不是一個檔案

只看 Git diff，很容易低估功能的大小。程式碼合併後，它會散到產品的其他地方，變成持續存在的責任。

實作：畫面、資料、API 與錯誤處理
產品：使用情境、預設值、權限與邊界
呈現：文案、翻譯、空狀態與無障礙
營運：分析事件、客服、付費規則與發布說明
維護：測試、相容性、重構，以及日後如何安全移除

AI 很擅長降低第一項成本，有時也能協助補齊後面的工作。但它不會替我承擔未來的客服、版本相容性和產品承諾。實作變便宜，不會讓持有成本跟著歸零。

最危險的功能，常常看起來只差一點

大型功能容易讓人提高警覺，因為一看就知道要投入很多時間。反而是那些「順手補一下」的東西最容易進入產品。它們不需要重大決策，也很少有人要求寫清楚停止條件。

一個新欄位可能牽動舊資料；一個新入口可能需要同步修改 onboarding；一個新分類可能讓搜尋、篩選與分析事件都多出分支。每一項都不大，加在一起卻會改變整個產品的維護速度。

功能清單就是在一次只看一小塊的情況下慢慢變重。單次決定可能合理，累積後的成本卻被忽略。

每個功能都向同一個人收費

同一天裡，我可以寫程式、修問題、準備 App 更新、回頭整理文章，也可以研究下一個產品方向。這些工作看起來屬於不同專案，實際上都使用同一份注意力。

新增功能不會讓一天變長，只能重新分配原本就有限的時間。它會從修正既有問題、理解使用者、寫文件，或讓另一個產品往前走的空間裡扣除。

這也是為什麼「做得到」對獨立開發者來說是很低的門檻。真正的問題是：做完之後，我願不願意一直對它負責？

我開始先問五個比較難的問題

現在看到一個新功能，我會先寫下它要改變什麼，再決定要不要實作。這五個問題比估工時更能暴露成本：

它發生在使用者的哪一個時刻？
使用者現在怎麼處理，真的卡在哪裡？
上線後要看到什麼變化，才算值得？
誰要維護它，會牽動哪些既有流程？
如果結果沒有發生，什麼時候停止或移除？

這些問題沒有答案時，功能不一定很差，只是還不適合進入 roadmap。先保留想法，通常比先留下維護責任便宜。

KOFNote 的功能清單也很容易繼續長

KOFNote 可以增加更多捕捉來源、匯入格式、AI 欄位、分類方式與自動化流程。每一項都能讓產品看起來更完整，也都能找到合理的使用情境。

但結果契約把優先順序拉回另一個問題：已經保存的內容，會不會在需要時被找回並再次使用？如果這件事還沒有足夠證據，繼續擴大入口，只會讓產品更忙，不一定更有效。

網站、App 和遊戲也在搶同一份注意力

KeepOnFirst 同時有文章、App、遊戲、研究頁面與開源工具。它們可以互相提供題材與技術，但也各自帶著發布、相容性和內容更新的責任。

網站多一篇文章，不只多一個資料檔；還有英文版、SEO、預渲染與 sitemap。App 多一個功能，也不只多一個畫面；還要面對狀態、資料、付費與版本發布。每個表面獨立的成果，背後都會回到同一個維護者。

我不再追求讓每個專案看起來平均前進。比較實際的順序，是看哪一個問題現在最值得取得證據，再把時間放到那裡。

Roadmap 也是一張維護清單

功能還在 roadmap 上時，看起來是一個未來成果。正式上線之後，它會變成承諾：資料不能突然消失、按鈕不能隨便改掉、使用者已經建立的習慣也需要被尊重。

沒有 PM 的好處，是產品方向不用經過很多層才能改變。代價是沒有人會替我擋下那些看起來合理、實際上會讓整個系統變慢的功能。

所以我現在把產品管理理解成時間分配。每個新功能都在和修正、研究、寫作、客服以及下一個真正重要的問題，搶同一個人的時間。能清楚說不，才有機會把答應過的事情做好。