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

最後更新：2026年9月15日

路線圖在製作出來的那個早上是準確的。到了發布週期的第二週,有一個功能悄悄地規模翻倍,另外兩個卡在一個沒有人寫下來的決定上等待,而投影片上依然整齊地顯示所有五項會同時到位。

沒有人說謊。只是那張投影片根本沒有辦法得知有任何事情變了。

好的產品路線圖規劃,不是做一張更好的投影片。而是縮小計畫和實際工作之間的落差,讓計畫能在其他人都知道的同時,也跟著學到新資訊。以下是這個落差藏身的五個階段、如何誠實地進行排序的討論,以及一個可以直接借用結構的實際運作中的 Quire 專案。

什麼是產品路線圖規劃?

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

大多數建議都只停在前半部分。你會得到優先排序框架、利害關係人範本、關於主題與功能之爭的討論。這些都有用,但沒有一個觸及真正會出問題的地方。

為什麼產品路線圖會漸漸和現實脫節?

路線圖會失準,是因為它和它所描述的工作分開儲存。 兩份產物,一個真相,卻沒有機制讓兩者保持一致。所以它們大概只能一致維持一週左右。

這個落差要付出三種具體的代價。

它讓誠實的答案付出代價。 有人問接下來會出什麼,知道答案的人得去問五個人,再從回覆中重新拼湊出一張投影片。等到報告出來時,描述的已經是上週四的狀況。

它讓決策軌跡付出代價。 一個功能延遲了,路線圖顯示新的日期,卻沒有任何記錄說明是誰做的決定,或是為了騰出空間放棄了什麼。

它讓預測付出代價。 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(出貨) 依靠「出貨檢查清單」子清單運作。跳過它,客戶會在支援團隊還不知道這個功能存在之前,就先遇到它。

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

產品路線圖和產品待辦清單有什麼分別?

待辦清單是你可能會做的所有事情,沒有承諾的順序。路線圖則是你已經承諾要做的一小部分,附有大致的時間點。 團隊常常因為只維護一份清單、卻把它同時當成兩者而陷入麻煩,因為這樣一來,清單裡的每個構想讀起來都像是一個承諾。

把兩者放在同一個專案裡,但分屬不同區段。同樣的任務、同樣的欄位,意義卻不同。

這樣做帶來的實際好處,是「升級」變成了一個明確的事件。把一項任務從 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(來源),以及一個「需要發布說明」的核取方塊。
• 展開成實際工作的功能。 通知中心不是單一一項待辦事項。它包含規格、設計、面板開發、靜音設定和摘要郵件,每一項都有負責人和日期。
• 作為專案里程碑的發布關卡:功能凍結、程式碼凍結和 GA,以相依關係串聯起來,讓它們必須發生的順序清楚可見。
• 三個橫跨整棵樹的子清單:目前的發布版本、承諾給特定客戶的所有項目,以及出貨檢查清單。
• 一份「我們如何排定優先順序」文件,把評判準則一次寫清楚,讓你不用每次對某個項目有分歧時,都要重新爭論方法本身。
• 兩個報告分頁:一個供每週檢視的儀表板,以及「各負責人的工作量」,加總每人估計的工時,讓你能問這個發布版本是否配得上手上的人力。

嵌套結構,正是讓一個功能不會連續兩週都顯示「完成八成」的原因。當「通知中心」變成五個有負責人的子任務時,「完成八成」就會變成「摘要郵件還沒開始,而 Ana 正在處理」。

無論你是否打算動用範本其餘的部分,都值得直接借用這份出貨檢查清單。七個問題,每一項都對應一個負責人的名字,而且在全部回答完之前,GA 這個專案里程碑不會關閉:

1. 這次發布中的每個功能都已 Shipped,或明確被砍掉並移到下一版。
2. 所有勾選了「需要發布說明」的項目,都已寫好發布說明。
3. 每個有變動的介面,文件和 API 參考都已更新。
4. 支援團隊已被告知:已知問題、應對方式、何時該升級處理。
5. 遷移已在生產資料的副本上測試過,回滾方案也已經演練過。
6. 功能旗標已針對啟動族群設好,預設值也已確認。
7. 狀態頁公告和應用內更新日誌,都已排定在發布時刻發出。

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

