Linear 替代方案：當行銷與設計團隊不再被迫假裝自己是工程師

今年春天我們做用戶訪談時，反覆出現一個沒預期到的場景。一家 14 人 SaaS 公司的行銷主管帶著一點不好意思跟我們說：她最近一直在找一個「真的適合非工程團隊的 Linear 替代方案」，因為公司的工程團隊把整間公司搬上 Linear 之後，她每天的工作都被迫填成一張一張 issue，連 estimate 欄位都得隨便填一個 story point 才能存檔。那個月我們已經是第三次聽到類似的故事了。

公平地說，Linear 真的是個好產品。它在 2025 年 6 月跨過 1 億美元 ARR、以 12.5 億美元估值完成 8,200 萬美元 C 輪募資，客戶數超過 15,000 家、ARR 年成長超過 200%（TechCrunch, 2025 年 6 月）。它確實是這十年來最受工程團隊喜愛的 issue tracker。但 2026 年它快速成長中相當大一部分，是「工程同事把非工程團隊一起拉進去」帶來的——這就是縫隙開始浮現的地方。

Linear 的設計到底適合什麼？

Linear 是有「主見」的產品，這是它的優點。它的主見大致是：軟體開發的方式，是把事情拆成一張張 issue，集中放進每 1～2 週一個的 cycle，新進來的需求先進 triage 等人決定要不要做，然後紀律地交付。鍵盤快捷鍵、流暢的介面、清晰的視覺層級，全部都在服務這個觀點。

對工程團隊來說，這套模型剛好就是工作的形狀。一張 issue 對應一段程式碼變更；cycle 對應一個 sprint；triage 對應外部進來的 bug 與需求清單，需要有人先過濾才丟給團隊；估點 (story points) 對應「這件事大概多大」。當工作就是寫軟體出貨，Linear 裡的每個基本元件都很值得。

問題在於：這些基本元件對「非寫軟體」的工作，其實對應不上。一份行銷活動 brief 不是 issue。一場設計評審不是 triage 事件。每週看 marketing initiatives 跑得怎麼樣，也不是 cycle 回顧。當工作硬被塞進這些容器，症狀就會慢慢累積——你的非工程團隊花在「把工作翻譯成 Linear 的形狀」的時間，比真的做事的時間還多。

行銷與設計同事一看就懂的症狀

跟夠多非工程的 Linear 使用者聊過之後，會看到一張幾乎重複的抱怨清單。每一條都不算戲劇化，但加起來就成立。

被迫填 story point 才能存檔。 行銷不是用點數思考的。問他們「重做訂價頁面要幾點」，他們會挑一個感覺合理的數字、然後不再去想。資料毫無意義，整個團隊也心知肚明。
明明是 Figma comment，卻得開一張 issue。 設計師想留一句「按鈕顏色要再深一階」，在 Linear 裡的「正確位置」是新開一張 issue，配標題、狀態、被指派人。結果這條 comment 不是不寫了，就是悄悄寫在自己的 Notion 裡。
把 cycle 開成週會檢討會。 工程團隊用 cycle 是真心要交付紀律。行銷團隊照搬之後，常常變成一場帶著歉意的週會：30% 的工作根本塞不進這個禮拜的 cycle，只能愧疚地拉到下一週。
工作藏在私人文件裡。 這是最深的症狀。當 workspace 跟工作形狀不合，人就不會把工作放進 workspace。看上去 Linear 看板很乾淨，真正在進行中的工作則在 Notion、Slack 私訊和 Google Docs。工程同事還以為導入很順利。

許多 Linear 比較文章引用過的一份 2024 年 Product Management Institute 調查指出：跨職能團隊以 Linear 為主要工具時，只有約 26% 滿意；純工程團隊則有 83%（Growth Method, 2026）。這個落差不是 UX bug，是產品照原本設計運作，只是被丟到不適合的工作上。

公平地說：Linear 真正做得好的地方

光講缺點不公平，分析也會失準。Linear 的強項是真的，而且正是這些強項讓「拉非工程團隊一起用」更不舒服。

鍵盤優先的速度。 重度使用者操作 Linear 的速度，市面上沒有對手。對已經住在鍵盤上的工程師，這是純粹的生活品質升級。
有立場的 Issue 階層。 Project → Issue → Sub-issue，狀態模型乾淨，沒有 14 層巢狀，也沒有無限自訂欄位。形狀被限制住，這是優點。
強制執行的 cycle 紀律。 Cycle 不是選配，它每週／每兩週準時開始與結束，沒做完的自動帶到下一輪。對工程團隊來說，這個被強制的節奏正是他們需要的。
Triage 是個一級公民。 一個共用收件匣，所有新進來的 issue 先在這裡被看過、再決定丟到哪個團隊。對輸入來源很多的工程組織（客服轉來的 bug、客戶請求、內部點子），triage 是真的有用。

誠實的結論是：每一個強項，當你把工具推給行銷、設計、營運、HR 時，都會反過來變成阻力。鍵盤速度假設你願意花一小時練到能用；強制 issue 階層假設工作真的是 issue；cycle 假設 sprint 是對的節奏；triage 假設進來的工作技術性夠高、需要工程角色去過濾。

