產品路線圖規劃：5 個階段、3 個時間範圍與一份範本

最後更新：2026 年 9 月 15 日

路線圖在完成的那個早上是準確的。到了發布週期的第二週，一個功能悄悄膨脹成兩倍大，另外兩個卡在一個沒有人寫下來的決定上等待，但投影片依然顯示這五項會整整齊齊地同時抵達。

沒有人說謊。只是那份簡報根本沒有辦法得知有任何東西改變了。

好的產品路線圖規劃，不是把簡報做得更漂亮。它是把計畫和實際工作之間的落差縮小，讓計畫能和其他人一樣，在事情發生的當下就跟著學到新資訊。以下是這道落差藏身的五個階段、如何誠實地進行排序的論證，以及一個可以直接借用架構的 Quire 專案。

什麼是產品路線圖規劃？

產品路線圖規劃是決定你的產品要出貨什麼、大致按什麼順序出貨，然後讓這個順序持續連結到交付它的任務上。 前半部分是關於價值的論證。後半部分是管線工程，而正是這後半部分決定了六週之後這個論證是否還有意義。

大多數建議都停在前半部分。你會得到優先順序框架、利害關係人範本、關於主題 vs. 功能的辯論。這些都有用，但都沒有觸及真正會出問題的地方。

為什麼產品路線圖會逐漸偏離現實？

路線圖之所以走偏，是因為它和它所描述的工作被分開存放。 兩份成品，一個真相，卻沒有機制讓它們保持一致。所以它們大概只能維持一致一個星期左右。

這道落差具體造成了三種代價。

它讓誠實的答案消失。 有人問接下來會出什麼，而知道答案的人得去問五個人、把回覆重新拼成一張投影片。等到簡報呈現出來時，內容其實描述的是上週四的狀態。

它讓決策軌跡消失。 一項功能延期，路線圖顯示新的日期，但沒有任何紀錄說明是誰決定的、又犧牲了什麼才騰出空間。

它讓預測失準。 Kevin Thomas 與 Cornelius König 在 Frontiers in Psychology 發表的研究發現，當任務與估計者過去已完成的任務相似時，工期預測會更接近真實情況。

你自己過往出貨的紀錄，是你手上最好的估算工具。一個在發布結束那一刻就把這些紀錄封存起來的路線圖，等於每一季都白白丟棄這項資產。

我們曾經有一段時間用試算表來管理 Quire 的發布流程。它一直運作良好，直到有一週，有人問了一個它沒辦法不開會就回答的問題。

這個問題中「回報」的那一半，另有解方：不用開狀態會議也能更新利害關係人介紹了那種從工作本身而非從某人的記憶中產生報告的非同步做法。

從構想到出貨，中間會經過哪五個階段？

一項功能會依序經過 intake（收件）、triage（分流）、scoping（界定範圍）、build（開發）和 ship（出貨），而傳統路線圖通常只顯示最後兩個階段。 這樣足夠畫出一張圖表，卻遠遠不足以解釋整個季度發生了什麼，因為真正有意思的事都發生在那三個不留任何痕跡的階段裡。

以下是功能實際會停留的五個位置，以及某個階段被跳過而非確實走過時，最終要付出的代價。每個階段下方都標出它在 Quire 產品路線圖範本中的所在位置，本文稍後會完整展開這份範本。

• 1. Intake（收件） 位於 Idea intake 區段。跳過這一步，需求就會停留在私訊裡，六個月後以抱怨的形式回歸。
• 2. Triage（分流） 最終走向 Later，或者直接關閉。跳過這一步，清單會越滾越大直到沒有人再信任它，於是每個人都悄悄自己維護一份私人清單。
• 3. Scoped（界定範圍） 位於 Next，狀態為 Scoped。跳過這一步，工程團隊打開工單時，就得在自己那一週承接你延後做的決定。
• 4. Build（開發） 位於 Now，附帶子任務。跳過這層巢狀結構，一整列不透明的工作可能連續兩週都顯示「完成八成」，卻沒有人說得出原因。
• 5. Ship（出貨） 依循 Ship checklist 子清單運作。跳過這一步，客戶會在客服團隊還不知道這個功能存在之前就先遇到它。

留意哪些階段會留下痕跡。只有最後兩個階段會出現在傳統路線圖上；前三個階段發生在收件匣和走廊對話裡，這也是為什麼圖表看起來總是比實際那一季平靜得多。

產品路線圖和待辦清單（backlog）有什麼差別？