複製會作用在整個專案上,所以整棵任務樹會完整帶過來,而不是一次只搬一個任務。從範本標題旁的下拉選單,展開 More,選擇 Duplicate。

給複製出來的專案取個名字,選擇它要歸屬的組織,再按下 Create。大約一分鐘,每一層嵌套結構都會一起帶過來,這也是複製勝過從頭重建的唯一原因。

然後對它下狠手。結構才是有用的部分;範例功能只是鷹架,你留下的每一個,到了十一月都會變成一件讓你隱隱有罪惡感的事。

如何決定下一個發布版本要放進什麼?

比較價值和成本,並讓兩者的證據都留在螢幕上,而不是把它們混合起來消失不見。 優先排序常以一種可預測的方式出錯:有人設計出一個評分公式,公式算出 7.4,於是每個人都對這個數字點頭,而它其實已經悄悄埋葬了本該解決的分歧,而不是真正解決它。

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

• Impact(影響力):代表它的價值,分為 High、Medium 或 Low。
• Effort(工作量):以大致的 S 到 XL 表示。
• Customer requests(客戶要求數):實際提出要求的人數。

按 Impact 排序,對照旁邊的 Effort 一起看,並讓要求數來防止聲音最大的人成為唯一的輸入依據。

接著留意每個人都會踩到的那個落差。在範例資料中,「深色模式」上線時有 47 個客戶要求,但 Impact 卻是 Low。

這仍然是一個合理的決定,因為它成本低,又解決了一個反覆出現的抱怨,但沒有人應該假裝這是一次成長賭注。清單上最多人要求的東西,往往不是最有價值的東西,而一個單一的綜合分數,正是最會把這一點藏起來的工具。

這就是表格檢視模式:同樣的任務,六個可排序的欄位,不需要匯出任何東西。

在任何項目進入 Now 之前,有三個測試。它是 Scoped 嗎?它會在程式碼凍結前完成,而不是拖到 GA 那一週?它有一個具名的負責人,而不是一整個團隊?一個擁擠的 Now,和沒有 Now 是一樣的。

說「不」是另一半的工作,而讓事情永遠留在 Idea 裡,其實就是一種沒有人願意說出口的「不」。把它們移到 Later 並附上一句話的理由,或是直接關閉它們。例外是 Customer-committed 子清單:任何有真人向特定客戶承諾過的項目,都放在那裡,所以把它拿掉,就會變成一場對話,而不是晚上十一點悄悄的一次編輯。

拿你的團隊最常爭論的十個候選項目試試看。在一個免費的 Quire 專案裡為它們評分 Impact 和 Effort,然後排序。通常十個裡有八個會自己得到答案,會議就會縮小到那兩個原本就是真正的爭論焦點。

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

你直接從時間範圍、專案里程碑和狀態裡讀出答案,因為這三者都已經由正在做各自本職工作的人持續維護著。 這正是那份投影片一直想回答、卻總是很快變得過時的問題。

時間範圍回答的是大致的「什麼時候」。 Now 有日期,因為工作已經界定範圍並有負責人。Next 有發布版本,但沒有精確到日的細節。Later 兩者都沒有,而這是刻意的。為了看起來井然有序而給 Later 一個日期,就是你在無意間攬下一個你從未同意過的承諾的方式。

專案里程碑回答的是「必須先滿足什麼條件」。 功能凍結、程式碼凍結和 GA,是時間軸上真實存在、彼此有相依關係的物件,而不是寫在文件裡的句子。當一個功能延遲超過凍結期限,時間軸會直接顯示它撞上了什麼。

狀態回答的是「現在正在發生什麼」。 In Review 和 In Progress 看起來不一樣,In Progress 和 Idea 看起來也不一樣。工程師變更狀態,就會作為做本職工作的副產品,順帶更新路線圖,而這正是唯一能持續保持最新狀態的回報方式。

儀表板回答的,是給那些永遠不會打開路線圖的人看的。 這裡有兩個小工具特別值得擁有一席之地。

「已建立 vs. 已完成任務」設定了工作進來的速度和離開的速度之間的比對。這是發布版本正在膨脹、而不是正在推進的最早的誠實訊號。

「受阻任務」把每一個卡住的項目,和正在卡住它的原因配對在一起,讓任何路線圖檢視會議中那個常見的問題,提前就有了答案。

