> ## Content Index > Fetch the complete content index at: https://www.davehuang.io/llms.txt > Use this file to discover other available public pages before exploring further. # 獨立開發者該如何選題？ - URL: https://www.davehuang.io/domain-knowhow/ - Published: 2026-08-20T05:13:32.000Z - Updated: 2026-08-20T05:13:32.000Z - Description: AI 讓做出產品變容易了，但真正困難的，仍是判斷什麼問題值得解。從三位獨立開發者的選題路徑，我重新思考 domain knowhow、product sense，以及自己想讓什麼開始複利。 - Author: Dave H - Tags: Business, Indie Hacking 自從看完《[Unscripted](https://www.amazon.com/dp/0984358161?lv=shuf&channelId=500&plpRedirect=mhFallback&ref=davehuang.io)》以及許多 [Starter Story](https://www.youtube.com/@starterstory?ref=davehuang.io) 的商業案例後，我就養成了在生活中觀察 SaaS 題目的習慣。 剛好身邊有不少經營中小型企業的朋友，每次聽他們分享公司經營上遇到的問題，我都會忍不住在腦中拆解他們的 workflow，思考其中有沒有什麼事情，可以透過我會的技術解決。 最近的一次聊天，就讓我找到了一個結合法遵與 RAG 的題目。我很快開始動手做 POC，除了寫程式，也一邊補足自己在 RAG 與法遵上的知識。 靠著 Claude Code 輔助，一開始的進展非常順利，隨著 RAG pipeline 與系統架構逐漸完整，我開始意識到，工程實作可能只是這個題目最容易解決的部分，真正困難的點在後頭：Golden set 的資料要從哪裡來？當一個法遵案例連我自己都看不懂時，該怎麼判斷系統的回答是否正確？Eval 又該由誰來做？ 這些問題最後都指向同一件事：這套系統能不能商業化，取決於我對 domain knowhow 的理解，以及能否把這份理解轉成可靠的交付。 對我來說，軟體系統有相對清楚的 verification 方式。但法律就沒這麼容易了，那是超出我專業範疇外的知識體系。 軟體與法律，兩者都需要有人為其負責，但法律答案即使附上法源，仍需要具備資格的人判斷，並且願意替結果背書。我沒有足夠的信心，單靠技術跨過這道門檻。 走到這裡，我開始省思：是我一開始就選錯了題目，還是這有辦法透過 skin in the game 來跨過？ ![](https://www.davehuang.io/content/images/2026/08/IMG_0643-1.jpg) 這是一隻英鬥 當我還卡在這個問題裡找不到答案時，LinkedIn 上的獵頭竟然剛好丟給我幾個 AI Native SaaS 的機會。我甚至還沒來得及把自己的思緒整理清楚，就進入了另一輪面試準備週期。這個專案就這麼被我擱置在一旁。 在幾輪面試下來，也剛好給了我機會看見資金更充足的新創，如何處理類似的 domain knowhow 困境。 比方說，以法律為題材的 AI 新創，他們有足夠的資金直接把律師與顧問納入團隊，有些人甚至就是公司股東。提供領域知識的人共同承擔風險，也共享產品成功後的利益。 很顯然，這種資本與組織規模已經超出獨立開發的範疇。但它呈現出的工作方式，很接近我嚮往的環境：工程師與領域專家長期待在同一個問題裡，也一起承擔產品最後能否交付的責任。 對我來說，這種合作最有價值的地方，是工程師能一路參與問題如何被定義、答案如何被驗證，以及產品最後如何交到客戶手上。 如果有機會加入這樣的團隊，我能透過自己的工程能力，把領域專家的判斷轉成可靠、可維護的系統，除了把需求做完，也逐漸弄懂為什麼要做、客戶真正重視的是什麼、技術上該怎麼取捨。Domain knowhow 便會在這個過程中累積。 這段面試經驗也讓我回頭檢視，自己對獨立開發的假設。 我原本把這條路想得很線性：找到一個潛在痛點 → 累積足夠的 domain knowhow → 搭配 technical skills 與執行力做出 POC → 確認有人需要之後，接著處理 distribution。 而問題就在這個順序。它假設我能先辨認出值得解的痛點，再把所需的 domain knowhow 補齊。 真的走進陌生領域後，我才發現，domain knowhow 很難像技術套件一樣，等到需要時再安裝。有些知識需要長期累積，有些資訊根本不在公域流通。更麻煩的是，一個題目是否適合獨立開發，可能在我真正理解它以前，根本沒有辦法判斷。 那麼，獨立開發者究竟該如何找到值得長期投入的痛點？又該怎麼累積足以解決它的 domain knowhow，最後把產品帶到願意付費的人面前？ 帶著這些問題，我回頭研究了最近接觸到的三位獨立開發者。 ## **三位獨立開發者，三種選題路徑** Jesse Hanley、Takuya Matsuyama 與 Jannis Fedoruk-Betschki 三人的背景跟產品截然不同，卻都從自身的職涯軌跡逐步累積，發展出一門能由一人或極小團隊長期經營的生意。 以下我會先簡單介紹產品，再用四個問題來拆解這三個案例： - 他解決了什麼問題？ - 他憑什麼能解決？ - 客戶從哪裡來？ - 驗證花了多久？現在走到哪裡？ ### **1\. Bento - Jesse Hanley** [Bento](https://bentonow.com/?ref=davehuang.io) 是一套主打 Email 成功送達率與行銷自動化的平台，服務對象以 SaaS 和電商公司為主。 當初我會注意到 Jesse，是因為在 X 上看見 Marc Lou 跑去日本找 [Jesse](https://x.com/marclou/status/2069264657102336353?s=20&ref=davehuang.io) 玩。好奇之下，我開始爬文研究他到底是誰，也撈出了一系列 Podcast 訪談。 我很喜歡 Jesse 在 Podcast 上帶給我的感覺：務實、真誠、帶有溫度。而他也常在訪談中帶出自己的價值觀——他很重視家人與生活品質，他總是傾向把生意維持在小而美的規模，把時間跟專注留給真正重要的人事物。 #### **他解決了什麼問題？** Jesse 想解決的問題，來自他過去操作 Email 行銷的經驗。 行銷團隊寫了好的內容、設計了完整的漏斗，最後卻因為寄件信譽、DNS 身分驗證或共享 IP 裡的其他寄件者，讓信件直接進入垃圾郵件。既有工具的自動化流程編輯器也常常很難用，價格還會隨著聯絡人數暴增，即使多數名單根本沒有收到信。 Bento 最初走的其實是網站個人化的服務，當時還不是 Email 行銷產品。為了讓企業客戶看見個人化帶來的成效，Jesse 又加入分析與追蹤功能，記錄網站訪客的行為。上線後，他發現客戶對這些訪客數據的興趣，甚至高於原本的個人化功能。這讓他開始思考：既然已經知道訪客做過什麼，能不能直接根據這些行為採取下一步行動？於是他加入 Email 自動化，再一路往 SMS、交易型郵件與成功送達率深挖。 #### **他憑什麼能解決？** Bento 這題目與 Jesse 的工作經驗幾乎完全重疊。他早期替澳洲的保健品零售與電商公司負責系統、行銷及運營，後來又自己經營行銷公司，替客戶操作 SEO、廣告與 Email 行銷活動。等於他自己就是 Bento 的理想顧客 (ICP)，多年後才開始打造自己的工具。 Jesse 自學 Rails 與 React 進行全端開發，當遇到超過能力範圍的問題，就找更有經驗的工程師合作，再從對方提交的程式碼中學習。 #### **客戶從哪裡來？** Bento 的獲客方式也沿用他過去經營行銷公司的做法：長期在網路上無償的幫助別人。 Jesse 曾經連續三、四年把 Calendly 放在 [Twitter 個人檔案](https://x.com/jessethanley?ref=davehuang.io)，任何人都能直接跟他預約通話。他常常花一個多小時免費幫對方釐清問題，最後什麼也不賣。這些關係可能幾年後才變成客戶，或在某個朋友受不了 Mailchimp、Klaviyo 時，想起可以找 Jesse。 客戶進來後，他又透過創辦人親自提供的支援繼續推動口碑。US$30 與 US$3,000 的客戶都能直接在 [Discord](https://bentonow.com/docs/support?ref=davehuang.io) 找到他；他也會親自展示產品、協助資料搬遷、錄製教學影片。 小客戶介紹大客戶的情況反覆發生，客戶支援本身逐漸變成 Bento 最重要的獲客渠道之一。近年他也開始透過 Podcast 節目、贊助與訪談，反覆讓目標客群記得 Bento 的存在。 #### **驗證花了多久？現在走到哪裡？** 從 Jesse 的回顧看來，Bento 在開始前沒有經過一輪明確的市場驗證。當時他仍在經營自己的行銷公司，出發點之一只是很想寫程式、成為開發者。他找來在東京認識的 Andrew Culver 合作，第一年把數據分析、少量 Email 與自動化功能全塞進產品。Jesse 後來形容，當時的自己想替所有人做所有功能，結果一直沒有進展。 直到 COVID 疫情期間賣掉行銷公司，需要重新建立現金流，他才開始全心投入回 Bento。 這時他發現，使用者真正有迴響、也確實持續使用的是 Email 功能，才開始把產品往這個方向收斂。 如果只看市場驗證所需的時間，Bento 其實是三個產品裡最慢的。Jesse 邊經營行銷公司邊開發，花了約三到四年，才讓功能完整到足以被客戶視為既有 Email 服務商的替代方案。這場驗證沒有在幾週內跑完。他一路從客戶的使用狀況找線索，慢慢收斂產品定位。 但這段時間也換來了很深的產品認知。2026 年 3 月的 [Tropical MBA 訪談](https://tropicalmba.com/episodes/million-revenue-no-employees?ref=davehuang.io) 將 Bento 描述為一間年度經常性收入已超過 US$1M 的公司，換算後每月營收規模至少是 US$83K。Jesse 沒有公開精確 MRR，但整間公司大多數時候依然只有他自己，加上幾位兼職協作者。 ### **2\. Inkdrop: Takuya Matsuyama** [Inkdrop](https://www.inkdrop.app/?ref=davehuang.io) 是一套專門為軟體工程師打造的跨平台 Markdown 筆記工具，支援離線使用、雲端同步、端對端加密與外掛系統。 我是在研究 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 編輯器選型時，關注到 [Takuya](https://www.craftz.dog/?ref=davehuang.io)。他是我少數知道的日本獨立開發者，他也用 Ghost 自架 [部落格](https://www.devas.life/?ref=davehuang.io)，讓同樣身為 Ghost 用戶的我感到格外親切。 他非常認真地透過 [YouTube](https://www.youtube.com/@craftzdog?ref=davehuang.io) 經營受眾，用著他獨特的日本腔英語，分享自己的生活，以及一路面對的挑戰。他近期有一集講述自己如何在 AI Era 被搞到 [burnout](https://youtu.be/Mf%5F524J8fPE?si=qo62chYjCIHaPXKf&ref=davehuang.io)，讓我相當有共鳴。 #### **他解決了什麼問題？** 這個產品的起點非常直覺：Takuya 找不到自己想用的筆記軟體。（跟我開發 Peak Pals 的初衷很像！） 他當時用 Evernote 記錄開發筆記，但它並不適合存放大量程式碼片段與 Markdown。網頁版工具離線時不能用，透過 Dropbox 同步的編輯器又慢又吃 CPU，其他選項不是功能太少，就是複雜到讓他不想每天打開。試過一輪後還是找不到能長期使用的工具，於是他決定乾脆自己做一個。 #### **他憑什麼能解決？** Inkdrop 的領域認知首先來自 Takuya 自己。他就是目標用戶，每天寫程式，也每天記錄技術筆記。 他從青少年時期就持續開發軟體，工作上待過 Yahoo! Japan，也長期參與開源專案與接案。他曾經做出擁有 13 萬使用者的音樂應用程式 Walknote，卻完全沒有辦法變現。這段失敗讓他深刻認知到，下載量與商業可行性是兩件不同的事。到了 Inkdrop，他從第一天就採用訂閱制，並把客群限縮在願意為開發工具付費的人。 #### **客戶從哪裡來？** Inkdrop 早期的獲客幾乎都來自內容行銷。Takuya 持續寫下自己如何開發、獲得第一批客戶以及經營一人 SaaS，再把文章分享到 Hacker News (HN)。流量最高的時期，約九成新使用者都來自 HN。他沒有在部落格直接推銷產品，只是很誠實地分享自己做對與做錯的事情，反而慢慢累積了讀者與口碑。 2018 年後，獲客重心逐漸移到 devaslife YouTube 頻道。他拍自己的開發生活、工具與業餘專案，在影片裡自然帶到 Inkdrop。到了 2024 年，YouTube 一度帶來 70–80% 的新使用者。後來他也建立付費用戶才能加入的 Discord、舉辦線上聚會；這些管道未必帶來大量新客，卻讓核心用戶更願意留下。 #### **驗證花了多久？現在走到哪裡？** Takuya 沒有在開發前進行用戶訪談或架產品 waitlist。他先清空了手上的接案，接著給自己三個月的時間完成 MVP，並在 2016 年 6 月把封閉測試版丟上 Hacker News。文章登上首頁後，短時間內帶來超過 1,000 人登記測試。這些使用者提供錯誤回報與功能建議，也讓他從使用數據裡觀察到確實有人每天使用。這是 Inkdrop 最早的市場驗證。 產品在 2016 年 10 月正式收費，半年後累積 US$1,000 銷售與 30 位付費使用者；上線約一年時，MRR 已經來到 US$1,361。速度不算爆發，但已經足以證明有人願意長期為這個利基產品付費。 Takuya 最近一次給出的明確數字，是 Inkdrop 已經連續三年以上超過 US$10K MRR。不過他在 2026 年初的 [2025 年回顧](https://www.devas.life/my-2025-indie-dev-journey-review/?ref=davehuang.io) 中也提到，因為整年專注開發 v6、減少行銷，新客成長放緩，營收比 2024 年低。因此目前只能確認它曾穩定跨過 US$10K MRR，無法知道 2026 年的精確數字。 ### **3\. Magic Pages: Jannis Fedoruk-Betschki** [Magic Pages](https://www.magicpages.co/?ref=davehuang.io) 做的是 Ghost 部落格託管服務。使用者不需要處理伺服器、更新、備份、CDN 或寄信設定，幾分鐘內就能建立一個功能完整的 Ghost 網站。 Jannis 是近期讓我印象最深刻的一位獨立開發者，因為我們有過實際互動——我甚至在跟他接觸的兩個月後，成了他的付費用戶！ 我當初是在 [Ghost forum](https://forum.ghost.org/?ref=davehuang.io) 上搜尋關於搜尋功能的討論串，當時的我想要自己做一個 Ghost RAG 的 side project，進而看見 Jannis 在論壇上非常活躍，還分享了自己開發的全新搜尋套件。當時我覺得：這個人超屌，一定是個 Geek。繼續往下爬文才發現，他竟然還經營著 Ghost 託管服務，而且是一人公司！ 最開始跟他的接觸，是因為 Magic Pages 官網的 localization pricing 頁面出了一些 bug，讓我誤以為年費是 US$4,480，後來才發現其實是 NT$4,480，幾乎是 Ghost(Pro) 的半價！跟他反饋完本地化問題後，他竟然在 30 秒內秒回我，還在 10 分鐘內修正了這個 bug，讓我非常驚艷。 隨著我鑽研如何進行 migration 的過程，我也問了他幾次問題，接著就開始了試用期。這段期間只要我寄信到客服信箱，他都在短時間內親自回應我，不論他自己當地是什麼時間。就這樣，我被他的執行力與熱誠打動了，決定加入他的平台。 後來我也發現了他的 [寶藏 Blog](https://www.jannis.io/?ref=davehuang.io)。他在上面分享許多創業過程遇上的困難以及個人經驗。我最喜歡的是他講述自己當初 [回絕 Apple offer 的故事](https://www.jannis.io/how-saying-no-to-apple-changed-everything/?ref=davehuang.io)，那個選擇也一路造就了今天的他。 #### **他解決了什麼問題？** Ghost 這套開源軟體已經把寫作體驗與電子報系統做得很好，剩下的差異通常出現在架站方式的選擇；選擇自行架站，就得面對 Docker、資料庫、備份、DNS 與 Email 設定；選擇託管服務，價格又可能隨著自訂主題、CDN 或進階功能一路往上疊。許多創作者只想專注在寫作，最後卻被迫理解一堆可能兩、三年才碰一次的技術細節。 另一個差異在於電子報的計價方式。Ghost(Pro) 依網站的會員總數決定方案，免費會員也會列入計算，但寄信次數沒有限制。Magic Pages 則提供無上限的會員數，每月包含 10,000 封 Email，超出後每 10,000 封收取 US$5。對寄信頻率不高的小型部落格來說，後者更貼近使用情境，能夠省下寄信成本。 Jannis 最初也沒有打算經營一間完整的託管服務公司。2023 年初，他只是想架一台伺服器，放一批 Ghost 網站，再以這套基礎發展 Ghost 客製化開發服務。他先開出 15 份、每份 US$249 的終身方案預售。產品當時甚至還不能使用，第一批客戶卻已經願意付錢。 #### **他憑什麼能解決？** 這份信任與他先前累積的領域認知有關。Jannis 原本從事客服工作，2020 年曾在一間新創公司從零建立客服團隊。當時公司突然有了數百名客戶，規模又不足以繼續請人，他才開始學網頁開發，希望透過程式解決客服與運營問題。 後來他成為專職網頁工程師，也替 Carrd 製作範本、協助客戶處理網站問題。Magic Pages 解決的痛點，剛好落在在客服、網頁開發與 Ghost 三個經驗的交叉點上。 隨著託管的網站從 30 個成長到 100、600，再到現在的 1,400 多個，他又被迫補上基礎設施的知識。Docker、Kubernetes、分散式儲存、CDN、Email 成功送達率，幾乎每一塊知識都來自實際運營遇到的問題。這種認知很難靠做一個 POC 專案就補齊。 #### **客戶從哪裡來？** Magic Pages 的獲客起點是 Twitter。 Jannis 在產品還沒有名字時就公開分享想法，最早的客戶來自他既有的人脈，以及曾經買過 Carrd 範本、接受過他幫助的人。第一輪客戶開始使用後，真正把產品推出去的是口碑行銷。到了 2023 年中，他發現客戶會主動向朋友推薦 Magic Pages，才意識到這可能不只是一個業餘專案。 現在他的主要獲客渠道依然圍繞著創辦人個人品牌、既有客戶與 Ghost 社群。他會在個人部落格公開寫基礎設施出包（post mortem）、成本變化與經營上的困難，也長期出現在 Ghost 論壇和 Reddit。當有人詢問 Ghost 託管服務時，往往是他的客戶主動跳出來推薦。 我自己就是被這種創辦人熱誠轉換成付費用戶的例子。過去我曾因為網站後台卡頓而聯絡 Ghost(Pro) 客服，正常情況要等2\~3天才會回，若剛好遇上員工放假，甚至有過七天以上才收到回覆。相較之下，我每次寄信給 Magic Pages，幾乎都由 Jannis 本人在 15 分鐘內回覆。對網站正在出問題的創作者來說，這種回應速度會直接影響對託管服務的信任。 #### **驗證花了多久？現在走到哪裡？** 如上面所述，Magic Pages 的市場驗證發生在產品完成以前。最初 15 份預售帶來約 US$3,500，支付了第一台伺服器與部分開發成本；從預售到第一批網站真正上線，大約隔了三個月。2024 年 2 月，他在終身方案之外加入月繳與年繳方案，七個月後達到 US$1,034 MRR。 這也是 Jannis 最後一次公開精確 MRR。2025 年 5 月，他只透露 Magic Pages 的收入已經持續高過自己的正職工作；截至 2026 年 8 月，官網則顯示超過 1,400 位創作者。由於客戶混合了月繳、年繳、終身方案、舊價格與多網站帳號，無法從網站數量推算目前 MRR。但從產品在三年內由一人業餘專案長成三人小團隊來看，它已經走過最初的商業驗證階段。 ## **回到我的選題困境** 研究完這三個案例，我也重新梳理了自己開發 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 的經驗。 跟 Takuya San 一樣，我當時就是 Peak Pals 最直接的使用者。從流程該怎麼設計，到哪些問題應該優先解，我一直都很清楚；產品上線後，我自己每天使用，搭配 beta users 持續提供回饋，feedback loop 很自然就建立了起來。這些 domain knowhow 原本就存在於我的生活裡，幾乎不需要另外取得。 真正卡住的是商業模式與 distribution。這部分我在 [Peak Pals V1 發佈心得](https://www.davehuang.io/peakpals/) 也有寫下省思。 這次的法規 RAG 剛好相反。我透過工程視角看見了解法，卻卡在無法有效進行 LLM Eval、缺乏情境資料，難以替結果背書。 其實在深入研究這三位獨立開發者以前，我曾經跟一位好友 [Marcus](https://blog.0xhhc.me/?ref=davehuang.io) 討論過，該怎麼補足自己缺少的 domain knowhow。 他提出了一個我沒有仔細想過的方向：如果缺的是領域知識，何不直接聘請領域專家，透過長期顧問或鐘點諮詢來補足？ 而且問題的規模可以調整。一個人能做的事情，跟一個團隊能做的事情肯定不同。如果目標是打造一個人能完成的產品，需要諮詢的範圍應該也不至於高到無法負擔。 反過來說，如果一間公司需要聘請大量領域專家，靠著許多不會寫在書上的經驗建立背景資料，那可能本來就不是一個人的範疇。即使我真的加入那間公司，這些知識門檻也不會因此消失。 聽完之後我才發現，自己原本的思緒把兩件事情混在一起了：一件是「我要怎麼取得 domain knowhow」，另一件是「這個問題到底適不適合獨立開發」。 我很認同聘請顧問可以幫我快速理解產業結構、既有 workflow、法規與常見問題，少走很多冤枉路。 但我比較沒把握的，是那些難以量化，卻足以深刻影響 product sense 的經驗。以及那些「未知的未知」。 那天我們沒有聊出一個明確的答案，不過 Marcus 確實幫我把原本混在一起的問題拆開了。從第一性原理去拆解問題本質，一直以來都是他的強項。也因為他提出這個方向，我才繼續往下研究，最後寫成這篇文章。 ### **工程與 Domain Knowhow 的不對稱** 研究這三人的過程中，我被提醒了一件事：Jesse 跟 Jannis 都曾將工程開發外包。 Jesse 找了 Andrew Culver 協助開發 Bento，自己是一邊看 code，一邊慢慢學會 Rails 與 React。 Jannis 早期也曾花錢請外部開發團隊協助客製 Email functionality。 但即便他們都外包過工程環節，他們都持續保持 hands-on，事情爆炸了自己都有辦法跳下去解決。他們這段從非工程背景一路走到 SaaS founder 的過程，帶給我很大的啟發。 但我也發現，他們選擇外包的工作都是「功能」問題或是「客服」——範圍明確，能夠定義與驗收。 就像現在為何 LLM 可以取代大量的 coding 實作一樣，工程師們對於定義 spec 最在行了，而 code 本身也是最容易被驗證的介質。 Domain knowhow 與商業邏輯就沒那麼容易定義與外包。 他們一直自己握著「什麼問題值得解、該服務誰、誰會願意付錢」的商業判斷。 AI 加速了軟體基底的建置，卻沒有能力提供 product sense。 這讓獨立開發者做產品的職涯路徑有機會反過來： > Non-tech Domain Expert → 借助 AI 與工程能力 → Domain-specific SaaS 對工程師來說，如果想進入一個完全陌生的領域，顧問也許可以幫忙補課。但要真的理解那個領域，長期環境的選擇 (exposure) 或 incentives 一致的夥伴，還是更務實的切入點。 ### **痛點背後的「在乎」** 回頭看這三人，我發現他們還有一個共同點：他們都由衷的高度在乎自己正在解的問題。 Jesse 過去經營行銷代理商，所以他很清楚 Email 工具不好用、信件進垃圾郵件，最後會怎麼傷害客戶的行銷成果與信任。 Takuya 每天都要寫 technical notes。只要工具不好用，就會持續磨損他日常的開發能量。 Jannis 原本做過 customer service。他在意創作者有沒有被技術問題卡住，也在意問題發生時，有沒有人願意接住他們，並且用對方聽得懂的語言協助解決問題。我自己也親身感受過 Jannis 的這一面。有好幾次，我都覺得自己的問題問得有點唐突，Jannis 還是很大方地回答了所有細節毫無保留。那種熱誠很難靠 SOP 模仿，也是我很欣賞、很嚮往的一種做產品的態度。 這幾位開發者都不是某天突然坐下來想著：「噢！我要開始找痛點囉～」再決定產品要往哪裡走。這些痛點原本就存在於他們的生活與工作裡。 因為在某個領域待得夠久，他們知道哪些地方真的麻煩，也看得出哪些摩擦力只是大家已經習慣了，但不代表無法被解決。當其中一個問題讓他們在意到想親手做出解決方案，產品就慢慢的「長」了出來，這過程是有機的。 當然，光是在乎還不夠。 持續交付的能力，以及有效的根據回饋持續修正與 pivot 也很重要。 ### **我想讓什麼開始複利** 寫到這，我開始思考另一個問題：接下來幾年，我想讓什麼開始複利？ 作為工程師，我很習慣累積 technical skills。LeetCode、system design、framework knowledge，都有相對清楚的學習路徑。投入多少時間、學會哪些東西、能不能通過面試或完成實作，通常也有明確的 feedback。 這些能力依然重要。我希望自己對工具的掌握一直維持在前緣，也持續磨練處理複雜問題的能力。但如果我想做出真正解決問題，也讓自己感到驕傲與滿意的產品，工程能力還需要搭配對使用者與 domain 的理解。 Peak Pals 的開發經驗讓我理解到，工程能力佐以 AI 可以把想法快速帶到 production，但產品該解決什麼、哪些功能應該優先，以及最後能不能真的幫助使用者，還是取決於我對問題的理解。 我想刻意累積的，是這種產品思維的複利（product sense）。 在一個問題空間裡待得夠久，久到知道哪些問題真的值得解、哪些需求只是噪音、客戶願意為什麼付錢，以及產品應該往哪裡長。 這些判斷很難透過讀書或短期衝刺補起來。它們藏在一次次與使用者互動、解決問題與修正假設的過程裡。對我來說，這些 domain knowhow、customer insight，都是做出好產品前很難取代的累積。 如果能在職涯上置身於自己真正在乎，且願意長期投入的 domain，依然是時間上最高效的配置。有著良好工程文化的團隊會讓工程師接觸客戶、參與問題定義，也能看見產品決策最後造成的結果。 Coding 已經能被 AI 加速。省下來的心力，我想拿去理解用戶、思考產品，再把這些理解轉回技術判斷。 工作以外的生活經驗、遇見的人、長期參與的社群，也會把我帶進其他問題裡。我未必需要刻意切出一個 time block 來「Explore domain knowhow」。 對我來說，當前能持續執行的，是留意那些反覆讓我覺得不對勁、甚至在乎到想親手解掉的麻煩。Technical skills 繼續累積，當真的遇到一個足夠在乎的問題時，我就有能力立刻動手驗證。