待辦清單是你可能會做的所有事，沒有承諾的順序。路線圖則是你已經承諾要做的一小部分，並附上大概的時間點。 團隊常犯的錯誤，是只維護一份清單卻把它同時當成兩者，這樣一來清單裡的每個構想讀起來都像一項承諾。

把它們放在同一個專案裡，但分屬不同區段。相同的任務、相同的欄位，意義卻不同。

由此帶來的實用結果是，晉升會變成一個明確事件。把一項任務從 Later 移到 Next，是某人在某一天做出的決定，而不是一列在沒人注意時悄悄往上漂移的資料。

關於如何讓那份候選清單保持有用而不淪為墳場：讓你的產品待辦清單完整說出故事。

Quire 的產品路線圖範本裡有什麼？

它是一個已經內建五個階段的實際運作專案，任何方案都能免費複製。 範例資料是一個虛構的 v2.0 發布版本，所以你可以先看到這套架構如何運作，再把它換成你自己的內容。

與其從空白專案開始建立，不如直接使用 Quire 的產品路線圖範本。它附帶八項內容：

• 三個時間範圍區段，再加一個收件區段。 Now 是附有真實日期的目前發布版本，Next 是以輪廓呈現的下一版本，Later 是沒有日期的候選項目，而 Idea intake 則是尚未分流的需求，其中沒有任何一項是承諾。
• 五步驟狀態流程：Idea、Scoped、In Progress、In Review、Shipped。Scoped 是刻意設計的，因為「尚未開始」和「沒有人決定過這是什麼」是兩個完全不同的問題。
• 六個路線圖欄位：Release、Impact、Effort、Customer requests、Source，以及一個 Needs release note 核取方塊。
• 展開後即是實際工作的功能項目。 Notifications center 不是單一一項待辦事項，而是規格、設計、面板開發、靜音設定和摘要郵件，每一項都有負責人和日期。
• 以專案里程碑呈現的發布關卡：feature freeze、code freeze 和 GA，以相依關係串接，讓它們必須依循的先後順序清楚可見。
• 三個橫跨整棵樹的子清單：目前的發布版本、承諾給指名客戶的一切，以及出貨檢查清單。
• 一份「我們如何排定優先順序」文件，把評分準則一次寫清楚，讓你不必每次意見不合時都重新爭論方法本身。
• 兩個報告分頁：供每週檢視用的儀表板，以及 Effort by owner，它會加總每個人預估的工時，讓你能判斷這次發布的工作量是否符合負責的人力。

巢狀結構正是讓功能不再連續兩週停留在「完成八成」的關鍵。當 Notifications center 拆成五個各有負責人的子任務時，「完成八成」就變成了「摘要郵件還沒開始，負責的人是 Ana」。

即使你不打算動用範本的其他部分，也值得直接拿走這份出貨檢查清單。七個問題，各自有指名負責人，而且 GA 專案里程碑必須等到全部回答完畢才能結案：

1. 這次發布中的每個功能都已 Shipped，或明確被剔除並移到下一版本。
2. 針對每個勾選了 Needs release note 的項目，發布說明都已撰寫完成。
3. 每個有變動的介面，文件與 API 參考手冊都已更新。
4. 客服團隊已收到簡報：已知問題、應對方法、何時該升級處理。
5. 遷移流程已在正式環境資料的副本上測試過，回滾方案也已經演練過。
6. 功能開關已針對啟用族群設定完成，預設值也已確認。
7. 狀態頁面公告與應用內更新日誌已排定在發布時刻發布。

第五項寫的是「已演練」，不是「已寫成文件」。一份沒有人實際跑過的回滾方案，只是一個附了檔名的願望。

Duplicate 是針對整個專案執行的，所以整棵樹會完整帶過來，而不是一項任務一項任務地複製。從範本標題旁的下拉選單中，展開 More，選擇 Duplicate。

給複製出來的專案取個名字，選擇它要歸屬的組織，然後點擊 Create。大約一分鐘，所有層級的巢狀結構都會一併複製過來，這也是「複製」勝過「重新建立」的唯一原因。

接著要對它下狠手。架構本身才是真正有用的部分；範例功能只是鷹架，每留下一項沒刪掉,你到了十一月就會隱隱感到一絲愧疚。

如何決定下一個發布版本要包含什麼？

