功能準時上線了，數字卻沒有起色，問題在哪？

當上產品經理的人，多半都曾把「待辦功能清單」誤當成產品路線圖。

這週業務要一個報表、老闆要一個 AI 聊天機器人、客服要一次改版，你默默把它們排進 Q4 Roadmap，然後化身規格翻譯機，努力產出 PRD，再讓工程師加班、功能準時上線。然而，儀表板上的數字常常沒能達到當初業務單位想像的水準。於是有人會說：「當初妥協的某個地方一定阻止了大眾使用，應該再做某某功能跟某某功能！」一切週而復始。

問題也許不在執行，而在更早的起跑點：還沒訪談任何用戶、還沒畫第一張設計稿、還沒寫下第一行程式碼之前，你就把老闆口中的「功能」鎖成了目標。之後的探索只剩走過場，設計與開發速度再快，也只是朝錯的方向集體加速，上線後沒有人對商業結果負責。

所以答案是：我們把功能當成了目標。解方是一個轉向：從問「交付了什麼」，改問「誰的什麼行為因此改變了」。

路線圖不是交付承諾，而是策略的溝通文件

Matt LeMay 在《產品管理最佳實務》（Product Management in Practice）把一種常見的新手 PM 叫做「路線圖聖誕老人」：急著證明自己，四處蒐集業務與行銷的點子，把路線圖上一個個加上去的節點當禮物發給聽話的部門。

更麻煩的是，路線圖寫滿了功能與日期，拿到的人就會把它當成「保證交付的承諾」去向利害關係人推銷。這時我們連迭代都談不上：Feature A 一上線就得忙 Feature B，A 的狀況如何再說，要改的東西只能排在「已經承諾」的 C、D、E、F、G 之後。團隊向著十個方向各自踏出一小步，小步快跑就變成了小步亂跑。

書中一位廣告科技新創的產品主管（Josh W.）的做法很務實：他把第一版路線圖標上醒目的「VERSION 0」，並先與業務主管約定它能怎麼用、不能怎麼用。也就是在發出去之前，先說好這份文件的性質。

LeMay 的看法是，路線圖的真正作用是「策略溝通文件」，不是執行時間表。換句話說，一份路線圖如果回答不了「我們押注在哪個關鍵的地方」，就只是一份待辦事項清單。兩種路線圖的差別可以這樣對照：

右邊這一種，就是接下來要談的東西。

用「誰＋做了什麼＋改變多少」改寫目標

準時上線、沒有 Bug，不叫成功，只叫交差。

先把兩個詞講清楚。Output（產出）是我們交付的東西，例如一個上線的功能；Outcome（成果）是使用者因此產生的行為改變，而且這個改變對公司有價值。「該專注的是 Outcome」這句話很有名，對 PM 這份工作有憧憬的人都講得頭頭是道，但路線圖還是很難逃出變成待辦清單的命運。主因有兩個：一是舊習與職務定位，同事和老闆都認為你的工作就是「準時交付」、「榨出產能」；二是即使知道原理，自己寫路線圖的能力也不見得都能體現「策略」。

不想讓路線圖變成承諾式的待辦清單，就會走向 Outcome-based Roadmap：寫出「我們期待在這段時間改變什麼」，功能本身退居為達成成果的手段與賭注，可以被實驗與證據取代；時程也不必綁死，Janna Bastow 的 Now-Next-Later 就是用比較有彈性的方式表達先後。以下是一個極簡的示意（記帳 App 為虛構情境，數字非實際基準）：

這個想法與 OKR 其實非常契合。OKR 是一套目標管理方法：O（Objective）是想達成的方向，KR（Key Results，關鍵成果）是衡量進度的結果。Outcome-based Roadmap 回答「我們要改變什麼」，OKR 則把「改變多少、怎麼衡量」寫成 KR；OKR 給路線圖一把評估點子的尺，路線圖則說明我們打算用什麼角度、什麼次序來應對某個 O 和它的 KR。KR 用的字雖然是 Result，但這些 Result 正是我們要追求的 Outcome。

Josh Seiden 與 Jeff Gothelf 在《Who Does What by How Much?》提出，每條 KR 都要能填進三格：誰（Who）＋做了什麼行為（Does what）＋改變幅度（By how much）。比方說書中的製鞋公司把「上線新版協作系統」改寫成「品牌經理提供每款鞋樣設計回饋的速度提升 50%」，「做了什麼」從此變成可以被量測的事。Seiden 說：「用公司的大目標來衡量眼前小需求的價值，這樣你和團隊才知道為何而戰。」

目標對齊、影響衡量完畢之後，你在未來的某時某刻就更有底氣說出這樣的話：「我們可以插單做 A，但這意味著能帶動本季目標 B 的項目必須延後，這符合我們這季最優先的目標嗎？」

讓 AI 幫點忙

在這件事情上，生成式 AI 其實可以幫上不少忙，但首要是讓 AI 讀得到產品的 Context。路線圖與策略有關，同一件事對不同市場定位的公司差異很大，脈絡沒進去，AI 只能憑空產生看似合理的路線圖。能讓 AI 讀多少取決於公司的 policy，不過就像你希望同事交出接近你想要的成果，就得給他足夠的脈絡，對 AI 也是一樣。可以先從三類整理起：

共通的原則是：用 AI 讀得到的格式（文字、Markdown、CSV）保存，勝過只有人看得懂的簡報；涉及機敏或個資的內容，先去識別化再提供。

另一件事是 PM 自己最該小心的地方：剛開始練習寫 OKR 時，成果很容易寫得太空虛，或者悄悄變回活動（「分析」「幫助」「開發某某版本」），而且自己寫完往往看不出來。這時可以找一位不會累的挑剔審查者。我自己整理了一組 PM partner skills，其中兩個就是為此設計：

• okr-objective-challenger：已經有 Objective 草稿時，檢視它的品質。
• okr-kr-critic：已經有 KR 草稿時，檢查這些 KR 是否真的衡量了 Objective。

它們的定位是教練而不是代筆，用提問和診斷幫你把自己的判斷想清楚。OKR 弄完之後，你對整體策略多半會有一番看法，這時再回頭檢視現存的 Roadmap，會比較容易看出哪些項目其實沒有接上任何成果。

馬上可以做的一小步

先不必急著大幅更改路線圖。除了自己的溝通技巧，組織本身也有它的脈絡，在自己的思路還沒能解釋清楚之前就全部改掉，不見得是好事。

但有一個馬上可以做的練習：挑一個你最近收到的需求，想想看

• 做這件事情以後會獲得什麼？這真的是你們想要的東西嗎？有多直接、多間接？
• 嘗試用「誰＋做了什麼＋改變多少」去表達，然後拿著去對公司的目標：該擺在此時此刻嗎？跟其他要做的事情相較之下又如何？

如果你連「誰」都寫不出來，這個需求很可能還沒被理解。如果你是準 PM，也可以拿作品集裡最得意的那個功能做同樣的練習，下次面試官問「你怎麼定義成功」，你的答案就不再是「準時上線」。

這個思路也能幫我們看 RICE 排序法裡的 I（Impact）該怎麼評估，之後另開一篇來聊。