一個簡單的判斷規則

如果你只想從這篇文章帶走一件事，請帶走這個經驗法則。它是我們找到最乾淨、用來判斷「Linear 該全公司導入還是只給工程團隊用」的測試。

如果整間公司就是在出貨軟體，Linear 全公司用沒問題。如果你公司一半以上的 workspace 是非工程團隊在裝成工程團隊，就該把它們搬出去（或同時跑第二個工具）。

第一種情況很單純。一個 12 人的種子期新創，所有人都在出產品——工程師、寫文案的創辦人、設計師、外包負責的營運——這種公司完全可以全公司跑 Linear。工作就是軟體，模型剛好對得上。

第二種情況是大多數成長中團隊在 15 到 40 人之間會撞到的。行銷有自己的季度活動，設計在做客戶評審，營運在跑 onboarding playbook，業務在追 pipeline。多數的 workspace 已經不是軟體 workspace 了。這時候只剩兩條路：要嘛接受好幾個團隊每天在一個跟自己對著幹的工具裡工作，要嘛把他們搬到一個跟工作形狀真的吻合的工具。

通常正確的做法不是把 Linear 從工程師手上搶走。他們愛它、在裡面有效率、搬遷成本是真的。正確的做法是：不要因為工程團隊先到，就硬把每個團隊塞進同一個工具。

「搬出去（或同時跑第二個工具）」實際長什麼樣？

很多公司在這一步會踩到另一個陷阱：直接跳到最重的那種替代品——整間公司全面導入 ClickUp 或 Monday，配上自訂欄位、自動化、儀表板、和每季一場「工具管理員會議」。這只是另一種不快樂。鐘擺從「太工程化」盪到「太可組裝」，代價一樣高。

可以這樣想：多數非工程團隊需要的是比 Linear 更少的主見，不是更多。 他們要的是一張任務：標題、被指派人、到期日、狀態、留言串。看板或清單兩種檢視。不要思考 cycle、estimate、triage。工具在不被使用時應該安靜消失。

三個方向：

單純的固定費率工具（例如 Heimin），資料模型就是一張任務和它的基本欄位，整團一個月一個固定價格、沒有人頭數學。當團隊真的就只是想記任務、又受夠了 per-seat 帳單時往這邊看。
Asana，當行銷形狀的工作比較重——視覺化時間軸、portfolio rollup、內容行事曆。比 Heimin 重，但對非工程團隊來說比 Linear 自然。
Notion 當文件 / wiki 是主要產出，任務只是次要視角時。我們在另一篇從 per-seat 定價的角度寫過這個方向的限制——2026 年它把 AI 綁進 Business 方案後，價格門檻明顯被往上推了。

你也不一定得整間公司挑一套。2026 年對許多混合團隊最誠實的答案是：工程留在 Linear，公司其他部門搬到一個跟工作形狀吻合的工具，兩邊靠少量、明確的整合彼此講話。

Heimin 的位置（誠實版本）

Heimin 是刻意比 Linear 慢、比 Linear 沒那麼有主見的工具。沒有 cycle，沒有 triage 功能，沒有 estimation point。一張任務——標題、被指派人、狀態、到期日、描述、留言——表面積就到這裡。整個團隊每月固定 12 美元，沒有人頭數學。

這不是包裝成分析的銷售話術。這是一個不同的觀點：Linear 賭的是「有主見、快、工程形狀」是產品的核心。Heimin 賭的是「對行銷、設計、營運和大量小團隊而言，沒主見、簡單、形狀中性」才是產品的核心。我們不是在嘗試做一個更好的 Linear 給工程師用，我們是在嘗試成為那「另一半」非工程團隊真正適合的答案——他們現在每天都在把自己的工作翻譯成 Linear 的形狀。

如果你的工程團隊愛 Linear，請放過他們。如果你的行銷主管正在隨便填 story point 才能存檔，那是個真實的問題，而修法只要五分鐘。

決定前的實務 checklist

盤點誰在 Linear 裡做什麼。 把 workspace 列出來，標註工程 vs 非工程。如果非工程超過一半，工具已經跟公司形狀脫節。
找非工程主管做 5 分鐘症狀檢查。 他們在隨便填 story point 嗎？把不是 issue 的東西當 issue 開嗎？把工作藏在私人文件裡嗎？一個「是」是黃燈，兩個就是判決。
不要把 Linear 從工程手上搶走。 它對他們是值得的。對它不適合的團隊，跑第二個工具就好。
挑替代品看「形狀」，不看「功能多寡」。 一個對得上工作形狀的簡單工具，永遠贏一個對不上的強大工具。
預先算 seat 帳單。 如果替代品是 per-seat，請用「現有人數 × 1.5」算月費。如果那個數字會讓你皺眉，去看固定費率的選項。

正確答案不是「Linear 不好」——Linear 很優秀。正確答案是：不要再裝行銷團隊是工程團隊了。 那層假裝的成本，藏在 Linear 上低落的活躍度、藏在私人文件裡的工作，以及團隊之間對「workspace 顯示的東西到底等不等於現況」逐漸流失的信任裡。