把價值拿來對比成本，並讓兩者的證據都攤在螢幕上，而不是把它們混合掉。 優先順序判斷之所以常常出錯，方式相當固定：有人建立一個評分公式，公式算出 7.4 分，然後大家對著這個數字點頭，卻沒發現它其實悄悄掩蓋了本該解決的分歧，而不是真的解決了它。

把輸入項目分開並保持可見。在範本中，這代表每個候選項目都有三個欄位：

• Impact（影響力），代表它的價值高低，分為 High、Medium 或 Low。
• Effort（工作量），以大略的 S 到 XL 表示。
• Customer requests（客戶需求數），統計實際有多少人提出過需求。

依 Impact 排序，同時檢視旁邊的 Effort，讓需求數字避免讓聲音最大的人成為唯一的輸入來源。

接著要留意那個幾乎每個團隊都會踩到的落差。在範例資料中，Dark mode 上線時有 47 個客戶需求，但 Impact 卻是 Low。

這依然是個合理的決定，因為它成本低、又解決了一個反覆出現的抱怨，但沒有人應該假裝這是一場成長賭注。清單上最多人要求的東西，往往不是最有價值的東西，而單一混合分數正是最容易掩蓋這一點的工具。

這就是表格檢視模式：相同的任務、六個可排序的欄位，什麼都不需要匯出。

在任何項目進入 Now 之前，先做三項測試。它是否已經 Scoped？它是否會在 code freeze 之前完成，而不是拖到 GA 那一週？它是否有一位指名負責人，而不是一整個團隊？一個擁擠的 Now，等同於根本沒有 Now。

說「不」是另一半功夫，而讓某項東西永遠停留在 Idea，其實就是一種沒有人願意說出口的「不」。把它們移到 Later 並附上一行原因，或者直接關閉。例外是 Customer-committed 子清單：任何有人向指名客戶承諾過的項目都放在這裡，所以要拿掉它就會變成一場對話，而不是深夜十一點的一次悄悄編輯。

拿你們團隊最常爭論的十個候選項目來試試看。在一個免費的 Quire 專案中為它們評分 Impact 和 Effort，然後排序。通常十個裡有八個會自然而然定案，會議就會縮小到剩下那兩個真正該爭論的項目。

如何直接從路線圖本身回答「接下來會出什麼、什麼時候出」？

你可以直接從時間範圍、專案里程碑和狀態讀出答案，因為這三者本來就是由正在做這些工作的人持續維護著的。 這正是那份簡報原本存在的目的，也是它總是變得過時的原因。

時間範圍回答的是大致何時。 Now 有日期，因為工作已經界定範圍並指派了負責人。Next 有發布版本但沒有精確到天的細節。Later 兩者都沒有，這是刻意的設計。為了看起來井然有序而給 Later 加上日期，等於憑空取得了一項你從未同意過的承諾。

專案里程碑回答的是必須先成立哪些條件。 Feature freeze、code freeze 和 GA 是時間軸上真實存在、彼此有相依關係的物件，而不是寫在文件裡的句子。當一項功能延遲超過 freeze 時間，時間軸會顯示它撞上了什麼。

狀態回答的是現在正在發生什麼。 In Review 和 In Progress 看起來不一樣，In Progress 又和 Idea 不一樣。工程師更改狀態，作為完成自己工作的附帶結果，也順便更新了路線圖，而這正是唯一能持續保持最新的回報方式。

儀表板為那些永遠不會打開路線圖的人回答這個問題。 這裡有兩個特別值得的元件。

Tasks Created vs. Completed 對比工作進來的速度和離開的速度。這是最早、也最誠實的訊號，能看出一次發布是在膨脹，還是在正常推進。

受阻任務把每個卡住的項目和阻礙它的原因配對呈現，於是任何路線圖檢討會議上的固定問題，都已經提前有了答案。

範本中每個已出貨的功能，也都記錄了當初的估算與實際花費的對比。這個模式正符合前述研究的預測：與團隊過去做過的東西相似的工作，估算會很準；而真正全新的工作，往往超支達三分之一。

背後有兩個機制值得單獨閱讀：Quire 中專案里程碑的運作方式與任務相依關係如何串連工作，正是這套機制讓延遲的 freeze 變得可見，而不只是理論上的存在。

產品路線圖規劃應該放進你的任務管理軟體嗎？

是的，而判斷標準就是：當工程師關閉一張工單時，路線圖會不會在沒有人要求的情況下自動更新。 如果答案是不會，那你就同時維護著兩份文件，還養成了一個你最終會放棄的每週對帳習慣。