範本中每個已出貨的功能,也都記錄了當初估計的工時與實際花費的工時。呈現的模式正如上述研究所預測:與團隊過去做過的東西相似的工作,估算得很準,而真正全新的工作則超出了大約三分之一。

底下有兩個機制值得單獨閱讀:Quire 的專案里程碑如何運作,以及 任務相依關係如何把工作串聯在一起,這正是讓一次延遲的凍結變得可見、而不只是理論上存在的原因。

產品路線圖規劃應該放在你的任務管理軟體裡嗎?

應該,而檢驗方式是:工程師結案一張工單時,路線圖會不會在沒有人要求的情況下自動更新。 如果答案是不會,你就等於維護著兩份文件,以及一個你終究會停止執行的每週對照習慣。

投影片軟體和專門的路線圖工具,都能產出一張乾淨的圖片。但兩者都無法告訴你面板開發已經延遲了,因為兩者都沒有握有面板開發本身。把路線圖放進團隊已經在使用的同一套任務管理軟體裡,能去掉那份副本,也就一併去掉了失準的可能。

如果你還在挑選那個工具,這篇文章會帶你走一遍整個領域:最好的任務管理軟體與任務追蹤工具,比較它們如何處理嵌套工作。

有一種情況下,這種結構是錯的形狀,值得明說。一個還在摸索產品應該是什麼樣子的團隊,只有候選項目,而沒有確定的發布版本。這時如果打開一個 Now 時間範圍,並在上面標上日期,就是在捏造一個沒有人做過的承諾。

在真正有東西被界定範圍並指派負責人之前,只運作 Later 和 Idea intake,等到那一週再開啟 Now。時間範圍的存在,是為了容納承諾,而不是為了看起來很滿。

這份範本只是一整套範本中的一個。其餘的都收錄在 你的團隊真的會用的專案管理範本 這篇整理文章裡,包括發布、狀態回報和風險管理用的範本。

複製之後,你應該先改什麼?

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

接著,把範例功能換成真實的功能,每一項都對應一個真人,而不是一整個小組。

最後,砍掉任何你私下確信永遠不會被做出來的東西。一份路線圖只有在上面每一列都仍然為真時,才會保持有用。

重點整理

路線圖之所以會過時,是因為它存放在工作觸及不到的地方。把每一列都變成真正的任務,失準的情況大致就會停止。

這代表要用五個階段取代「規劃中」和「完成」這種二分法,用三個時間範圍取代憑空捏造的日期,用帶有相依關係的專案里程碑作為發布關卡,以及展示證據、而不是把證據藏進一個分數裡的優先排序欄位。

這一切都不需要從零開始搭建。拿一份 產品路線圖範本 的副本,為你的候選項目評分,讓 Now 保持精簡,結構本身就已經在為你做這些工作了。

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

常見問題

什麼是產品路線圖規劃?

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

產品路線圖和待辦清單有什麼分別?

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

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

目前發布版本用真實日期,下一個版本給個大致輪廓,再往後的一律不設日期。這正是 Now、Next 和 Later 的用途,因為為了填滿投影片而捏造的日期,之後就會變成你要負責兌現的東西。

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

比較價值和成本,並讓兩者的證據並列呈現。Quire 的範本把 Impact、Effort 和 Customer requests 作為表格檢視模式中可排序的欄位,刻意不混合成單一分數,因為一個數字會掩蓋掉值得攤開來討論的分歧。

路線圖應該和實際工作放在同一個工具裡嗎?

應該,否則你就要維護兩份真相,還得手動對照。把它放進工程師已經在用的任務管理軟體裡,這樣狀態變更就能自動更新路線圖,不需要任何人再去碰第二份文件。

這種路線圖結構在什麼情況下行不通?

當還沒有任何東西真正確定下來的時候。一個還在摸索產品方向的團隊,只有候選項目而沒有發布版本,這時開出一個附有日期的 Now 時間範圍,就是在捏造一個承諾。這種情況下只運作 Later 和 Idea intake,直到有東西被界定範圍並指派負責人。

這種規劃路線圖的方式,如何幫助團隊在工作上提升生產力?

它刪掉了回報這一層:不用每週重做投影片,不用在利害關係人會議前追著六個人問狀態,也不用重複問已經決定好的事。當路線圖、發布關卡和實際工作全都放在同一個 Quire 專案裡,那些時間就能用來提升工作上的生產力,而不是花在描述工作本身。