產品實測迭代

產品迭代的實踐經驗

本篇分享我們在產品製作過程中，如何以SCRUM敏捷開發思維管理，動態定義成果，並持續從用戶回饋中優化產品。

產品迭代是一個在不斷蒐集用戶體驗回饋的同時，朝著理想產品樣貌修正演進的過程。

我們採用的行動框架大致上是參照 SCRUM 的架構，同時在詞彙與流程上保持一定的彈性。

產品開發流程：從目標到行動

首先，我們以一個 Sprint（衝刺）為行動的時間週期單位，它大約會是 1~4 週左右，並視情況調整。

這段時間內，會以 Sprint Goal（衝刺目標）為核心，規劃一系列的行動與產出。Sprint Goal 則視根據產品的不同階段或商業目標來制定，確保走在正確的發展路徑上。

舉例來說，曾經的 Sprint Goal 包括：

接著，會依據目標，在公司內部尋找適合的跨部門夥伴，共同規劃這段期間結束時，需要產出的成果細節，稱為 Output List（產出清單）或 Sprint Backlog（衝刺清單），其中會涵蓋商業策略資料、產品服務、功能、行銷、硬體改造、軟體系統優化等等。

例如，某次 Sprint 的產出清單會是：

有了此清單後，則開始撰寫任務計劃，描述著「由誰、在什麼時候、做哪些事情」，當任務都執行完畢後，理論上就可以產生所有需要的成果了！

最後，則是替這個包含衝刺目標、產出清單、任務計劃的階段性專案，適當的設定 里程碑 以掌握節奏，並在最後設置明確的截止日。

這些產出的細節，不一定能在初期就完整描繪出來，而是在真正進入執行階段後才逐步細化，甚至在過程中也會持續調整，如下圖：

這種逐步明確與彈性調整的方式，與傳統「瀑布式開發」形成強烈對比。

瀑布式要求高度確定性與前期規劃，對創新產品與未知領域反而是一種限制。而 SCRUM 這種敏捷式開發的核心精神，更適合像我們這樣的早期團隊。

難以在設定目標後就定義成果細節，是因為 PM 和執行者各自有其專業強項：

如果只由 PM 獨自定義成果，容易忽略細節、方法不當，甚至仿照競品而喪失創新意圖。而若完全交由執行者決定，則可能過於追求完美、過度投入不必要的功能，忽略商業節奏與資源限制。

因此，PM 的責任，是將用戶洞察、衝刺目標、商業目標與價值主張等核心資訊清楚傳達給執行者，協助他們做出合適的決策；而執行者則基於這些資訊提出解決方案、說明設計邏輯，最終由 PM 進行判斷與拍板。

「動態定義成果」並不只是因為產品的不確定性，還包含了技術上的困難度與理解力。而與專業執行者共同定義產出，是每個產品經理、專案經理的必修課。

我們的產品迭代節奏，建立在兩條策略主軸上：商業發展與用戶需求。

商業發展：
從產品的核心階段出發，並根據內部期待與預算資源，持續調整時間與範疇。

例如，當內部需要更早看到成果，在目標與產出規劃上，會花更多力氣在精簡產品複雜度、縮小用戶範圍等。

用戶洞察：
則是基於產品價值主張，透過理解用戶使用反饋後，持續驗證與調整。

例如，每一次改動產品與價值主張後，都會微調產品、使用流程，並且基於此再制定新的訪談計畫，核對使用者期待與實際體驗的差異。

這樣重複性的迭代，似乎讓流程更瑣碎、費時。有時候，我們自己也會產生懷疑：

「訪談這麼多用戶、設計這麼完整了，
還能有新的發現嗎？
為什麼不乾脆一次做到好？」

但事實證明，市場與用戶的永遠值得我們謙卑面對。

例如，這次的軟體系統是依附在 LINE 上運作，雖然在團隊內部測試時一切順利，但對於許多遠距工作者來說，LINE 是最常使用的通訊軟體，對話容易被洗掉，也造成實際使用困難，造成我們必須要調整流程、資訊呈現才能達到基本的用戶體驗。

這是在設計時難以預料到的，也只有在真實場景下才會發生的事。這也是為什麼我們每一次產品推出後，都會執行質化與量化的調查，確保我們真的理解用戶發生了什麼事情。