投影片軟體和專門的路線圖工具都能產出一張漂亮的畫面。但兩者都無法告訴你面板開發延遲了，因為兩者都沒有真正掌握面板開發本身。把路線圖放進團隊已經在使用的同一套任務管理軟體，就能消除這份副本，也一併消除了落差。

如果你還在挑選這套工具，這篇文章帶你走過整個領域：最好的任務管理軟體與任務追蹤工具，比較它們如何處理巢狀工作。

有一種情況這套架構並不適用，值得說清楚。一個還在摸索產品該長什麼樣的團隊，手上只有候選項目，沒有確定的發布版本。開一個 Now 時間範圍並在上面填上日期，等於憑空捏造出一個沒人真正做過的承諾。

只運作 Later 和 Idea intake，直到真的有東西被界定範圍並指派負責人，那一週再開啟 Now。時間範圍存在的目的是承載承諾，不是為了看起來滿滿的。

這份範本只是一系列範本中的一個。其他範本收錄在團隊真正會用到的專案管理範本總覽中，包括發布、狀態回報和風險用的範本。

複製這份範本後，最先該改動什麼？

先從日期開始，因為所有東西都掛在日期上。 重新命名各個發布版本，把三個關卡拖曳到你的日期上。

接著把範例功能換成真實的功能，每一項都指派給一個人，而不是一整個小組。

最後,把你私底下確定永遠不會被開發的項目全部刪掉。路線圖只有在上面每一列都仍然屬實的時候，才會持續有用。

重點整理

路線圖之所以過時，是因為它存在於工作觸及不到的地方。讓每一列都對應到一項真實任務，落差大多就會停止擴大。

這代表用五個階段取代「計畫中」和「完成」兩種狀態、用三個時間範圍取代憑空捏造的日期、用附帶相依關係的專案里程碑作為發布關卡，以及讓優先順序欄位展示證據，而不是把證據藏進一個分數裡。

這一切都不需要從零開始建立。直接複製一份產品路線圖範本，為你的候選項目評分，讓 Now 保持精簡，架構本身就已經在替你做事了。

註冊新帳號，在任務原本所在的地方運作它，這樣下次有人問接下來會出什麼時，答案就會是一個連結，而不是一整晚的加班。

常見問題

什麼是產品路線圖規劃？

決定要出貨什麼、大致按什麼順序出貨，並且能展示每項承諾背後的實際工作。在 Quire 的產品路線圖範本中，每一列都是一項真實任務，有負責人、有發布版本、底下巢狀著實際工作，所以計畫和執行不會悄悄地各說各話。

產品路線圖和待辦清單有什麼差別？

待辦清單是你可能會做的所有事。路線圖是你已經承諾要做的部分，並附上大概的時間點。範本把兩者放在同一個專案裡，但分屬不同區段。

產品路線圖應該規劃多遠的未來？

目前這個發布版本給真實日期，下一個版本給一個輪廓，再更之後的就完全不給日期。這正是 Now、Next 和 Later 存在的目的，因為為了填滿投影片而捏造的日期，之後就會變成你必須兌現的承諾。

如何為產品路線圖排定優先順序？

把價值拿來對比成本，並讓兩邊都有證據可查。Quire 的範本把 Impact、Effort 和 Customer requests 做成表格檢視模式中可排序的欄位，刻意不混合成單一分數，因為一個數字會掩蓋掉真正值得討論的分歧。

路線圖應該放在和實際工作相同的工具裡嗎？

是的，否則你就得維護兩份真相並手動對帳。把它放進工程師已經在使用的任務管理軟體，這樣狀態一改變，路線圖就會自動更新，不需要任何人碰第二份文件。

這種路線圖架構在什麼情況下不適用？

當還沒有真正確定任何事情的時候。一個還在摸索產品樣貌的團隊手上只有候選項目，沒有發布版本，這時開一個附帶日期的 Now 時間範圍，等於憑空捏造出一個承諾。這種情況下只運作 Later 和 Idea intake，直到有東西被界定範圍並指派負責人為止。

用這種方式規劃路線圖，如何幫助團隊在工作上更有生產力？

它拿掉了整層回報工作：不用每週重做投影片，不用在利害關係人會議前追著六個人問，也不用重複問「到底決定了什麼」。當路線圖、發布關卡和實際工作都放在同一個 Quire 專案裡，那些原本用來說明工作的時間，就能改花在推進工作本身。